time remaining on render Indicator

[spartan00j]

Is there a way to see an ETA on my renders?
Instead of seeing how many seconds one frame takes to render and asking Google to multiply that by how many frames I have.

[spartan00j]

So Is there anyone that can answer?
If this is not possible please let me know

[spartan00j]

It's been 8 months.
No reply?

[jobigoud]

It's not currently available but I agree it would be nice to have at some point. I was wondering the same a few days back.

[nuno1980]

Why do you need this topic? But Octane Render ALREADY has the estimated time for completion (check "Render progress indicator"), ok?

[jobigoud]

Say you start a render job in the evening. It only tells you the estimated duration and only of the current frame. It would be convenient if it directly told you that the ETA for the whole job is at 4 PM the next day for example.

[spartan00j]

Why do you need this topic? But Octane Render ALREADY has the estimated time for completion (check "Render progress indicator"), ok?

I guess you didn't read my initial post correctly. What you're stating only shows the duration time of one frame. If I have 1,000 frames. And each frame takes 1 minute. The standalone should tell me. A render of a thousand frames will be completed in 16 hours and 40 minutes.
The point is that the plugins do this. But the Standalone for some reason doesn't.

[frankmci]

When you are rendering linearly through a sequence, there is no way to make a good prediction, because the image contents and frame render times can change drastically from beginning to end. The way we used to do it is run renders non-linearly, either random frame jumping, or repeated sparse sampling - rendering all the way through, but skipping 30 frames each time for instance, then going back and doing it again 29 more times. This gives you a pretty accurate estimate the whole job instead of trying to extrapolate from the first few frames.

This method doesn't work for all renders, though, since frame C may depend on information from frame B, which depends on frame A, etc.

A method I sometimes use is to render the whole animation at full quality, but at a much reduced resolution. Extrapolating from that can be pretty accurate, as long as the overhead for each frame isn't a significant chunk of render time. Even then, if you know the overhead, which parts are linear and which parts scale non-linearly (such as reading data vs writing/compressing etc.), you can subtract that and still get a reasonable estimate.

[spartan00j]

When you are rendering linearly through a sequence, there is no way to make a good prediction, because the image contents and frame render times can change drastically from beginning to end. The way we used to do it is run renders non-linearly, either random frame jumping, or repeated sparse sampling - rendering all the way through, but skipping 30 frames each time for instance, then going back and doing it again 29 more times. This gives you a pretty accurate estimate the whole job instead of trying to extrapolate from the first few frames.

This method doesn't work for all renders, though, since frame C may depend on information from frame B, which depends on frame A, etc.

A method I sometimes use is to render the whole animation at full quality but at a much-reduced resolution. Extrapolating from that can be pretty accurate, as long as the overhead for each frame isn't a significant chunk of render time. Even then, if you know the overhead, which parts are linear and which parts scale non-linearly (such as reading data vs writing/compressing etc.), you can subtract that and still get a reasonable estimate.

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.

[karl]

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.