In article <36bb7727.2503144@news.povray.org> , pet### [at] usanet (Peter
Popov) wrote:

> Is it possible that, instead of, or in addition to the currently
> implemented average rendering speed indicator of the windoze GUI, a
> current speed indicator (updated every second) is displayed, as well
> as an estimate based on one or both of them (selectable)? With the
> current implementation it is nearly impossible to predict how long a
> picture will take to render if you haven't done a complete render of
> it before (unless you've been raytracing too long :) ). Also, it would
> be useful if, when using mosaic preview, an estimate is made after
> each pass has been finished. Do these ideas seem reasonable? If so,
> are they difficult to implement?

For the mosaic preview part that might be possible (and help to do the
general prediction). Any other prediction of the render time based on the
lines rendered so far (the only "easy" way I can think of) is not very
useful for most scenes. For example you might have just a sky in the upper
half of the image which renders fast, and the, in the lower part you might
have a few hundret glass spheres, using a high max_trace_level and
anti-aliasing the first line that intersect a few of the spheres might take
a few times what the whole image took to the middle...

I usually use a very small preview image (like 32 * 24 for a 640 * 480
image) with the _same_ options I will use for the final image and multiply
the time it took for the small one to estimate the final render. Most of the
time an additional factor of 1.05 to 1.1 is needed to account for background
system tasks etc.


    Thorsten

Post a reply to this message