I’m running Blender 2.63 release candidate on OSX 10.7
I have a project that involves some huge textures (20k pixel resolution blue marble earth imagery). Amazingly, cycles handles it like a champ, and i was able to design the shaders with cycles updating the viewport interactively.
But as soon as I go to do the actual render, cycles appears to reload every single texture, on every single frame with the message “updating images.”
This texture reloading almost doubles the rendertime; and i’m not sure why its necessary, as i can scrub the timeline, move objects, modify materials etc and the viewport updates without any delay.
I also noticed it updating the BVH on every frame, despite having cache BVH checked in the render panel. Again, when scrubbing the timeline the viewport render doesn’t seem to suffer the need for this recalculation?
Is there some toggle that i’ve foolishly bumped or anything anyone can think of for why the final render has all these pre-processing steps that don’t seem to be needed to render the same image in the viewport?
Thanks for any suggestions!
I think the BVH cache only works if the geometry in your scene is static. Does your scene have a moving camera and moving objects?
nuts. the earth is rotating, yeah.
but regardless, there is definitely a missed opportunity for some sort of optimization in the final renderer that is already being used in the cycles viewport rendering mode. when i initially turn on the viewport render, it does all the image loading and bvh calculations, and the viewport render time matches the final output render time. but from there, you can scrub the timeline and all subsequent frames will immediately start rendering, regardless of whether objects have moved or deformed. in a texture heavy project like the one i’m doing, this would literally cut the per frame rendertime by more than half, and so far as i can tell, the output is identical.
Another problem is, that cycles loads ALL texture, even if i render only a specific layer.
Yes, when I have file with a lot of linked materials and only one of them is assigned to only one object, then Cycles loads all of them to memory with long time.
I think it should be changed, Cycles should load only used materials and textures. It could save much time.
This is a great thread. You guys have nailed the biggest problems Cycles for animation has right now. All of these frustrate me endlessly, although I try not to think about them. What can you do?
Still, I seriously hope they fix all of these things. I can’t believe that every issue thus named in this thread is not tops on their “Things that Cycles will no longer do in it’s Finished Ideal Version”
It’s a great engine. If they fix these things, it will go from a cult to a legend overnight.
And, yes, getting rid of these problems would cut animation rendertime in half, thus removing Cycles’ worst Achilles’ Heel: rendertimes.
oh gosh i am so happy to see people taking note of these “opportunities for optimization”
is this the type of thing that could be submitted to the bug-tracker? i mean nothing is “broken” per se, i just can’t for the life of me think of any logical reason why the viewport renderer can immediately update on frame changes just fine while the output renderer requires the re-loading of assets.
likewise, the optimizations jachtarfranko mentioned might require some additional coding, but i don’t think there is any technical reason it wouldn’t be possible?
the potential benefits for production work would be so great, i would happily donate to see a developer tackle them, similar to the ocean sim or open cl compositor fundraising campaigns.
I had same problem. But in the current Blender is settings: Performance > Final Render > Persistent Images. It fix trouble with load all texters every frame.
Can someone explain why this option isnt on by default?
Now I know When I render heavy scene with GPU it crash with “No memory” problem. It doesn’t happen with disabled “Persistent Images” . It is strange, because scene use same textures every frame, but memory is growing.
MMmm, you know, come to think of it, since I started enabling it these past couple of days, my blender has been crashing in the middle of renders.
“8 Years Later” lol… There needs to be an adaptive feature for this. Only reload images that need reloading (such as image sequences or videos, etc.) and those who do not change such an image textures should always simply remain cached. Blender KNOWS the difference. Why can’t Cycles know it too?
Every other render engine I have used had this problem solved many years ago. For me it’s usually just a matter of 1-3 seconds spent loading images because of my habit to create nicely packed atlases beforehand in formats that load quickly, but please. This still makes especially path-traced previews with Cycles, which are a vital part of any full 3D production, extremely sluggish, even when you have many GPUs…
Time is money. You’re probably paying for this down-time when you’re paying for a render farm job.
I dont even get why it needs to reload images if there are not an image sequence. I mean, that already means its a static image and thus does not change over time.
Im seeing issues where with persistent data ON, my GPU hits the MAX. But when its OFF its renders fine. Super weird
I think i post a bug report. Its bl3.6.1