Does POV-Ray initialize all variables between frames?  Can any variable
declarations made at the "end" of the processing of one frame be
available at the beginning of the next frame?  Does information "build
up" and make the last frame render more slowly than the first?

The implications are twofold:
1. In planning a flocking animation, I would want data from one frame
available to the next. I could avoid installing POV 3.1, with its read &
write capabilities, if there were some other way to let data hang
around.
2. I'm currently making a 250 frame animation.  The render time near the
beginning was 18 minutes/ frame.  Each frame takes progressively longer,
and at frame 170, I'm up to 27 minutes per frame. The October 15th IRTC
deadline is fast approaching!  While it's possible that more complex
effects exist at the end of the animation, I am wondering if I might be
able to finish this whole thing more quickly if I were to stop and start
the whole thing again at the current frame.

____________________
Greg M. Johnson
http://members.xoom.com/gregjohn

Post a reply to this message

I've noticed this effect with animations before as well.  As far as I know
this is unique to windows, but don't quote me on that.  I think it has
something to do with windows and its memory management, but I don't know.
Pov doesn't keep variables alive between frames.  That was the main reason
for adding the file reading and writing ability.  If you are using pov for
windows, and you really don't want to install pov 3.1, you can still do
reads and writes to files through a few tricks with stream redirection.  You
can probably find more info on that somewhere on this news server, otherwise
I can post a quick explanation or example.

Ken

Greg M. Johnson <"gregj56590:-)"@aol.com> wrote in message
<361CF888.6A9B2D3E@aol.com>...
>Does POV-Ray initialize all variables between frames?  Can any variable
>declarations made at the "end" of the processing of one frame be
>available at the beginning of the next frame?  Does information "build
>up" and make the last frame render more slowly than the first?
>
>The implications are twofold:
>1. In planning a flocking animation, I would want data from one frame
>available to the next. I could avoid installing POV 3.1, with its read &
>write capabilities, if there were some other way to let data hang
>around.
>2. I'm currently making a 250 frame animation.  The render time near the
>beginning was 18 minutes/ frame.  Each frame takes progressively longer,
>and at frame 170, I'm up to 27 minutes per frame. The October 15th IRTC
>deadline is fast approaching!  While it's possible that more complex
>effects exist at the end of the animation, I am wondering if I might be
>able to finish this whole thing more quickly if I were to stop and start
>the whole thing again at the current frame.
>
>____________________
>Greg M. Johnson
>http://members.xoom.com/gregjohn
>
>

Post a reply to this message

Greg M. Johnson wrote:
> 
> Does POV-Ray initialize all variables between frames?  Can any variable
> declarations made at the "end" of the processing of one frame be
> available at the beginning of the next frame?  Does information "build
> up" and make the last frame render more slowly than the first?
> 
> The implications are twofold:
> 1. In planning a flocking animation, I would want data from one frame
> available to the next. I could avoid installing POV 3.1, with its read &
> write capabilities, if there were some other way to let data hang
> around.
> 2. I'm currently making a 250 frame animation.  The render time near the
> beginning was 18 minutes/ frame.  Each frame takes progressively longer,
> and at frame 170, I'm up to 27 minutes per frame. The October 15th IRTC
> deadline is fast approaching!  While it's possible that more complex
> effects exist at the end of the animation, I am wondering if I might be
> able to finish this whole thing more quickly if I were to stop and start
> the whole thing again at the current frame.

In answer to your first question - yes, each frame is basically rendered
as a separate image (with separate parsing et al), using the relevant
clock value and output name as determined by the animation settings. 
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.

In POV-Ray 3.0x, you can use the #debug directive to write the variables
(in #declare Name = Value format) to the debug_stream, which you can
output to a file using the -GD[filename] switch (or
Debug_File=[filename]).  You then include this file in subsequent
frames, eg. (using -GD Settings.inc):

   #if (clock > 0) #include "Settings.inc" #end

   [... uses and modifies the variables from the file ...]

   #debug concat("#declare Value1 = ", str(Value1, 0, -1), "\n")
   #debug concat("#declare Value2 = ", str(Value2, 0, -1), "\n")

The disadvantage of this method is that you usually have to start the
render from the beginning of the animation (unless you have a
Settings.inc file from the frame before the frame you want to start on).

And finally, regarding the animation slowdown - if you render the first
and last frames separately (using +K0 and +K1) you should see if there
is a genuine difference between the complexity of the two frames, or if
the slowdown is caused by the internal animation loop.   One possibility
(quite common at that) is a problem with the automatic bounding
threshold - if your first frame includes few or no objects, whereas
subsequent frames contain many objects, automatic bounding may not be
turned on at the beginning of the rendering (and therefore won't be used
later on, when it is need to vastly speed up rendering).  If this is the
case, simply use +MB=0 (or Bounding_Threshold=0) so that automatic
bounding will be enabled no matter how many objects are (or aren't) in
the frame you start rendering from.

Post a reply to this message

Chris Colefax 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.

> In POV-Ray 3.0x, you can use the #debug directive to write

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 finally, regarding the animation slowdown

In my animation, I wanted a large translucent plastic sign to be visible
in the reflections of my Metal Men, and to be visible with a color
shadow on the ground. I ended up using (perhaps ineptly) a combination
of ambient and transmission in the color. The sign wasn't visible at the
beginning, and there were a more reflective objects at the end. This
could easily explain the slowdown. 

> (quite common at that) is a problem with the automatic bounding
> threshold

I read about bounding in the 3.02 docs. When I saw that a large majority
of the ray tests had to do with my blob figures, I added bounding
statements for the blobs.  POV gave me all kinds of warning messages
about unnecessary bounding, so I removed it and went on.  I DO NOT
understand the concept of bounding: my experience destroyed any
intuition on the subject.

___________________
Greg M. Johnson
"Volunteer firefighters is fine, ma'am, but don't tell me there ain't
nobody burnin' in that buildin'," said the Fire Chief to the Libertarian
Lady.

Post a reply to this message

I simply let the clock be 0 to 1 for most any animation I do.
If I were to do 15 frames for preview, and 150 final the clock is still 
incrementing proportionaly. Same for Subset_Frame_Start and _End.
For exact frame number event stuff I'm not the one to advise you but it 
should be basic math.

Message <362### [at] aolcom>, Greg M. Johnson  typed...

>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.


-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.html
=Bob

Post a reply to this message

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