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