Time Remaining Estimation for Multi-Frame Renders
Is there a practical way for a Time Remaining estimation for multi-frame renders to be calculated? I know that render time for each frame would vary drastically for some renders where the scene changes a lot. Perhaps Blender could assume that the scene doesn't change, and use (Last*Remaining Frames) and display it as an estimation.
6 Comments
It's a nice idea, but how could it work when every frame could potentially take vastly different amounts of time. For example part of an animation might have no volume, but then after an explosion the render time would increase per frame dependant on volume coverage and settings.
Use a calculator...?
I don't think anyone struggles to do that. But it could be debated that it'd be nice to have it in Blender from the get go.
Brilliant suggestion!
Something I've observed in the past, in software that has this feature: users who have no idea that the estimated time is based on the current frame.
Which often leads to a situation such as: Frame 1 took 2 mins to render. Frames 30-150 takes 20 minutes each to render. Artist then complains that the "time remaining" calculation is completely inaccurate.
Today even single frame render time estimates are horrible.
I made this PR after getting a 4000s estimate for a 40s render: projects.blender.org/blender/blender/pulls/134524
In Cycles, the current estimate assumes that all samples take the same time (false because of adaptive sampling) and that the number of samples to render is known (also false because of adaptive sampling).
I believe using the last frame render time is a lot less bad than what we have now.