Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I don't know what preprocessing Iray does to textures, if any. Those Image Editor values are meant to be passed by the Studio to the 3Delight utility called tdlmake, the preprocessor. The Iray equivalent may not have been implemented yet.
Bless you for writing this. It should be required reading.
I've been a GC evangelist since the early days with BagginsBill. I was overjoyed when it came to Studio.
Its a shame that you will be ignored, reviled, belittled and told "It looks better to me with GC off, and its the default anyway so why should I turn it on?"
Some people do not want to learn, or refuse to step outside what they think they know.
If it were up to me, I'd cannonize you alongside Kettu, Wowie, BagginsBill, theSea and others.
Sorry, I guess I am having a cynical day.
That's not what I said at all.
Whenever a new technical workflow comes along I have to test it, and I have to also weigh it against my current time budget for promos. Even if it is more correct and gives a better result - which it can, there are some lovely images in this thread - people's follow-up comments indicate that the actual workflow time for making it work with every image is much too high for me to use it, because I needed to do a number of additional steps even to make the simple image I presented work.
"I don't have time because I have to do ten promotional images per product in two days" is very different from "why should I bother, it's not the default."
I'm sure there will be some gorgeous and much more photoreal images that can result from the information in this thread, and I look forward to seeing them; and those would not be possible if Parris were not here sharing the information.
That's not what I said at all.
Whenever a new technical workflow comes along I have to test it, and I have to also weigh it against my current time budget for promos. Even if it is more correct and gives a better result - which it can, there are some lovely images in this thread - people's follow-up comments indicate that the actual workflow time for making it work with every image is much too high for me to use it, because I needed to do a number of additional steps even to make the simple image I presented work.
"I don't have time because I have to do ten promotional images per product in two days" is very different from "why should I bother, it's not the default."
I'm sure there will be some gorgeous and much more photoreal images that can result from the information in this thread, and I look forward to seeing them; and those would not be possible if Parris were not here sharing the information.
Don't worry, I didn't take your comments that way. I think what evilded777 means, is that I face an uphill battle trying to convince the DS community, and he would be right. This topic has historically met with skepticism in every forum that has introduced it.
Wow evilded777, thanks for the high praise! Admittedly, I'm a bit of a lurker and have read some of your posts on GC and admire your work, so I was hoping you would pop in here. As for this being ignored and reviled, you are probably right on target (not being cynical). GC is confusing and when implemented incorrectly it leaves a bad taste in the artist's mouth, with some vowing never to return. But fortunately, I'm getting some great help here and the response so far seems pretty positive.
Like I said though, I knew when I took this on that it would be an uphill battle. I put GC support in Aikobot 2 before DS supported it in render settings. Back then I thought Gamma Correction would be as big in this community as SSS is now, since it is very well established in the high end CG world. But the "Buzz" never came.
I was NOT looking to single anyone out with those remarks, and especially not YOU, SickleYield, My most sincere apologies if you took offense and thought my comments were directed specifically or generally in your direction.
The fact that you are ALWAYS popping up and trying new things automatically exempts you from any criticism I might level with my cynical shotgun.
That's not what I said at all.
Whenever a new technical workflow comes along I have to test it, and I have to also weigh it against my current time budget for promos. Even if it is more correct and gives a better result - which it can, there are some lovely images in this thread - people's follow-up comments indicate that the actual workflow time for making it work with every image is much too high for me to use it, because I needed to do a number of additional steps even to make the simple image I presented work.
"I don't have time because I have to do ten promotional images per product in two days" is very different from "why should I bother, it's not the default."
I'm sure there will be some gorgeous and much more photoreal images that can result from the information in this thread, and I look forward to seeing them; and those would not be possible if Parris were not here sharing the information.
Thank you. Perhaps deviantart has made me overly tetchy this month.
A couple more examples:
Parris, Your work is amazing.
Do you post tutorials anywhere?
Parris, I don't know if anyone, on any of the forums I haphazardly frequent, has ever said they admire my work; so I thank you for that.
I'll try to climb out of the deep well of cynicism I seem to have fallen into and try to contribute to the conversation.
Hard not to be negative if you're not getting enough positive. Just remember there are lurkers like me everywhere, so you may have more fans than you think. To be specific I saw several images of yours in a thread about lighting in DS that I thought were excellent. I also should have credited you for sharing one of the links to good GC tutorials that I listed in my first post.
Hey, thanks! Getting an "Amazing" is, well... Amazing!
Aside from the odd answer to someone's question, or a recipe, this is probably my first real attempt at sharing what I know with this community, though I've been a PA since 2004.
If you want, I can share one of my images here and I can break it down - share all the steps and the reasons for my approach. How about that? I might not be able to do it right away though. I'm working on my taxes right now.
That would be wonderful. Would really, really appreciate that.
This feels like a prayer being answered.
I decided to start using DS from now on after seeing such realistic renders.
I am right now rendering my very first image in DS using Iray.
Will post it for your constructive criticism once its done.
Today is the start of the DS journey.
Ok, sounds good. Although, it might be best to post Iray Renders elsewhere (and let me know where you post), since this thread focuses on 3Delight and Gamma Correction. I haven't yet delved into Iray so I won't be able to offer Iray specific help, just yet. I think we have yet to establish (in this thread at least) how to properly implement GC in Iray.
Parris, I understand.
What a great thread and I'm so glad it's stickied. They should set the GC in the render settings to 2.2 by default when they package DS. It's only recently that I've been setting the gamma map per map, but, it makes a heck of a difference.
Well done for making yourself heard
CHEERS!
It probably should be the default...but it's also not going to happen. Doing so, without individually correcting a lot of the old maps is going to cause problems and there is too much 'wrong'/non-linear content in the store to suddenly switch.
Yeah, you're doubtless right. Us and our wishful thinking eh.......
CHEERS!
EDIT:
I just remembered, my avatar was rendered with GC off! Oops!
The important part here is that to determine if to apply gamma or not, you have to determine if the value is an output/input or if it is used in calculations. I.e. The question is "how is this value used?", not "how is the value produced?". By simply gamma-encoding a Surface-brick, gamma encoding is done per surface, but not on how the surface is used. The value that a Surface-brick produces can be used in many ways in a render, to output the value on a display for viewing is only one of them. In particular it can be used for anything related to global illumination, like reflections, refractions and most importantly: indirect lighting. All those are calculations and therefore they should happen in linear space.
So what would be needed is this: As soon as you have a single surface in your scene with this kind of gamma-correcting shader, you would need to go through every surface in your scene which has e.g. reflections and mess with their nodes to gamma-decode the reflection value again. But only the reflections of the gamma-encoded surfaces, not the linear surfaces. That leads to the problem of how to determine if a surface is gamma-encoded or not (in 3delight you might have a chance to solve this by using a discriminations by raytype, at least for the raytracing calculations). Bagginsbill later posted a variant of his shader that handled reflections, but required that all surfaces in the scene use that shader, not only one (search for it in the renderosity forums, if interested). All in all very complicated stuff, and exactly the opposite of "linear workflow". However it can still be useful if all you have is a non-pro version of Poser. But as soon as you have Poser Pro or DS4 with gamma correction, stay away from it.
My headache has cleared somewhat, so now I can do what I meant to but couldn't (since I was looking forward to getting away from the computer ASAP above all):
There's a lot of absolutely stunning renders in this thread.
Twice as beautiful if they weren't done with full GI but rather with "oldschool" lighting techniques. This is a skill that I wholeheartedly admire.
------------
Each and every one, including the "high end"/"big name" communities. Most of the linear workflow tutorials were written for Maya users. Even Stephen Westin has had images published in his seminal papers that weren't gamma corrected. He has since put up new, correct versions of them on his website.
The only community that seems (to me) to have accepted linear workflow smoothly is the Poser one - because, well, because of Bagginsbill's relentless activity to guide and educate the community. And GC being on as the new default in Poser.
We probably won't get away with a new default in DS - the guys were right about too much "non-linear" stuff in the store.
What I would suggest is "fixing" all those example scenes that come with DS or DAZ-authored free tutorials - like that Fiery Genesis one (I did it, so it should be possible for others). Now that all render settings, GC state included, are stored inside the scene file and can be readily saved as presets, this should be easier than it might have been some time ago. A few builds back, gamma info for a texture was not reliably stored in mat/shader presets; now it is. So we're all set.
------------
*blushes* Oh please. Thank you. But... If anything, the list should start with BagginsBill and theSea. And KobaltKween.
It probably should be the default...but it's also not going to happen. Doing so, without individually correcting a lot of the old maps is going to cause problems and there is too much 'wrong'/non-linear content in the store to suddenly switch.
I think the next best thing to having GC on by default, would be to support it in product going forward. That's what I'm doing now. There are two ways to go about it:
1) GC in Render Settings: Map settings get saved with Material(s) Presets. But if a user changes maps then I think they have to update the settings for the new map.
2) GC in Shader: DS doesn't have to assess, because the PA has already made the determination about what parameters get anti-GCed. I'm pretty confident at this point that I can retrofit any Shader Mixer shader, including the DSDefault to have GC built in. Then the user just has to select all of a given shader and apply the retrofit shader and parameter settings remain intact. Not perfect by a long shot. But it's something.
Also, I've extrapolated Bagginsbill's Poser method for auto-detecting GC, and incorporated it in Shader Mixer, so Shader GC shuts itself off if Render GC is on (so GC doesn't happen twice).
Other benefits of shader based GC: GC what you want. For instance some have been disappointed with how GC makes trans maps more "whispy". That can be avoided with shader GC.
The majority of that went straight over my head. I tried a few of Bagginsbill's methods in Poser, nice results, but boy did they take some setting up!
CHEERS!
The important part here is that to determine if to apply gamma or not, you have to determine if the value is an output/input or if it is used in calculations. I.e. The question is "how is this value used?", not "how is the value produced?". By simply gamma-encoding a Surface-brick, gamma encoding is done per surface, but not on how the surface is used. The value that a Surface-brick produces can be used in many ways in a render, to output the value on a display for viewing is only one of them. In particular it can be used for anything related to global illumination, like reflections, refractions and most importantly: indirect lighting. All those are calculations and therefore they should happen in linear space.
So what would be needed is this: As soon as you have a single surface in your scene with this kind of gamma-correcting shader, you would need to go through every surface in your scene which has e.g. reflections and mess with their nodes to gamma-decode the reflection value again. But only the reflections of the gamma-encoded surfaces, not the linear surfaces. That leads to the problem of how to determine if a surface is gamma-encoded or not (in 3delight you might have a chance to solve this by using a discriminations by raytype, at least for the raytracing calculations). Bagginsbill later posted a variant of his shader that handled reflections, but required that all surfaces in the scene use that shader, not only one (search for it in the renderosity forums, if interested). All in all very complicated stuff, and exactly the opposite of "linear workflow". However it can still be useful if all you have is a non-pro version of Poser. But as soon as you have Poser Pro or DS4 with gamma correction, stay away from it.
Hmmm... I'm not sure I understand the contradiction, nor the severity of the problem that makes you say shader GC should be avoided entirely. Can you explain further? Could you demonstrate it with a picture? Note that all of my renders shared in this thread use shader GC.
Sorry. Basically I'm saying that I can make my products handle the setup for GC by default, so you don't have to do anything. But you can still make adjustments if you want.
In my experience, setting the opacity map gamma value to 1 always fixed this issue.
Although it's one of the areas where DS keeps guessing wrong. Say, on loading a Poser mat: bumps will get detected as linear control maps, but not opacity maps. So a manual check is needed almost always (unless you saved the mat yourself with the proper values).
Wow, thanks! Yep, you called it (not full GI). My typical light setup in these renders is a key (either spot or distant light), a rim (same), and a low intensity AoA Ambient or UberEnvironment2 as a fill. This hopefully demonstrates one of the ways that GC makes things easier.
Maybe it would be good to show one with full GI though. Do you have a recommended setup?
Part of that is the fault of the map...I've found ones that are RGB as opposed to greyscale are more likely to show up 'whispy'. And for a control map, does it really need to be 'color'?
Hmmm... that seems like a good tip, thank you. I need to test that.
Zilvergrafix, I don't know if you are still following this thread, but I wanted you to know that your post was neither unnoticed nor unappreciated. I wholeheartedly agree with you about the importance of getting the eyes right. The hardest thing to fake is the human face, and the hardest part on the face is the eyes. It's not cliche to say that much of the "life" and emotion comes from there. Thank you for pointing that out.
How do you feel about these?
Hmmm... that seems like a good tip, thank you. I need to test that.
I don't know if it's more likely that a non-color map is likely to be seen by Studio as a control map or what, but it's just something I've noticed. I kind of stumbled on it when working with an older hair. The bump map was not color (no, mot just black and white, but actually set to greyscale)...so was the transmap. I was trying to enhance the detail by pasting in one of the light colored maps, but it was always pasting in as a greyscale image, not color. But I also noticed that when rendered, this particular hair didn't get all wispy when GC was on. So I started looking/playing. The few that were wispy, so while the transmaps were black and white, they were actually 'color' images. And manually correcting them did help. But the true non-color ones loaded as 'control' maps...
What I'd like to know is exactly what data is being used when the maps are being fed to tdlmake. Because, that color information, bit depth and what not are all in the image file, so I'm guessing that the correction is more likely to be correct, if the expected map type is being fed to it...a true non-color map for a control map.
Also, map location seems to have some impact as to whether or not the 'guess' is correct. Ones in the strength slots tend, in my experience, to be more often correctly assigned. While ones in 'color' slots aren't. Normal maps seem to be one exception...it seems to me to be totally random as to how they are treated.