3Delight Rendering Engine for Dummies...
RKane_1
Posts: 3,037
okay... I need help.
The User guide states these things
"8.6 - Advanced Render Settings
Even when you have your quality setting at its highest there are still things you can do to improve the overall quality of your render. The render settings in the Advanced page of the Render Settings pane give you further control over the quality of your render. You can adjust these settings to increase speed or quality.
The render settings discussed in this section can be found in the Advanced page of the Render Settings pane when the render quality setting is 4. While there are many render settings that could be discussed we've chosen three of the most important settings in terms of quality. They are 'Max Ray Trace Depth', 'Shadow Samples', and 'Shading Rate.'
8.6.1 - Max Ray Trace Depth
'Max Ray Trace Depth' determines the number of light bounces for a single ray calculated by the render engine. The default max ray trace depth is 2. This is sufficient for most renders. The only time you need to turn max ray trace depth up is if you have multiple reflective surfaces in your scene. Increasing max ray trace depth can drastically increase your render time, so make sure you need the added ray bounces before you increase the value.
8.6.2 - Shadow Samples
'Shadow Samples' determines how many samples the render engine takes to create a shadow. More samples means a higher quality shadow but a longer render time. Lowering the number of samples will decrease render time but you may get grainy, low quality shadows.
The default number of samples is 16. Depending on the number of lights, the prominence of shadows in your scene and your shadow softness you can turn this value up or down.
8.6.3 - Shading Rate
Your 'Shading Rate' determines how detailed your render is. A higher shading rate means a faster render. However, with a faster render you sacrifice details. Your shading rate should be determined by your scene. If you are doing a close up portrait your shading rate should be low so you can capture as much detail as possible. On the other hand, if the subject of your scene isn't close up you can turn the shading rate up, as you won't be able to see the fine details anyway.
The default value for 'Shading Rate' is 1.00. This is a great baseline value, and most renders will be sufficient with this setting. However, if you find your render is taking far too long try turning the shading rate up. Does your render need finer detail? Turn the shading rate down."
But I am still left with a few questions, frankly.
I want to better understand the rendering process and what a lot of the things mean in the rendering option of DAZ Studio.
For 3Delight
1) What does the Progressive Rendering checkbox do when it is and is not checked?
2) Bucket order, I think, is what sections it renders first and the order that patches of the render are done. Right?
3) What is "Bucket Size"? What does adjusting it up or down do?
4) What does fiddling with Pixel Samples (x) and Pixel Samples (Y) accomplish?
5) What is Gain?
6) What is Gamma Correction and why would I turn it on or off?
7) Same with the Gamma slider? Why should I turn it up or down?
Thanks in advance for your helping me understand this better.
P.S.: Are there some recommended settings I should have for lowlight renders with many multiple light sources?
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
1- Progressive Rendering renders the scene all at once at a low resolution and looks better the longer you wait. When you have it off you get the normal top to bottom render style (or spiral, or zig zag, or whatever based on what you have bucket order set to). This is just personal preference.
2- Bucket Order- lets your render come in with different bits first. Personal preference.
Horizontal/ZigZag: top to bottom
Vertical: left to right
Spiral/Circle: From the center outwards
3- The size of your buckets. lol Really though it's just the size of the patches when rendering with Progressive off. Again, personal preference.
Try 'em out. They won't hurt the quality of the render one way or the other.
Bucket Size is the amount of data that is handed to the CPU in each batch. Larger bucket sizes use a bit more RAM, but are more efficient. Also, when you hit Cancel the buckets currently in process keep going until they complete, so a larger bucket size takes longer to cancel.
As I understand it (and someone correct me if I've got this wrong), light intensity is logarithmic, but is encoded to a linear (0-255) scale when stored in an image file. Windows and current MacOS decode the linear data using a gamma of 2.2 to reproduce the effect of light intensity as perceived by the eye. If I remember correctly, Gamma Correction off will produce the correct result for a printed image, but not for the image displayed on a monitor, for which you would turn on Gamma Correction with a value of 2.2.
1. When checked, 3Delight render the image in multiple passes. You will see you image start off looking ruff and then get better as more passes are rendered. It can be useful for seeing what your image is going to look like without waiting for the final quality to render in.
2. I lave mine at zig-zag. Its not a ibg deal
3. This tells 3Delight how much of the scene to render in blocks (per CPU core). I have tested this and found that a bucket size of 32 is best overall.
4. Pixel samples determine how smooth or grainy a render will look. If you are using Depth of Field and you want it to look smooth, turn this up. I personally go no higher then 32. I recommend keeping the values identical.
5. Just leave it where it is.
6. Gamma Correction is on all the time. The default of 1.00 if fine if you are not using realistic lighting. If you do use realistic lighitng, use 2.2
When doing test render, having your pixel samples set to 4 and shadow samples set to 4 is just fine. You will want to set them higher for a final render.
Is that Gamma Correction OFF/ON a new thing?
I don't remember seeing that before!
I expected a GC of 1 to be the equivalent of No Gamma Correction, but I'm getting different results from 'GC 1' and 'GC OFF'
What exactly IS Gain, though. How does it work and what is the slider doing there if it isn't to be fiddled with? :)
I expected a GC of 1 to be the equivalent of No Gamma Correction, but I'm getting different results from 'GC 1' and 'GC OFF'
Okay folks, now listen. I will be preaching. I've recently had the whole Linear Workflow thing explained to me by one awesome lady KobaltKween, and I'm in love.
In a nutshell, the "GC ON" is like "Linear Workflow ON", automagically. It means DS will be doing educated guesses on whether treat your textures as linear or non-linear.
Millighost has explained it in more detail perfectly:
http://www.daz3d.com/forums/discussion/22310/#329211
Why would that all ever matter?
Our eyes, our screens and our rendering software all "see" differently - our eyes have non-linear sensitivity to light, our screens have non-linear relationships between input voltage and output light intensity. This is where all this "gamma" stuff comes from - gamma is the exponent in a power law curve that models this non-linearity.
And our rendering software calculates everything in linear space. That's good. That's more like the light actually works by itself.
BUT it introduces a problem - the renderer thinks our colour textures are stored as linear images on disk, and yet they aren't!! To the renderer, our textures look much more washed out than to us!!
John Hable has a brilliant article that explains the mechanics of it:
http://filmicgames.com/archives/299
So this is why to get stuff really right, you'd want to "degamma" your colour maps = make them truly linear, make them look the way we intended in the "eyes" of the renderer, so that our renders will not look "washed out" when we apply screen gamma of 2.2 to them. To accomplish this in DS3, you'd need to do it manually - go over your colour maps and apply a 0.45 gamma correction to them in an image editor (or write a shader to do that, but that's not really efficient rendertime-wise, IMO). And now DS4.5+ can do it all for you! And if you don't want a particular colour map to be degamma'ed, you can override it in the "image editor" that pops up in the menu when you click on the texture.
// you only need to degamma colour maps, I'm not sure I understand 110% why it does not apply to greyscale maps, but there you go, these are generally okay as they are //
Okay, I hear you say: but I was getting great results without any gamma correction or linear workflow or whatever!
Yeah yeah yeah, everyone says that (apart from those who feel there's something "off" about raw renders and do all sorts of colour correction/curves/layers etc in postwork, like me...). But - I'd say it's worth trying!
Especially if you are using lights with square falloff (the "realistic" lighting Matty mentions). They will require less intensity scale upping, and will generally look very cool.
All in all... Linear workflow is the correct workflow.
Here is an excellent "why-to", if you want more information:
http://www.vfxwizard.com/tutorials/gamma-correction-for-linear-workflow.html
I always thought of progressive rendering as being a slow option, but having complained about how long the Predatron IDL lights were taking to render (2 hours or so at 750 pixels square, stuck on nine buckets worth of hair when i cancelled) I was told to try progressive rendering. Once I recovered I did so - the full scene rendered in about fifteen minutes. So for calculation-heavy renders, involving stuff like IDL and possible occlusion generally, it can be a lot faster though it does take a bit more memory.
...more on Gain from an authoritative source:
Google Books search - editing this for an umpteenth time to get the link just right, the forum software hates me again...
That's from "Essential Renderman". I have this book, and while I knew quite a lot of what it explains before I read it, I still found there is a lot of useful information there.
In general things like control maps don't need gamma uncorrection as they weren't created by looking at the colours but by their effects on transparency or bump/displacement. Colour maps, and greyscale maps used as diffuse or specular colours, would have been adjusted to "look right" on a monitor which gernally means they incorporate an implicit gamma correction that needs to be reversed out.
...what to watch out for when using automagical Linear Workflow:
Specular maps. If you are fond of sticking your specular strength maps in the colour channel, make sure you set them back to gamma 1.0 in the "Image editor", otherwise your specular will get too dark (=not noticeable).
Oh yeah. Thank you! That makes sense now.
I got stuck in the loop thinking "but I save them into the same sRGB files, so where's the difference?" And the difference is in the fact that these maps have a totally different function.
"We needs to display"? Is gamma another name for precious?
One important addition - remember that most light sets are created for rendering with Gamma Correction off, gamma 1.0 - as a result they will tend to blow out corrected renders unless you adjust them, and as far as I know there are no automatic tools for this. On the bright (so to speak) side, using GC does make regular point lights usable.
Yes the copy editing (is this the right way to call it?) in this book is atrocious. I really felt like reading with a sharp pencil at hand to correct the obvious typos and blatant mistakes. I don't know why it's like that, it's been through several reprints. Unless it got butchered in the later ones...
But the book itself is good. Once you get past what it does to the English language.
A couple of more things on bucket order/size....
It sort of matters for direction if you are using a lot of fine displacement...like displacement mapped fur or grass. In cases like that you want the buckets to go in the same direction as the primary direction for the displacement. This helps to prevent clipping on the displacement. The details and experiments for this were in a series of posts on the forumarchive...but it boils down to using vertical buckets for things that are mostly vertical, etc.
And I've found that if you can divide your image size evenly buy a bucket size, along other axis than you've chosen for direction (of course zig-zag is out), you'll pick a small boost in speed...this is because it always renders full buckets. That is if you set the width when using vertical buckets, If your image is just a few pixels over '20 buckets' wide, it's going to render that full 21st bucket...but if you adjust the image to be exactly 20 wide, then you'll save the time it takes to render that whole row.
To toot my own horn - I just checked, and my lights appear to render even prettier with GC on, without adjustment. Here they are, in case anyone's interested...
http://www.sharecg.com/v/74356/view/21/DAZ-Studio/Mk85-Fantasy-Lights
Bucket size can have an effect on rendering speeds. For each bucket that is rendered, the controlling part of the rendering engine has to gather the data needed to render and send it to thread that is rendering that bucket. Since that process of gathering and passing information can be "expensive" in processing terms, it can help to limit the bucket size. However, if you go too small, then the engine spends so much time gathering and sending that the amount of data isn't as important as the overhead of gathering and transferring it.
I like the tip that mjc shared about the relationship between the bucket size and the final image size as well.
Are there any settings I should change in special circumstances (i.e. low lighting renders, extreme close-up, etc)
What are your personal recommendations and tricks of the trade you'd like to share?
:)
Thanks in advance for your help in understanding this.
There are a few times when tweaking your rendering settings might be helpful. Mostly it has to do with the effects in the scene. For instance, if you use Depth of Field to control the focus. Or if you're using a volume shader that adds atmospheric effects. In those cases increasing the pixel samples and/or decreasing the shader samples can improve the final results.
With some lighting setups (especially those where you're using soft shadows or shadow bias), increasing the shadow samples obviously helps.
When considering closeups, etc. it isn't necessarily the render settings, but rather the surface settings. A big one to pay attention to is the bump/displacement settings. Values which look fine from a mid-range shot may be too strong when you get closeup.
Works the other way around too...values that look great close up, will probably seem non-existent in further away shots.
...so what does Pixel Filter Width do? When using progressive Rendering I get the following 3 Delight message
"(Severity 1): PixelFilter rest to "box" 1x1 (display driver requirement)"
-----
One of the advantages to progressive rendering is you can more readily see where scene errors (like floating items, shadows falling in the wrong place etc.) are without waiting for the entire render process to complete. This is especially important when you are dealing with transmaps in hair and foliage that slows the render process down.
Just ran a test between the two modes using scene built using ArtCollaboration's Alcove Jack Tomalin's Indigites the reflecting pool from Stonemason's Village Courtyard, a Skydome from Cloud9,1 AAL (replacing the UE component of Cloud9) and one Distant Light with ray traced shadows .
Bucket Render @ size 32, Horizontal mode: 0:03:05
Progressive Render: 0:03:55
Even though it takes a little longer, I tend to prefer the Progressive render. This is the way Bryce renders as well.
Pixel filter helps deal with aliasing issues. Compare your final result after "progressive" rendering with a "normal" one with the filter set to "sinc" over at least 4x4. If the "progressive" final render does not look as good as the sinc-filtered, it means there's something weird going on within the DS/3Delight interface, and maybe it's best to file a bug. If they look the same, then it's probably a message popping up when a shadow map is filtered, and then nothing to worry about - are you using DSM?
In case anyone wants further reading on filters:
http://www-cs.ccny.cuny.edu/~wolberg/pub/crc04.pdf - the introduction shows a filtered picture vs an unfiltered one;
http://www.renderman.org/RMR/st/PRMan_Filtering/Filtering_In_PRMan.html - a lot of generally useful information
...no, all shadows are raytraced.
That's sad if it is a bug as I prefer the progressive render more since it lets me catch errors in the scene faster.
You should probably still compare the outputs of the same scene rendered with "progressive" and "normal" modes (there's an option to drag one render over another in the render editor, IIRC, or just use an image editor). Maybe there's something with texture filtering - I don't think I've seen this error mentioned on 3Delight forums as connected to texture filtering, but who knows... If the renders look much different, then sure a bug. If not, then don't worry =)
...yes there is a difference. I notice that the conventional render does look cleaner along edges at filter 4 x 4. I then experimented by bumping it to 8 x 8 and noticed that transition between highlights and lowlights looked even cleaner and sharper than the default.