I would like to know why Blender flushes the memory all the time. I loaded the barbershop demo file. It takes about 6.8 gigs of memory. I render in the viewport in Cycles. It load everything and the memory goes up to about 10.6. If I go back to wireframe display, the memory shrinks back to 6.8. Back in render mode, it reload everything again. If I also render an image in the viewer this time, it will double the RAM usage by loading again the exact same stuff it already has in memory, now at 17 gigs. I have 64 gigs of RAM. I could keep all that information in memory and time to first pixel would be greatly reduced. I think Blender should keep textures and geometry in memory as long as there’s space to keep them. Flush it as needed, not automatically as soon as your render is done. If I only make a small change in let’s say a procedural texture, why would the renderer need to reload everything? And if I change one or several textures or geometry, only the ones that have been modified should be reloaded. It’s even the case when you render an image sequence. For every single frame, everything gets reloaded. Even if only the camera moves. I’m not a programmer so that’s why I would like to know why Blender does that. Renderman and Arnold don’t behave that way. It’s fine if you don’t have a lot of RAM but when you do, maybe an option to keep everything in memory would be of great help. Cheers
Anybody home? Surely someone could answer this. Right now I’m dealing with a 1.2 gig file. It’s hell every time I want to render a frame.
Maybe @dfelinto can point this to the correct person to give a proper answer
Earth calling @dfelinto.
Hello, we have the same problem currently at our studio. Blender flushes textures from the memory. 8GB worth of textures being constantly pulled from the server.
Recently because of the pandemic I have to work via remote connection from home. It is quit a long pause for me whenever I have to start a new test render and download all of the unchanged textures to check the compositing output.
Setting “Texture Time Out” to 0 in the preferences and turning on the “Presistant Images” in the render settings doesn’t do much for this problem.
We have been considering a switch from Maya + Arnold to Blender + Cycles. Everyone at our studio noticed the responsiveness of Cycles in viewport, powerful node system and the real speed advantage in relation to other above-mentioned render engine, in terms of raw render times for the same scene. But this issue is really holding us back. It would be very helpful if Cycles would have an option to cache unchanged textures. For bigger projects this would be literally a timesaver.
Maybe @dfelinto you could throw your two cents on this topic.
I’m testing the “persistant image” option and it seems to work fine with cycles. I’m rendering an environment with a huge pano (180x4K) and blender nows renders frames back to back very smoothly.
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Oh wow! Awesome! I will test it right away. Thanks.
Maybe someone could clear it up. I run into an issue when using Persistant Data on the latest 2.93.
I have tried to render an animation with a character which is driven by the armature rig. While textures remain in the memory, which made it really fast to render, there were no BVH updates per frame and the character didn’t move. Only the eyes, which are separate geometry parented to the bone, moved according to the animation.
This doesn’t happen, if the Persistent Data setting is off. The animation is rendered correctly, but textures keep loading/flushing again on every frame.
Is this the expected result? Changed geometry is not going to be updated when rendering an animation?
Seems like this is already filed as https://developer.blender.org/T87295
Thanks you @deadpin!