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
Well, if you turned off the progressive option in the script, it will use REYES, which can still be faster with very simple scenes like the ones you're using. If you're using UE2's BounceGI option, the raycache option in Kettu's scripts really helps speed that particular mode..
I did a quick test with a scene similar to yours but with the Toulouse hair. Even in AO mode, the render with Kettu's script is faster by about 4 seconds (both with progressive rendering enabled). I'm thinking that the speedup may come from the shorter time taken by the SSS precomputation pass.
Are you sure? I thought Kettu recommended it to be off in the script. I just did a normal DAZ Studio/3Delight render (that is REYES isn't it?) and the hair took much longer. Same settings as above. It took 4 minutes 30.9 seconds to render... much longer.
Well, it kinda depends on how complex the hair model used. I don't have that exact model, but with the Toulouse hair, progressive (raytrace hider) is quite faster. Judging by your times, I'd say both are pretty similar. I'm also getting something like 1/2 the render time with progressive rendering (compared to REYES).
The only thing left is the ray cache and of course your BounceGI settings. As you noted in previous posts, Kettu's script with raycache enabled can really help minimize render times with UE2's BounceGI mode. Have you tried running Kettu's script with the progressive render enabled? I'm curious what the render time would be.
Two things makes me a bit uncomfortable using BounceGI, even with Kettu's script. First is that render results tend to vary with the number of samples used. The second is noise. If you rely too much on bounced/indirect light in your scene, the shadowy areas looks pretty noisy compared to just plain occlusion with the same settings (shading rate 16 and occlusion samples at 128). Even with shading rate at 1 and occlusion samples at 512, I'm still unable to get good, clean, crisp shadows.
Here's an example of what I mean. I'm using BounceGI with a very strong indirect light (200%), occlusion samples at 128 and shading rate of 16 (with progressive rendering). Max trace distance is 1000, with a max error of 0.1. Normal render is 10 min 52 secs. With Kettu's script, render time went down to 4 min 30 secs. The entire scene is lit with one AoA's Advanced Distant Light.
Notice the noise on the grey chiller with both BounceGi renders. If you look very close, you can also see noise in the chair's padding. These areas are not directly lit by the distant light, so we can rule out insufficient samples with the Advanced Distant Light (set to 64).
Here's a render with occlusion samples set to 512. Took 11 min 50 secs WITH Kettu's script. The noise on the chiller is better, but still not as clean as I'd like. I can lower the Max Error, but I think these examples are enough to illustrate my point. Also note the general luminosity is noticeably different.
Of course, you can pretty much avoid this by using more direct lighting in your scene and avoid having dark areas. Keeping the camera zoom close will likely help too. There's also DOF which can help 'blur'out the noise.
I have problems with noise with a GI render with the Classic Deco Scene. I'm still undecided what to use finally with animation... I guess whatever works best. You can have a little noise in animation as the shot is moving, as long as it's not speckly. I'm toying with the idea of rendering some stuff separately and compositing everything.
Here's part of the code from Kettu's script. I think she calls on the raytracer separately. That's what I'm guessing as I'm no coder. Maybe Progressive Render is an added feature that is not tied to the hider in the script but is tied to the hider the way DAZ has it setup for Progressive Render.
>>>>
// Begin describing the render
Renderer.riBegin( sRibPath );
// Use the shiny new "raytrace" hider
// Enable or disable progressive rendering: [ 0 ] disables, [ 1 ] enables
aTokens = [ "integer progressive" ];
aParams = [ 0 ];
Renderer.riHider( "raytrace", aTokens, aParams );
// Enable GI cache for extra fast GI
// Option "trace" "int diffuseraycache" 1
aTokens = [ "int diffuseraycache" ];
aParams = [ 1 ];
Renderer.riOption( "trace", aTokens, aParams );
<<<<</p>
I changed the 0 to 1 to enable progressive before I rendered this in 3 minutes and 0.15 second: All the settings same as before. So with the GI pass enabled as before but no GI source in the scene, it is slower than the normal Progressive Renderer in Studio. I'm thinking she's correct and the Hider is working, and Progressive Render for the display just adds time to the render. There was some program I used years ago that was faster if you didn't display the render as it was happening, maybe it's similar to that.
Oh, and the hair is Micah Hair.
If you're aiming for animation, I would suggest sticking to AO and direct lighting. From my experience, the combo performs best and generally is more 'stable' between frames. An even better solution is to use point based occlusion. Since it's not an IBL light, you need to use additional lights to lit certain areas, but usually you already use some anyway.
Thanks for the hair info. Don't have that hair though. I don't buy that many male hair as I should :)
Yep, stability between frames is very important. I've also been digging into area lights, and some soft lights, too. I tried Point Based Occlusion once but got side tracked with other things. I'll check it out again. Thanks!
Hi everyone,
Neat renders!
Wowie, thank you for the links, I'll check them out ASAP.
Now, the script:
I do call the raytracer explicitly. Then you can decide if you have progressive on or off.
It's like: only raytracer can do progressive, but raytracer can be either progressive or bucket-based.
I don't personally _like_ progressive for final renders because it's hard-wired to use the box filter - and I prefer sinc.
The filter will also influence render times (box should be faster). So, there are many factors at play... Also pixel samples seems to have more impact on raytracer speed than on REYES speed.
And yeah, using GI cache makes no sense if there is no GI light (in theory, it's "diffuse" ray cache, and AO also uses diffuse rays, so it may speed up AO... or not. I never tested!). It won't break anything, but it may well slow things down, to generate itself, in the very least.
Wowie is right, PB GI/AO might be still best for animations because it's not supposed to flicker. But there's a "jitter" option somewhere (don't have time to look it up right now, but check the 3Delight manual) - I remember reading somewhere that it may also help with flicker, when it's off. But don't trust me on that right now, haha =) I don't even remember if it's REYES-only or not.
Fair enough! Thank you, Kettu!
I just tried disabling GI Cache and saved almost 5 seconds... render took 2 minutes 32.8 seconds.
...looks really good. Thought I saw some "noise" in the hair but then it was just dust on my screen.
OK so my next point. Turning off GI in this case saved 5 seconds. I would feel such an advantage would be very important when rendering animations.
However, I primarily create still images and rely on a lot of "in scene" effects, some that apparently are not compatible with this process. Postwork for me is limited to "touch ups" and use of various filters as my arthritis precludes any extensive "digital painting" to make up for the loss of what I can currently do with the standard 3DL in a single render pass. Other than reducing render time, I am having difficulty in seeing what advantage this process would have for my work as I would have to spend much more effort (and pain) in both "pre-production" (scripting and set up) and "post production" in a 2D app to achieve the results I desire and can already achieve, albeit with longer render times and lack of GI (until Age of Armour arrives at a viable solution for that with the Advanced Lights).
No render noise there, Kyoto Kid, but thanks. I did a full render with settings turned up tripling the render time and the hair looked the same. It's probably something in the texture being brought out by the gamma being cranked to 2.2 for Wowie's Lights and SSS.
I'm not so sure the Hider is as incapable as you think it might be. And it's only less than a handful of people using Kettu's script that are posting here. Some folks are just using the Progressive Renderer and calling it a day. There's already been disagreement about what it can and can't do. Best thing is to try it and see.
Now I was happy about the 5 seconds, but that's nothing to a scene with full GI, that pass would be a little longer, but still pretty quick.It would add up though for animation. I was really excited about the big difference from REYES to Progressive Render to just the Hider. It's a substantial time savings for animation. It's about two minutes off for this very simple scene. It will be longer for more complex scenes, that's why I mentioned breaking up the scene in separate renders and compositing them, as you could light by light. Two minutes off is like getting a big CPU upgrade without having to buy a new CPU. And a direct light occlusion render is as fast as some of the direct kernel times I've seen posted for Octane Render as it has gotten more complex compared to when it had fewer features. Not bad and it saves me having to wait around for the plugin to use Octane Render 2.0 that still will not include the time spent moving stuff over to Octane and tweaking for it. Tradeoffs for everything it seems.
But if you are happy doing things the way you have been, then stay happy. I'm sure someone will come up with some new tricks that may do what you want.
...thank you as well for the kind response.
Yeah it would be nice to have GI and bounce light for outdoor scenes. I have to "fake it" with extra spotlights flagged to specific characters/items in the foreground. Finishing up on a pic I will post which is probably as far as I can push things with the Advanced Lights set.
I do use the progressive render for test renders mainly to make sure shadows are where I want them and I don't have feet burind in the ground plane or characters floating slightly above it. However as mentioned, it overrides certain settings and details in shadowed areas is poor.
True, saving time during rendering is still a good thing as it puts less heat stress on the CPU and system. However if a single pass takes say 40 min and five layered passes take just as long (if not longer), I don't see much of an advantage especially given the added postwork time to put it all together. I have experimented with multipass rendering and compositing and actually, I don't particularly feel it looks any better (and in some cases, worse) than the same scene does when rendered in a single long pass. Guess it's the painter in me which makes me a bit more patient as with oils it could take a day or more for the paint surface to "set" properly. Heck, I was working with the concepts of GI, AO, bounce lighting, and SSS long before there was ever a thing called 3D CG (and it seemed a lot simpler then).
There is no one-size-fits-all, obviously. And that includes not just "person to person", but "scene to scene".
Whenever there is a render that does not require using AoA's cameras, isn't faster rendering worth it? Just the gain with soft raytraced shadows through transparencies, that's quite a lot.
The scripts are literally "make once, use forever".
Anyway... Your patience may well pay off some day - there will be a freebie in a few weeks: scripts, shaders n'stuff.
PS With all due respect to AoA, a "viable solution for GI" is better requested from DAZ Studio developers than from him. AoA writes shaders, which are all based on built-in shadeops - functions that simply won't suddenly outperform themselves, all other things being equal. GI won't fly without caching.
You're looking for an integrated solution that would at least call the GI cache seamlessly and hook up the atmosphere shader along. It's either a dedicated rendertime script or a few more toggles in the default DS interface. Given the Spartan state of the DS documentation regarding shader cameras, even the first option is more likely to come from the DS devs than from anyone else (I plan to investigate stuff further, just for the heck of it - and it's the only reason I ever do anything non-job-related, actually - because I like RI_Fog, but! I won't even be touching ShaderMixer objects, there's just too much DS-specific stuff to them).
...there almost isn't a time when I don't use either the effects cameras or advanced lights (or both together) anymore.
Having true squared falloff on the spotlight (and point light if you set the Advanced spotlight to 360° spread) makes for better more "real" lighting effects. Again the flagging ability makes these lights so much more valuable and helps to control render times.
I'm an old time veteran of LDP/LDP2. At the time it was the best solution for "real" lighting. Granted ti took nearly three dozen individual lights to do so, but it was still remarkable. Changing the Skylights to Ray tracing made it more stable on my old 32bit system (shadow mapping sometimes would cause a crash), though it did take some time. DreamLight's decision not to update the plugin for Daz 4.x was a huge disappointment (LDP-R is not the same and at least IMO is far more complex than it needs to be).
I have since taken to using AoA's Advanced Lights Set almost exclusively as I they allow me to achieve pretty much the same quality I could get with LDP/LDP2., only with a lot fewer lights and much improved render times. While I have a number of IBL/environmental light sets (like Skies of Economy, Cloud9 and Lantios' sets) I rarely use them much anymore (save for on occasion "stealing" a skydome) because of the lengthy render times.
Unless I can scrape up the resources to build a 24 processor thread beast with 64 GB of memory, I most likely will rarely, if ever, use UberEnvironment based lighting much anymore save for creating mesh lights with the UberArea light.
...oh and BTW, one thing I discovered is that The EasyVolume Camera and UberArea mesh lights don't like playing with each other very well even when only an Advanced Spotlight light is flagged for the volume effect. After thirty minutes, only 6% of a scene I was working on had rendered at 900 x 900 resolution (estimated total time: 7.5 hours). After resetting the shaders and using a setup of 6 linear point lights to substitute for the mesh lights, the total render time for the scene dropped to 27 minutes.
Just in case - don't forget that UE2 and UberAreaLight are separate and independent light shaders.
But in all honesty, I don't know what's wrong with those pre-built light kits you mention. None of these seem to be using GI or IDL. I do have one of Lantios' packs (one of the Core Lighting kits), but I bought it on sale simply for the sake of having a popular light kit to test my models under, those models I plan to (hopefully) sell one day. I never really rendered anything "production-style" with it (or anyone else's kit, although I did buy a couple).
However, I was rendering with UE2 set to image-based light with AO exclusively, even in DS3 - so, all REYES/hybrid, no pure raytracer speedups. And I never found it gave particularly long render times. I don't know if people who DL freebies are likely to complain about render times - but my freebie light kits released this far are all UE2-based, and I have not had anyone come up to me and say "Your lights take too long".
Maybe it's because for those kits (which were all born of stuff I did actually use for my renders) I used dzLights instead of built-in lights, and dzLights are overall better and faster. Maybe it's because of "my" non-overwhelming AO distance (the other UE2 settings there should be fairly HQ). I know that I, personally, religiously kill AO on transmapped surfaces, and I was using DSMs exclusively on my older computer, - both these things save a lot of time (okay yes, DSMs are trickier to work with due to self-shadowing issues...).
TL;DR: it should be possible to get acceptable render times (for me: under an hour for a 1000+ x 1000+ scene of relative complexity) with UE2 even in the REYES/hybrid hider and on a dual core with 2GB RAM (my older setup). But if you do want AO on transparencies... or render super high-res... then maybe not.
Either way, again, when you're not using volume cameras but are using anything raytraced (anything!), the raytrace hider will help with performance.
...the long render times were not so much with Lantios' light sets as they were with the others. Both Cloud9 and Skies of Economy do employ a UE sphere for the area lighting along with a "helper" light for the "Sun".
When I re-lit a scene originally rendered with both the Fog Camera and Cloud9 in which I substituted both the Advanced Ambient for the UE sphere and Advanced Distant light for the "helper" it didn't look quite right even though the Distant Light was in the same position and at the same intensity/colour. Most likely this was due to the fact there was no GI component.
The scene did render much faster however (original render time was well over 5 hours using raytracing at 1,600 x 1.050 render size).
I've noticed that turning ray tracing off on transmapped surfaces can give less than desirable results, sometimes making them appear too "flat" (particularly in the case of some hair).
To create the sense of depth in outdoor scenes, I find the fog/volume cameras to be indispensable. The only other solution (as DreamLight never updated Mood Master for Daz 4.x) would be to use something like Nerd3Ds Fog Tool Deluxe which would totally hammer the render time no matter which lighting setup was used.
Key word: "sometimes" ;) Wowie actually enhanced and perfected the geometry shell technique to overcome those "stubborn" cases; this was his first post about it here, and there are others; sorry I just don't have the time to do a thorough google right now:
http://www.daz3d.com/forums/discussion/21611/P345/#554231
Yup, basic fog (for aerial perspective) is very useful. This is why I want to get the RI_Fog up and running with the "scripted renderer".
Kettu, no luck so far in finding how to get Motion Blur to work in the script. There are lines in there for it, but they don't look complete and I downloaded the free 3Delight and looked though the docs but only a mention here and there. My lack of coding knowledge is not helping. I'll have to use Progressive Render in the meantime for the animated scenes that need Motion Blur and take the time hit until it can be figured out.
Wowie, I just figured out what you meant about the hair. I looked at the promo pic and saw it was a male. LOL. There are two sets in that hair... one for male and one for female which is the one I used.
Kyoto Kid, there are big time savings with some transmapped hair sets using the Raytrace Hider. Goldtassel's Sultry hair renders quite quickly and so far renders the quickest of any I've tried so far.
...try rendering the Mentha Piperata hair. The transmapping is so heavy on it it even slows my big system down something fierce when using UE2 (usually crashed on my old 32 bit system). It is also one of the hair props that also doesn't look as "convincing" with the RT turned off.
Mavka hair looks nice but it takes a loooong time to render with the Raytrace Hider. At least 10 minutes, compared to almost 9 tenths faster for Sultry hair. I'm guessing lots of transmaps for Mavka hair.
What we need for motion blur (apart from shutter settings etc) is to get this sort of lines in the RIB:
http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=3860
I haven't looked at the motionblur-related DS scripting documentation extensively yet, but there should be a function to generate these.
The problem is - this function may have been only implemented in DS4 and hence not covered in the DS3 scripting docs... and the DS4 scripting documentation is a WIP.
So there's nothing I can really say about it right now.
Meanwhile, I guess that if your scene permits, you could composite motion-blurred objects over non-blurred ones? I've never done this, but I imagine it might work... the blurred ones may not even need precise GI calculations because they are, well, motion-blurred. So if you render just the blurred objects in a separate pass via progressive, you could use IBL+AO in that pass, hide all the objects apart from the moving one and those it casts shadows on, and set up the surfaces that should receive shadows from that object to have "Fantom" on and "Occlusion" off (via UberSurface). This may (or may not...) save some time.
I was thinking along those same lines, just to save render time in general. Some scenes render very quickly until you put a figure in. Meanwhile the figure separately can render relatively very quickly. Glad to read you think it's a good idea as well!
There is a DiMotionBegin and DimotionEnd is the 3.x Scripting SDK as well as in the 4.x SDK
For your still unanswered question about a RiFog It may be not doable automatically if it doesn't work with DzShaderdescription (didn't try yet). Otherwise you'd need to program a function to get that
Thank you, Takeo.
I don't feel like wrecking my brain over RI_Fog anymore because I discovered this:
- in DS, volume shaders from the Shader Builder are attachable not only to cameras as Atmospheres, but also to surfaces as Interiors (select a surface in the scene and right-click the Builder shader icon!). OMG it works according to RiSpec ain't that amazing?! LOL
I now have a RI_Fog cube that I'm happy with (it can also be moved around so I think it can be stuck outside the room to simulate a foggy day, for instance). I disabled it casting shadows, and also added a rendertime script to make the shader invisible to diffuse rays. Just in case.
Everyone can do the same! =)
And "interior" fog renders without those weird white eyes, even in the progressive mode.
Which means: instead of sweating to make atmospheres work with "scripted renderer", I would rather be sweating to make volume codes work in accordance with the 3Delight guidelines (pp. 35-36 of the manual). Or maybe even not, if Larry Gritz's Noisysmoke.sl works well enough... I haven't yet tried.
Which also means: could we ask AoA to provide an "interior" preset to load his EasyVolume?
I think that writing a preset like this by hand is doable, but too tedious...
That's a good find, Kettu!
@Kettu: Yes and no. Making a cube is a workaround but it is better to have it calculated from the camera view, otherwise you have to adjust the cube position
And p35 is not really volumetric in my view. That is just blending of color and opacity which is very quick to calculate. That's when you begin Ray marching inside that you get on the real thing
For the Rifog by script, you can make it work easily by integrating the parameters inside the script and make a ON/OF Button. That shouldn't take more than a few minutes (max one hour)
About Volume, I was wondering wether it wouldn't rather be better performance wise to make a RSL Plugin called from DS.
You mean like the VolumeTracer they describe on pp.244-248 of the current 3Delight PDF manual?