Renders taking longer than the estimated time

[Dinkydau]

Hello,

Every times I start a render in Ultra fractal, the estimated time that it would take to finish the render appears to be much less than the actual render time. For example I've just rendered an animation which it said would take an hour to render, but it really took over 10 hours. This happens every time, on all renders, also on images. Has anybody got an idea of what could be the problem?

-Dinkydau

[David Makin]

UF's estimated render time when doing a render to disk is based on the time taken so far.

Consequently with say a zoom animation where you start off at low mag and end up at high mag then the render will take longer than the initial estimate (sometimes a lot longer) because the estimate at any given time is based on renders at lower iteration depths than the remainder of the render.

With static images often the area of highest iteration is in the center of the image so what usually happens here is that initially the render time given underestimates, then at some point through the render it overestimates after which time the estimate reduces.

[bib]

UF's estimated render time when doing a render to disk is based on the time taken so far.

It would be interesting if the estimated remaining time could be calculated based on a trend. For example, if the remaining time decreases only by 0.5 second every second, then the "true" remaining time could easily doubled. That could maybe eliminate the "exponential" effect in deep zooms and give more realistic estimate.

[David Makin]

What if a render starts deep and zooms out ?

[bib]

I though about that as well. At the beginning, of course, the remaining time will be over evaluated. But when reaching a quicker level, the remaining time should decrease by more than 1 second every second, so it still could be useful to calculate a trend and display a more realistic time (the other way round compared to zooming in)

[Dinkydau]

UF's estimated render time when doing a render to disk is based on the time taken so far.

Consequently with say a zoom animation where you start off at low mag and end up at high mag then the render will take longer than the initial estimate (sometimes a lot longer) because the estimate at any given time is based on renders at lower iteration depths than the remainder of the render.

With static images often the area of highest iteration is in the center of the image so what usually happens here is that initially the render time given underestimates, then at some point through the render it overestimates after which time the estimate reduces.

Thank you

So I guess the estimated rendering time is pretty much useless 

[bib]

UF's estimated render time when doing a render to disk is based on the time taken so far.

Consequently with say a zoom animation where you start off at low mag and end up at high mag then the render will take longer than the initial estimate (sometimes a lot longer) because the estimate at any given time is based on renders at lower iteration depths than the remainder of the render.

With static images often the area of highest iteration is in the center of the image so what usually happens here is that initially the render time given underestimates, then at some point through the render it overestimates after which time the estimate reduces.

Thank you

So I guess the estimated rendering time is pretty much useless 

Not totally useless because you can draw your own estimation. For example I have an animation calculating at this time: after 50%, every hour, the estimated time decreases by 10 minutes, and I know that each frame of the second half of the animation should take roughly the same time (+-20%). So my own estimation is 6 times UF's estimation...

[David Makin]

The only way to get a truly accurate estimate would be to render an animation doing one pixel from each frame consecutively and in something like the multi-pass mode, however using multi-pass would be horribly inefficient and doing all the frames like that would be even worse
UF can only estimate based on what's happened up to a given point - if you know that the rest of the fractal is going to be faster or slower then you should be able to guesstimate the actual time required.

For instance consider an animation where the first section zooms-in, then it zooms out then in again - here the estimate by the software is always going to be grossly incorrect at some point however it works out the estimate.

[Dinkydau]

UF's estimated render time when doing a render to disk is based on the time taken so far.

Consequently with say a zoom animation where you start off at low mag and end up at high mag then the render will take longer than the initial estimate (sometimes a lot longer) because the estimate at any given time is based on renders at lower iteration depths than the remainder of the render.

With static images often the area of highest iteration is in the center of the image so what usually happens here is that initially the render time given underestimates, then at some point through the render it overestimates after which time the estimate reduces.

Thank you

So I guess the estimated rendering time is pretty much useless  

Not totally useless because you can draw your own estimation. For example I have an animation calculating at this time: after 50%, every hour, the estimated time decreases by 10 minutes, and I know that each frame of the second half of the animation should take roughly the same time (+-20%). So my own estimation is 6 times UF's estimation...

Yes but I'm not an experienced Ultra fractal user and I'm very bad at guessing . Maybe if I make some more animations and images in Ultra fractal it will be easier to guess the rendering times based on what the computer thinks. You're right, there.

[lycium]

given an estimate of the higher derivatives d^n(Progress)/dT^n one could extrapolate using a 2nd, 3rd etc order formula

actually, giving more "sensible" values for the ETA isn't all that difficult if approached properly - which no one does! i'm sure many of us have seen what sometimes happens with windows file copy dialogues, when it says something like "4576458234564 seconds remaining"