The first frame is a doozy!

For an animation of 100 flocking objects,  I first create an INC with an
array of 100 actors x 6 coordinates x 375 time periods.  I then read the
INC to make my animation.  As the animation starts up, there are 100
actors in the first frame, 200 in the second, up to 2400 in the 24th,
with 2400 thereafter.  The animation in effect makes 100 growing sea
snakes which have reached maximum length at frame 24.

If I just start up naturally, the first 24 frames take longer and longer
to trace: an average of about 6 extra seconds per frame. One might think
this were reasonable, as I'm adding 100 new objects in each frame...  An
overnight render was once taking 7 minutes per frame after about a
hundred or so frames!

Then I got the idea of stopping and restarting the animation after about
the 4th frame.  Now, every frame takes about 4 seconds, with no increase
in render time with increasing objects, and at worst 8 second render
time by the 375th frame!  I also noticed that once I've done the stop at
frame 4, further stopping provides no benefit!

Doctor, give me the news. Do these data provide any hints at making a
small tweak to povray 3.1h to fix this animation slowdown without a
total rewrite from scratch? Is it making some BS calculation in the
first frame that uses up gobs of memory and is not really needed?  The
problem is in the first frame, it seems.   Apologies if this is a dumb
question.  Povray is the only language I'm fluent at; I know more about
chip attach and substrate ceramic materials science than I do about how
computers "actually work."

Post a reply to this message

On Mon, 16 Aug 1999 08:55:44 -0400, Greg M. Johnson wrote:
>Doctor, give me the news. Do these data provide any hints at making a
>small tweak to povray 3.1h to fix this animation slowdown without a
>total rewrite from scratch? Is it making some BS calculation in the
>first frame that uses up gobs of memory and is not really needed?  The
>problem is in the first frame, it seems.   Apologies if this is a dumb
>question.  Povray is the only language I'm fluent at; I know more about
>chip attach and substrate ceramic materials science than I do about how
>computers "actually work."

There was a discussion in c.g.r.r. about this a few months ago.  The 
consensus in that case was that if you start with an empty frame and
build up to frames with many, many objects, POV gets confused when it
determines its bounding parameters (By default, automatic bounding is 
disabled when you have fewer than 25 items in the frame.  It has been
determined empirically that this means fewer than 25 items in the FIRST
frame.)  One way to override this is to put +MB0 on the command line
or in the render options dialog.

However, you say you have 100 elements in the first frame, so this may
not apply.  There may be other parameters that are set the same way,
however.  One way to check is to add a thousand or so invisible objects
(out of view of the camera, and well-bounded) to the first frame and see 
if it changes the nature of the problem.  If it does, compare the render
statistics for the frame with and without the invisible objects and see
if you can find out what's making the difference.

Post a reply to this message

Well, I oversimplified my description a bit.  I think it actually is
frame 1: fog +  0 objects
frame 2: fog + 100 cylinders
frame 3: fog + 200 cylinders
frame 4: fog + 300 cylinders.
.. reaching a maximum number of objects of 2400 at frame 25, I guess.

Perhaps I just need to put those 100 cylinders in the first frame!!  Thanks,
will try. . .


Ron Parker wrote:

> There was a discussion in c.g.r.r. about this a few months ago.  The
> consensus in that case was that if you start with an empty frame and
> build up to frames with many, many objects, POV gets confused when it
> determines its bounding parameters (By default, automatic bounding is
> disabled when you have fewer than 25 items in the frame.  It has been
> determined empirically that this means fewer than 25 items in the FIRST
> frame.)  One way to override this is to put +MB0 on the command line
> or in the render options dialog.
>
> However, you say you have 100 elements in the first frame, so this may
> not apply.  There may be other parameters that are set the same way,
> however.  One way to check is to add a thousand or so invisible objects
> (out of view of the camera, and well-bounded) to the first frame and see
> if it changes the nature of the problem.  If it does, compare the render
> statistics for the frame with and without the invisible objects and see
> if you can find out what's making the difference.

Post a reply to this message

On Mon, 16 Aug 1999 10:06:45 -0400, Greg M. Johnson wrote:
>Well, I oversimplified my description a bit.  I think it actually is
>frame 1: fog +  0 objects
>frame 2: fog + 100 cylinders
>frame 3: fog + 200 cylinders
>frame 4: fog + 300 cylinders.
>.. reaching a maximum number of objects of 2400 at frame 25, I guess.
>
>Perhaps I just need to put those 100 cylinders in the first frame!!  Thanks,
>will try. . .

Failing that, just put the +MB0 on the command line.  It'll have the same
effect.

Post a reply to this message

With a two keystroke modification to my file using Ron's advice, I fixed the
problem.  Now there are 100 cylinders in the first frame, and the tracing time is
3.0 s, very gradually increasing to ~8 s by the last frame.

Thanks.

Ron Parker wrote:

> On Mon, 16 Aug 1999 10:06:45 -0400, Greg M. Johnson wrote:
> >Well, I oversimplified my description a bit.  I think it actually is
> >frame 1: fog +  0 objects
> >frame 2: fog + 100 cylinders
> >frame 3: fog + 200 cylinders
> >frame 4: fog + 300 cylinders.
> >.. reaching a maximum number of objects of 2400 at frame 25, I guess.
> >
> >Perhaps I just need to put those 100 cylinders in the first frame!!  Thanks,
> >will try. . .
>
> Failing that, just put the +MB0 on the command line.  It'll have the same
> effect.

Post a reply to this message