any new suggestions for staying under the limit in animated renders
WendyLuvsCatz
Posts: 41,269
I am circling the drain near the limit of my VRAM
it renders, for up until 60 frames last run
previous runs were 43 and 35 respectively
once it decides it's going to hit my limit and stop because dropping to CPU is definitely not an option so disabled
the only option is to restart Studio and proceeding from the frame I left off
I do want to avoid the obvious solutions of dropping to base resolution, removing or reducing texture maps
already optimised much, the fact it can render the images until it cannot is what irks me
what pushes it over the edge after up to 60 frames
removing things from the scene in most of these cases no difference whatsoever to the VRAM used too
it just uses the maximum it can but takes less time to do it
I am looking for new suggestions I haven't thought of that consume VRAM or rather intermittently do so pushing my render over the limit and point of no return
I suspect it's something Windows is doing outside of studio taking away VRAM
I am logging to file with GPU-Z also this run to see if I get any insights
smaller images is also not a solution, it's faster, much faster to go 760p instead of 1080p, but it just reaches the final destination of running out of VRAM quicker
for now I am plodding along restarting studio and continuing on
I did notice this next run of 50 frames since I posted this, it just sat at 10580MB of VRAM without any GPU activity and the render dialogue still open, I cancelled and it hung onto the VRAM, my trick with single images of switching to CPU and unchecking my GPU to free the VRAM doesn't work with animations. Even upon canceling before it drops out.
It can actually hit 11000 without topping out and never actually does according to the log
11200 is the absolute limit, 1 have a 2080Ti
there are no dforce simulations in the scene
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
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
You ask if there's something more without telling what you already did. However, one thing that comes to mind is disabling the denoiser, that you didn't mention you don't want, and can reduce vram usage. Another thing is "ray tracing low memory" in the render settings, if you didn't.
Personally I don't have this limit you mention, if a scene fits the vram I can go on rendering forever. You could try a couple tests to eventually identify the culprit. Start with a simple scene then add elements.
p.s. If you use extra plugins that's another thing to look for, as plugins may have memory leaks.
p.s. Keeping your viewport as "wire bounding box" will avoid stealing vram while rendering, if you use the same card for rendering and the viewport.
I need denoiser sadly as full of emitters for glow, not actually lighting so using sun/sky only
they still add noise though
my frames are 20 samples with denoiser from frame 0
the first up to 50 frames render fine
I always have the viewport as wire bounding box when rendering to file
am actualy eyeing off my antivirus
already not doing anything else especially browsing,
scenes well below that's never an issue and animations complete
it when it's to the wire with only 600ish MB of VRAM to spare this becomes a problem
I am rendering this scene
it is a lot, I usually do backgrounds and characters separately so don't have this issue either
Luthbell's outfit plus the Xi Steampunk Slums is a very big ask
still want to solve it
am trying earlier versions of D|S now
additional scenes for this video will be separate backgrounds and foreground
just finishing this 8 second shot ... slowly
you can render without the denoiser and then use this script that was also talked about in another thread (don't have that link handy) but everything you need is here:
https://taosoft.dk/software/freeware/dnden/
then you can drag and drop your frames here (you can select more than 1 at a time) and it will batch denoise them afterwards saving you quite a bit of vram memory during your renders, i've been doing this and it works great.
I could give that a try again if all else fails
did use it in the past but preferred the D|S denoiser
am actually watching my render and GPU-Z now to see when it happens
also using an earlier version of studio without the latest plugins I bought installed
saves disabling them, in case that's an issue
I also am forced to use an older Nvidia driver anyway which could too be an issue with later builds as I have other older expensive software (Octane Render4, iClone6) that doesn't like the latest ones
I also went through TaskManager and killed Microsoft Edge processes, news etc and a few other programs like Everything
Sharing my render settings if it can help. They work fine for me. However filling the vram to the top is always a risk, better leave some spare space. I'm curious how you render the background separately, I may have something to learn here, apart if you just compose.
just compose and what I do 90% of the time
I will look when I can but mine are pretty low and usually fast as in 6 frames a minute
this scene is a frame per minute
my older saved version of D|S, last with the 3Delight engine (irrelevant but reason saved) is so far going well but probably jinxed that by saying so
I have added Ultrascenery 2 to the latest among other plugins I don't have in this one I am now using
the logical thing is leave plenty to spare and I do mostly
just want to know why after rendering 50 odd frames perfectly it suddenly gives up
it stopped immediately after I posted this on my iPad
update
having denoiser not enabled actually makes no difference to my render or the VRAM or time taken
but will see if it helps it keep rendering
Padone, your settings not much different to mine except less samoles and small dimensions, mine are pretty much draft anyway
it did, I got it to render almost 3 hours
90 frames
it stopped 8 frames short of completion
no obvious reason
anyway done with that scene, will composite rest of my video
I'm confused. Render in batches. Only do frames 0-19. Then do frames 20-39. Etc.
If you have render queue, have it restart Daz between renders.
I don't have render queue
and I have no way of knowing when it will fail
D|S has to be totally shut down and restarted because it won't let go of the VRAM
i think the DnD denoiser can be configured to use the same denoiser as Daz (your Nvidia GPU). Mine is set to only use Nvidia denoiser, so I assume this is the same denoiser that happens if done in Daz on your GPU. I could be wrong, but I can't tell a difference between the two when I set like this. Anway, glad it worked for you.
Solution for rendering extensive animations:
Don't use Daz; use Unreal, Unity, or AI.
You can limit the number of frames to rnder in Render Settings, Just do a safe (at a guess) number of frames, restart DS, do the next batch of frames, and so on.
well this is in effect what I was doing except when it stops rendering instead of possibly before
I guess the only thing I can take away from this is treat my VRAM limit as 10GB in D|S
and,jeronimocollares, I do use other software a lot too
rendering the rest as mp4 backgrounds in Twinmotion and just my characters with matching EXR panoramas for lighting in DAZ
Bit late to the party and a weird suggestion perhaps, but have you tried using iRay Section Planes? Especially since you mentioned the environment you're using is rather large and heavy. Using iRay Section Planes, might limit what is sent to your GPU resulting in less VRam usage.
If you're unfamiliar with section planes, they are basically infinite rectangles that "remove" everything that's behind them from the render. So if you have a large or complex environment you could place them near your camera FOV edges and just cut everything off that isn't in view or behind the camera (and technically even everything that is too far in the distance, but that could be tricky)... I think they also have an option to still block light so the parts that are cut off don't suddenly change the lighting of your scene.
Another thing you could try is using Scene Optimizer, but I personally have no experience with that yet. Also technically lowering the texture compression threshold values in the render settings for medium and high might help (something like 512 / 1024 or 1024 / 2048), but that will also result in slightly lower quality textures (which might be visible or not) and might slow the render down.
A suggestion that was made to me - render the background as an HDR then apply the figures to that and animate them? Don't know if that would work for you?
The question I have with all of these suggestions is... why do we need to find workarounds at all? This was not necessary two years ago. Why do we now have to "re-set" the Vram? What is new and improved about DS that warrants needing to let the VRAM "build up"? I don't know enough about the nuts and bolts of DS, or computers in general, to understand what is actually going on; the only fact I know is that I used to be able to render out 1200-2400 frames overnight, no problem, and now I cannot. If there was something about DS that you could point to and say, "it is needed so you can have this improvement or that improvement", I could understand the change. You are giving something up to get something else, but I don't see what that is. All I see is the functionality of the animation side of DS taking two steps back. And that is too bad, because I thought DS was a great entry-level program for people to get their feet wet in animating. Would this have anything to do with the automatic save feature that is now available? I'm that guy who always wants to see what is new and shiny and have it as soon as possible, but this is one time I wish I could roll back my DS. I will admit that this could be an Iray issue and I am just not smart enough to understand the difference. But if there was a DS where Vram was released after a render WITHOUT having to close down DS...let's go back to that.