time remaining on render Indicator Tweet

[spartan00j]

This feature will be in the next major build. It's a simple extrapolation so all of the caveats that @frankmci mentioned will apply - as the render progresses, if different frames take different amounts of time to render, the estimate will change.

Thank you all.
Can't wait

[frankmci]

Sorry, I didn't understand most of what you were saying. But to summon up are you saying that it is impossible? Because it's kind of strange since my using the Google method seems to work great. When come to estimating time.

It boils down to the fact that you (and the render engine) don't know what the future holds, and things may change a lot before the render is done.

Say for example that you are doing a 300 frame crane shot, starting tight on a character's face, then pulling back and up to reveal a wide environmental panorama. The first 100 frames may only take 60 seconds each, but as the camera progresses through its arc, much more geometry, a refracting swimming pool, millions of translucent leaves, volumetric clouds etc. come into view and the render time per frame quickly ramps up to three minutes.

If you are basing the estimate on frames already completed, starting from the beginning, then for the first 1/3 of the render you'll think it will take 300 minutes, when in fact, it will take 900 minutes. The estimate will continue to be way off until the very end, getting longer and longer. If you leave work at frame 80 thinking the shot will be done when you get in the next morning, you will be sadly surprised when it take all of the second day to finish and your customer may be angry at you missing your deadline.

On the other hand, if you render by intervals of 30 frames, then after only ten frames rendered, your estimate is very close to correct and will remain so for the entire process. If you need to deliver the next day, you know you'll need to make some compromises to make the deadline.

This is an overly simplified example, with only two distinct render speeds. The more the render times change within a shot, the harder it is to estimate accurately. Sometimes a random sampling will give you a better estimate faster than even interval sampling, or you need to use a smaller interval that takes longer to give an accurate result. If there is a quick, but highly render intensive element like an intricate explosion, just a few frames in the whole sequence may take longer to render than the entire rest of the shot. If you miss them in your sampling, your estimate will be way off.

If your shot happens to be very uniform throughout, then estimating is easy. If the shot is complicated and variable, it is difficult.

[frankmci]

This feature will be in the next major build. It's a simple extrapolation so all of the caveats that @frankmci mentioned will apply - as the render progresses, if different frames take different amounts of time to render, the estimate will change.

The option of the usual frame sampling methods would be nice, with the understanding that they should only be used for frame independent sequences.

[spartan00j]

Sorry, I didn't understand most of what you were saying. But to summon up are you saying that it is impossible? Because it's kind of strange since my using the Google method seems to work great. When come to estimating time.

It boils down to the fact that you (and the render engine) don't know what the future holds, and things may change a lot before the render is done.

Say for example that you are doing a 300 frame crane shot, starting tight on a character's face, then pulling back and up to reveal a wide environmental panorama. The first 100 frames may only take 60 seconds each, but as the camera progresses through its arc, much more geometry, a refracting swimming pool, millions of translucent leaves, volumetric clouds etc. come into view and the render time per frame quickly ramps up to three minutes.

If you are basing the estimate on frames already completed, starting from the beginning, then for the first 1/3 of the render you'll think it will take 300 minutes, when in fact, it will take 900 minutes. The estimate will continue to be way off until the very end, getting longer and longer. If you leave work at frame 80 thinking the shot will be done when you get in the next morning, you will be sadly surprised when it take all of the second day to finish and your customer may be angry at you missing your deadline.

On the other hand, if you render by intervals of 30 frames, then after only ten frames rendered, your estimate is very close to correct and will remain so for the entire process. If you need to deliver the next day, you know you'll need to make some compromises to make the deadline.

This is an overly simplified example, with only two distinct render speeds. The more the render times change within a shot, the harder it is to estimate accurately. Sometimes a random sampling will give you a better estimate faster than even interval sampling, or you need to use a smaller interval that takes longer to give an accurate result. If there is a quick, but highly render intensive element like an intricate explosion, just a few frames in the whole sequence may take longer to render than the entire rest of the shot. If you miss them in your sampling, your estimate will be way off.

If your shot happens to be very uniform throughout, then estimating is easy. If the shot is complicated and variable, it is difficult.

Okay I understand
Thanks