I wrote:
> Therefore, if you want to perform calculations across multiple frames,
> you either have to recalculate the necessary information for each frame
> (using the current clock value) - this is the method I use in my
> Explosion and Liquid Spray include files - or, you can save and read the
> values of the variables, as you suggested.

Greg M. Johnson wrote:
> Thanks for the tips! Is there an easy way to decide the number of
> iterations I want the animation to go through?  Suppose I want to test
> it at 15 frames several times, then go to 150 frames.  I'm wondering if
> I would have to do a whole bunch of retyping in several places in order
> to key my while statements with the number of frames.
> 
[and a few other things, not important to the current discussion...ie.
snip!]

Obviously, the number of frames you use with an output-input method as I
described above is going to effect the resulting animation.  This is one
of the reasons I decided to use the first method I described, ie.
recalculate all the necessary data for every frame.  The
advantages/disadvantages of both techniques, as I see them, are:

- recalculation means any arbitrary frame can be rendered in isolation,
allowing stills and animations to be produced;

- depending on the maths used, recalculation is probably more accurate,
eg. for a collision detection system, it might be possible to
accidentally miss a collision if you use input-output;

- for all its advantages, recalculation might be slower than
input-output; in some cases, however, it might actually be faster (eg.
if you render 100 frames, and then decide you want 200 instead, you
would only have to recalculate the extra 100 frames - with input-output,
you would need to start from the beginning again);

- recalculation gives consistent results, no matter which frame you
render or how many frames you render (ie. exactly the problem you raised
in your question above).

As for a solution to this last problem - POV-Ray 3.1 now offers the
clock_delta variable, so a script can know the frame rate of the
rendered animation.  This way, it should be possible to perform some
kind of interpolation, giving a consistent result.  Even so,
input-output will probably not be as accurate as recalculation, unless a
suitably large number of frames are rendered.  (In POV-Ray 3.0, the
clock_delta could be replaced with a user-declared frame_count variable,
so only one option need be changed.)

I seem to remember that your original question related to a flocking
animation - I imagine either of the above methods would be suitable, if
they are well-coded.  For a great example of the input-output method
(using POV-Ray 3.1), you can take a look at Mikael Carneholm's new Smoke
Generator:

   http://www.studenter.hb.se/~arch/smokegen/smokegen.htm

And, of course, my own recalculated efforts can be found at:

   http://www.geocities.com/SiliconValley/Lakes/1434

Should you have any questions about any of the files you find there,
feel free to grill me by email at your discretion...

Post a reply to this message