Estimated remaining render time
Imagine you are rendering an animation for a client project. You have 300 frames to render, and each frame is taking about 2 minutes, or more.
With the current system: After 1 hour, the display might only show "Elapsed Time: 01:00:00." You have to manually calculate: you've completed maybe 30 frames, so you have 270 left. 270 frames * 2 minutes = 540 more minutes, or 9 more hours. This requires mental math and guesswork.
With the proposed system: After that same hour, the display would clearly show:
Elapsed Time: 01:00:00
Remaining (est.): ~09:00:00
Overall Progress: 30/300 Frames (10%)
Last frame : 02:02
This immediate information allows you to confidently manage your schedule. You could decide to let it run overnight, pause it to adjust settings for efficiency, or inform your client of the precise expected delivery time—all without needing to stop and calculate. It transforms the render process from a blind wait into a predictable task.
5 Comments
It's quite hard to predict render times in animation. The camera could pan halfway from a single diffuse shader to many complex SSS/Glass materials or heavy geometry that throws away any prediction.
The best is for the user to render a low-sample/low-resolution animation and try to extrapolate from that.
Exactly this. Blender only has awareness of how long the last frame took. It has no way to know how long the NEXT frame will take.
The fact that a particular scene might have all the same render times for each frame is situational and incidental.
All this is all true. Not to mention other variables like your electricity power source and computer's PSU quality, temperature variations in the room and your hardware's cooling capabilities, Windows deciding to do something you didn't ask in the background but absolutely takes resources away or even reboots for an unrequested update...
That being said , it would still be useful to have a prediction of remaining render time based in remaining frames and average frame render time so far. It would still be a crude approximation that can't be trusted unless you know your scene to be pretty constant across all frames. It's not every scene, but it's still something. It's better than nothing. (While we're at it, showing the average frame render time in the current sequence render job would also be nice).
I believe the potential downside is thousands of new users hitting forums and bug reports with "blender said my render would take 20 minutes, and it's now been 5 hours."
Every computer and phone has a calculator app. It's trivial to type "300 (frames) * 140 (seconds) = that's how long you can estimate" if you really want to know that number.
How likely is that scenario to happen, at that scale? People are frequently presented with an estimated time and do not take it as "guaranteed time" ; from the basic "copy a bunch of files on your computer", to your food delivery app.
The only real systematic complaining happens when you fail to communicate it being an estimate or when there's urgency (but then, it would be worse without guesstimate). It's not a new notion that people have never seen or heard of before, and I doubt a significant amount of people will suddenly flood the bug reports inquiring why renders don't take as long as the estimated time.
Even if a basic estimation based on last frame render time is accessible, it still is a nice QoL to have, and having Blender do it would allow an estimation based on the average frame render time so far, which I would argue to be a bit better.