Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Thanks SY. I hadn't seen these before. What I notice from watching one of them is the fact that you seem to have a lot of graphics hardware to play with. That's reasonable for a professional but most hobbyists can't afford that kind of render power. I know the theory is the same and that just the render times might vary but it does have a bearing on how scenes are put together. I have only just bought a GPU capable of rendering IRay scenes but my test renders take many minutes to resolve to a point where I can make lighting decisions. Yours seems to get there in seconds.
The other point I would make is that the idea of adding lots of zeros to the lumen setting is so vague. Start with 1500 then jump to 3,000,000, then play with tone mapping. Also play with the geometry of spotlights and the question of which units to use (Watts or c/cm2, etc.). This is one area where Luxrender seems to be far more predictable than IRay.
What I generally do is go into the scene tab, do 'expand all,' ctrl-A to select all items, then go into surfaces tab, again expand all (because sometimes selecting objects doesn't select all the surfaces on said objecty), select all.
Then double click on the Iray Uber, and everything converts.
The problem is that sometimes things don't convert right. At that point you have a very annoying task of hunting down all the stuff you need to tweak.
But MOST of the time, the above thing works fine and you can do a quick test and then tweak one or two things.
I do wht Will says, but Command (ctrl) click to keep my maps.
Luxrender might indeed be better with this, but for Iray, it's really a matter of consistency inside D|S -- Iray is actually pretty consistent in the formulas it uses.
You mention spotlights; they lack the feature to change the luminance units. Only emissive geometries allows you to change the units, and your choice will dictate whether the apparent brightness of the object changes with size. Spotlights and point lights have only a lumens setting, and because you can change the emitter size and shape, there can be a wild fluctuation in values in order to achieve the same light intensity at any given area of the scene. This makes sense when you get down to it -- light from a flat disc is distributed only over the area of that disc, but light from a sphere must be distributed 360 degrees in all directions. A sphere, directly viewed by the camera, will appear less bright at any given lumens, because much of its light is pointed away from the lens.
Things look a little more consisten once you figure out how D|S is representing lumens through the various lighting types, though bugs/changes may upend that, from time to time. For example, the value of the distant light is measured in lumens incident on the scene, rather than light produced by the fixture, as is the case with the others. In 4.8, this was measured in cm^2, so a value of about 10 would simulate noon-day sun; there's about 10 lumens per sequare centimeter on the ground at full noon. For whatever reason, in 4.9 the value now appears to be measured in m^2, requiring a 10000x increase in value. It's really the same intensity, but the difference is in the scene units that D|S uses. (D|S defaults to centimeter as the scene unit, so it's odd that distant lights are now measured in meters. Go figure.)
The render settings are already optimized. Except for a few settings here and there, D|S uses the Iray defaults, which have been selected for their balance between performance and quality -- otherwise known as optimization. You can read about the various default settings in the Iray programmer's manual, here:
http://www.migenius.com/doc/realityserver/latest/resources/general/iray/manual/index.html
Not defined in any manual is optimizing the scene for Iray, which is a wholly different subject. The common causes for a poorly performing Iray scene include:
* not enough light;
* excessive highlights (can cause fireflies);
* "noisy" shaders (the specularization of the materials causes slower convergence calculations);
* unnecessary use of emissive geometries when the native light types will work as well;
* poorly selected geometries that over-complicate light exitance calculations (too many facets when just a few will do)
* an extreme number of light bounces due to reflections (alter the max path value to compensate)
* internal reflections in overlapping geometries
and a large number of others. Only a few of these things can be "fixed" (more like Band-aid coverups) through changes in the render panel settings, so it's better to correct the scene in the first place. The forums have been pretty active with suggestions on how to improve the scene for better Iray results, though I don't know of any one source that's collated it all.
I came across something in an Iray document that seems to work on some renders.
Open up a scene that takes a while to render. Go through all the surfaces and where the Glossy Color is set to white, unless there is a map there or it has been preset by the shader, click on it and change the Val: setting to 217 instead of 255; change Glossy Reflectivity to 0.70, and see if it helps.
I just tried it on an old render and it went from 15% after 45 minutes to fully rendered after 30 minutes. I've been testing this for a while but that was the biggest difference yet :)
That's one to remember - thanks.
I've been observing the GPU performance with GPU-Z and I'm surprised to find that the GPU is constantly around 90% even when nothing is happening in the scene. This is with the main viewport on Texture Shaded Draw Style (OpenGL) and the little AUX Viewport on IRAY interactive.
It is the default setting of 0.50 that I change to 0.70.
Ah... kind of baffled why that would help. Huh.
I didn't think it would make much difference either but it does help with some renders and speeds them up.
Good tip. I'll store that in my notes!
Unfortunately it doesn't work on every render nor to the same extent. I use it in conjunction with tweaks to the Environment settings which I found in another Iray paper. They speed up the render but don't give a perfect image. I think they would be of most use for animation where image quality is less of an issue.
Pretty much, yes. That's what I'm doing right now with some of the old Poser-era stuff we're now getting transferred from RDNA. Sometimes you need a lot of patience and a lot of test renders, but some of these ancient models come out looking surprisingly good.
"Only applying the Uber preset" is usually a good beginning. The big plus in doing it, though, is that it allows you to tweak material settings between test renders in a consistent, controlled fashion. That's impossible if you just rely on the auto-conversion at render time — there's no guarantee that a change you make to 3Delight materials will translate to the same change in the final render.
Scavenger, if you're looking for speed and noise reduction (it's geared to animation, but still good for reducing times), try this:
One thing that video doesn't mention is rendering in IRay interactive mode which is a lot quicker than photoreal mode but more realistic than OpenGL. I find that some IRay materials look over-glossy in OpenGL so if I were using OpenGL for animations I would probably switch back to 3DL materials. Nor does it mention keeping an IRay preview render open so that IRay doesn't have that 30 to 40 second delay when loading each frame. That is discussed here (scroll down to the comments from MEC4D).
I'll have to try the over-sampling method but I would have thought that increasing the image size would increase the render time even though you might need fewer iterations. In other words, one would cancel the gains of the other.
Interactive mode can be quicker but sometimes the quality is not as good.
For manual oversampling, as long as your scene and the calculations for the larger image fit in your card's memory (and if the scene isn't too dark as mentioned elsewhere), there's less time spent computing if you set it to render at lower iterations, and resizing the image to 50% of it’s size, emulates what two times anti-aliasing would do since the pixels blend together at 50%. Combined together you get your time savings with less noise and not having to go the extra time to get rid of that noise.
For sure, Interactive is not as high quality as Photoreal, Kevin, I do agree. There's problems with transparency and HD and the Draw Dome looks blurred compared to Photoreal. But for animations, where a frame is on the screen for a fraction of a second, these limits might be acceptable.
I need to find more time for experimenting with larger images - need to find out how big a scene my 4GB GTX970 can take.
Im finding that is is not always necessary to convert EVERYTHING to iray base. Some matrials convert nice "as is" here is an example where I just applied some shaders to certain items and let some translate over.
http://fav.me/da0dghj
The thing is, even if they render well, all that means is that the autoconversion is adequate. Preconverting all materials will save some time, in the long run, especially if those conversions are saved as material presets. It eliminates the autoconversion step...which can be very time consuming, if there are a lot of items to be done. Also, there is no easy route to tweak the settings, because if you tweak the 3DL material, then it will be autoconverted after each tweak, but a material that has already been fully converted will just render.
I have more of a process of elimination approach. Whetever does not auto convert well outside of planned used shaders I will then make that material DAZ uber base and tweak (which is reducing gloss in many cases) as needed.
Then again some shaders NEED to be converted even if only by applying the Uber Base iRay shader into the mix. I had this exercise ball nicely set up for 3Delight. Added it to my scene and my render took like 45 minutes to go fully. When I converted the balls shaders to iRay the render was done in under 5 minutes.
That's definitely a case where, while the autoconversion may have ended up with acceptible results, they were not optimized so a major time penalty was incurred.
And yes, it can be more common than one would think for that time penalty to happen...because the autocomversion isn't going to do any optimization. And yes, using the MDL examples can even improve times over the Iray Uber...eliminating unused options/features can really speed things up.
Right now I'm working on a hair shader and just trying to get a handle on the values, colors and strengths to get something nice. Seems that Glossy Roughness plays allot into the shine effects on the hair. Weird. Roughness in my mind tells me to roughen up the surface so that tells me that the light would be more diffused, broken up but the higher the value the more light seems to gleam off of the hair... Still trying to get my head around all this I guess! lmao
Never thought of none converted materials adding time interesting..
Here's a link that should be helpful...
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/interface/panes/surfaces/shaders/iray_uber_shader/shader_general_concepts/
...but wouldn't increasing it make a surface appear more shiny?