I would like to request that Povray state the frame number in an animation in
the status bar and title bar. When I run animations, unless I keep careful
track, there's no obvious or trivial way to tell (without maybe digging through
the messages window) which frame in the sequence the program is currently
rendering.

-Mike

Post a reply to this message

"SharkD" <nomail@nomail> wrote in message 
news:web.486c23a336d6ae943cc4f9660@news.povray.org...
>I would like to request that Povray state the frame number in an animation 
>in
> the status bar and title bar. When I run animations, unless I keep careful
> track, there's no obvious or trivial way to tell (without maybe digging 
> through
> the messages window) which frame in the sequence the program is currently
> rendering.

also, I would like to request the possibility to show an approximation of 
how long the render will still take.  I know it wouldn't be accurate, but it 
might give just an idea of how long we still have to wait for our reflective 
spheres :)

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen wrote:
> "SharkD" <nomail@nomail> wrote in message 
> news:web.486c23a336d6ae943cc4f9660@news.povray.org...
>> I would like to request that Povray state the frame number in an animation 
>> in
>> the status bar and title bar. When I run animations, unless I keep careful
>> track, there's no obvious or trivial way to tell (without maybe digging 
>> through
>> the messages window) which frame in the sequence the program is currently
>> rendering.
> 
> also, I would like to request the possibility to show an approximation of 
> how long the render will still take.  I know it wouldn't be accurate, but it 
> might give just an idea of how long we still have to wait for our reflective 
> spheres :)
> 
> cu!

Actually, I bet POV could do a fairly accurate approximation by first 
shooting one ray from each block, and figuring the speed based on those 
tests.  That is, by sending out those test rays, it would know (roughly) 
how long each block should take, and so could approximate the final 
render time.

...Chambers

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Actually, I bet POV could do a fairly accurate approximation by first 
> shooting one ray from each block, and figuring the speed based on those 
> tests.  That is, by sending out those test rays, it would know (roughly) 
> how long each block should take, and so could approximate the final 
> render time.

  Too complicated. Much easier is to simply update the estimated time after
each block has been rendered with a simple formula like this:

ETA = total_blocks * time_so_far / bloks_rendered

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Too complicated. Much easier is to simply update the estimated time after
> each block has been rendered with a simple formula like this:
>
> ETA = total_blocks * time_so_far / bloks_rendered
>
> --
>                                                           - Warp

A lot of times, the first and last few blocks render much more quickly than the
middle blocks if they are composed of mostly empty space.

-Mike

Post a reply to this message

SharkD <nomail@nomail> wrote:
> A lot of times, the first and last few blocks render much more quickly than the
> middle blocks if they are composed of mostly empty space.

  No matter what you try to do, the estimation will always be off.
However, a simple algorithm like I described is very easy to implement
and contains basically no overhead whatsoever, and may be more useful
than nothing.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> SharkD <nomail@nomail> wrote:
>> A lot of times, the first and last few blocks render much more quickly than the
>> middle blocks if they are composed of mostly empty space.
> 
>   No matter what you try to do, the estimation will always be off.
> However, a simple algorithm like I described is very easy to implement
> and contains basically no overhead whatsoever, and may be more useful
> than nothing.
> 

In fact, if the blocks are rendered in random order (rather than across 
rows like they are now), then area locality would have less of an effect 
on the estimate, making it more accurate.

That is, many times local blocks have correlated render times, while 
blocks that are separated by some distance have unrelated render times 
(much like the Noise3D function that I'm so fond of :) ).  During tough 
patches, the render time will be overestimated.  The corollary is that 
in fast to render areas, the render time will be underestimated.  This 
is compounded by having several slow-to-render or quick-to-render blocks 
in a row.  Randomly picking between the blocks will alleviate this 
(although I don't know what effect it will have on Radiosity).

...Chambers

Post a reply to this message

Zeger Knaepen wrote:
> also, I would like to request the possibility to show an approximation of
> how long the render will still take.  I know it wouldn't be accurate, but
> it might give just an idea of how long we still have to wait for our
> reflective spheres :)

I wrote a GUI extension for that :)

Post a reply to this message