Rendering 4 scenes at once, best practices
Deadly Buda
Posts: 155
I noticed with Daz 4.10 and 4.11, it was possible to render multiple scenes if you attribute each scene to its own video card (I have 4 video cards in my box). Everything seems to work fine, I'm currently simultaneously rendering 4 different image sequences. Are there any tips to speeding up this process? Should OptiX be enabled?
Also, I am using a Threadripper processor, is this making this go smoothly? Would I have the same luck with a high end Intel processor, or do the multiple cores on Threadrippers somehow get used if you have multiple instances of Daz Studio open at one time?
Is it true you can't have multiple instances of Daz 4.12 open at once?
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
The General Release (4.12.0.86) hasn't chnaged with respect to running multiple instances). The current Public Build (4.12.1.16) is limited to oen instance at a time - however, we know from the change log that theya re implementing a system that will allow multiple instances with each having its own name and settings (which may be copied from another named instance), so avoiding the issues that the existing "system" can cause - but that has yet to be released as a publicly accessible version.
Wow! I can't wait until that comes out!
I really have to wonder if using all your GPU horsepower on a single image series at a time might not be faster.
I suspect interleaving jobs like that is harder work on the GPU command queue, rebinding resources, waiting at fences, setting registers and so on. At the end of the day single and multiple renders still have access to the same number of ASIC blocks and CUDA cores, where most of the work gets done.
For these scenes, nope. 4 cards are not faster than 1. If the resolution was bigger, or the texture maps larger, it would be better with 4. But in this scene I have low textures and 720p output. So its faster to render on 4 different instances.
If you don't mind it would be very interesting to see some specs. For example the rendering time taken over ten frames with separated vs "unified" gpus. Together with vram and ram usage.
As for tips 4.12 always uses optix so you can't disable it. For animation I'd suggest to turn off rendering quality and set the max iterations from 128 to 512 depending on the final quality you need. And use a denoiser as a final pass, either the integrated or an external one.
Hey everyone, thanks for the insight. But, I can tell you why it's currently faster on 4 seperate instances. I have render quality set to .01, textures were reduced 32x with scene optimizer, I'm rendering at 1280x720 and convergence is at 22%. So, once the scene gets to the GPU (1080ti) it renders it in seconds. So, splitting up the scene to distribute to all 4 gpus is basically irrelevant.
The bottleneck seems to be iRay loading up all the objects in the scene... or something...? I'm not really sure what iRay is doing for a full minute getting each frame ready, other than I have a lot of geometry to deal with. There is about 500MB of textures, lights are 10mb and 77mb of geometry.
Iray gets very weird when rendering one image after another. With scenes that small you may not have any issue (600Mb scenes on a card with 11Gb of VRAM) but they do add up and loading each tiny scene onto the card still takes time. All the assets have to be read into system RAM and then transfered over the PCIE bus to the card. As fast as these scenes render it is very possible all 4 cards are competing for the CPU time and RAM bandwidth slowing down loading times pretty significantly.
Why such low quality scenes? Even if viewed at 720p those must look awful.
I believe if you set your viewport to Iray, when you go to render the scene it won't reload it. It should just render it. I got that tip a few years ago from here. I don't know if it's still true.
This is (and always has been - so far as I have been able to determine) untrue. Each and every time an Iray render is initiated (whether via the Render button/menu command or activating Iray liveview in a preview window) texture data always gets reloaded directly from your content library. You can verify this for yourself by performing the following test (adapted from a similar test originally posted here):
What you will find is that the scene renders, but without any visible texture data (eg. character skin now appears white) due to the content library no longer being available. If it were possible for one Context (instance) of Iray to inherit already loaded scene data from another, this visual error would not happen.
ETA:
The reason why people used to think this was true was actually because of spinning HDDs and hardware sleep states. By default, spinning HDDs like to stop spinning when not currently in use. Since various common scene setup tasks performed in Daz Studio do not involve constant reads/writes to disk (eg. character/camera posing) it is not uncommon for a Daz user's content library HDD to have spun itself down prior to a final render being started. Since Iray always attempts to read directly from disk at that point, there is often a signficant added delay (~10 seconds) to Iray's initilization process during which it is just waiting for the HDD to reach full rotational speed.
Activating Iray liveview just prior to starting a final render has the effect of moving that added disk spinup delay to the liveview initalization process. Thereby causing the subsequent final render initialization process to take signficantly less time - despite an identical amount of scene data being loaded from disk each time.
With SSDs this phenomenon goes away completely (because of no spin delay.)
Just doing compostion and motion tweaking with a big scene. These are for test renders.
Hi Robinson, RayDAnt! Thanks for the insight. So I tested this out, and unfortunately RayDAnt is right about the SSD. No speed up by using the Aux view with IRay.
As for daz studio 4.10 and below the textures were reloaded for each frame of the animation and this was reported in the log. Having the viewport in iray mode prevented this behaviour and the textures were only loaded once at the start of the animation, always as reported in the log. As for daz studio 4.11 and above this doesn't seem to be necessary anymore, the textures are always loaded once at the start of the animation. May be this was a iray bug, or may be this was a daz studio bug if it was re-initiating iray for every frame of the animation.
Someone should add a comment to that guy's video! I assumed it didn't work for me because I had a crappy GTX 970 and he was doing it with a couple of Titans.
Here are the results of this test using a short/fast animation seuqence (technically just a static scene stretched out over multiple frames) rather than individual images in 4.10 final:
And here are the results of doing the same again in 4.12 final:
The content library drive was physically disconnected from the system during the rendering of frame 2 (prior to the initialization of frame 3 of 4) in both instances. Notice the missing textures in the final two frames. Even in the case of animation sequences, all versions of Iray in Daz Studio currently available always reload texture data from disk at the start of each and every individual frame/image. Not just once at the beginning of a sequence. Nor in advance by way of leveraging Iray liveview.
I guess this is done because some objects could leave the scene and others enter in later frames but really what a mess. That has got to increase the time it takes to render an animation substantially.
That's odd since the log reports the textures loading only at the start of the animation. I guess either your test may be invalid for some reason (for example iray may just check the texture location with the file system), or the log can't be trusted, that's entirely possible as well. Thank you very much for your tests they are very interesting.
As a side note in my test the task manager reports read activity on disk only at the start of the animation, but it's not a realiable test since the textures may probably be cached. And if this is the case with enough ram it would be the same as loading them once anyway, even if iray itself doesn't.
CPU cache is measure in kb and Mb not Gb. For instance the Ryzen 3000 CPU's have 32kb of L1, 512kb of L2 and 16Mb of L3 (L3 is per 8 core CCX). I strongly doubt all the textures are in that. Any cache on the drive itself should still show as activity but Task Manager, who knows.