Nicolas Alvarez wrote:
> Brent Fraser wrote:
>>   I see that rtr/clockless animation in 3.7 will not re-parse, so the 5
>>   minute file loading hit is done only once.  Now I need to figure out
>>   where to add the file-saving code.  Is there a technical reason (i.e.
>>   thread complexity) or a more administrative reason why that capability
>>   is not in the current 3.7 beta?  Any pointers to where I could add it
>>   would be appreciated.
>>
>>   The problem with using the clockless animation approach to solve my
>>   performance problem is that my script does actually contain a minor
>>   amount of animation so I'd like to preserve it if possible (which
>>   clockless animation does not currently allow).
> 
> The reason why the current clockless animation is even possible is *because*
> it lacks the flexibility you're now needing...
> 
> I think instead of storing a number, it stores some special object saying it
> has to animate that number. When the first frame is done, it updates that
> one number and re-renders.
> 
> If you want to run any more complex code to move the camera, it will have to
> re-parse to run the code again...
> 

  I'm new to Pov-Ray so I'm still trying to get up to speed on the design philosophy. 
My understanding so far: the Pov files describe a scene containing objects with
properties and a viewpoint (camera).  Some properties change over time, driven by
Pov's CLOCK variable.  Since the properties are complex (can interact, etc) the scene
needs to be reconstructed (object properties re-calculated, possibly including the
camera postiion/orientation) for each frame (tick of the clock), and this is done by
re-parsing.  I get that; what I don't get is having to re-read height_field and
image_map files (non-changing raster files) on every frame render.

  We're likely using POV-Ray in a non-standard way: we want to render lots of small
frames (1024x768) by moving the camera over a small set of huge height fields (with
huge image maps) to make a movie.  From what I've read, POV's strength is rendering a
single large frame from a scene containing lots of objects; kind of the opposite of
our situation.  If the object definitions are small, then re-reading them on every
parse is a very minor part of the render time, but that's not our case.

   And I found it frustrating to read about MegaPov's "persistence of variables" only
to find out the feature is no longer available.

Thanks,
Brent Fraser

Post a reply to this message