This is kind of a stupid question considering I've been using POV-Ray 
for nearly 20 years.

Does the program need to parse the scene completely each frame of an 
animation? Is there any speed benefit compared to rendering each frame 
individually without POV's animation feature?

I have a huge LDraw model that takes ~30 hours to parse and ~1 hour to 
render. If each frame doesn't need to the scene to be parsed completely 
I may consider making an animation. Otherwise, I won't do it.

Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:
>
> Does the program need to parse the scene completely each frame of an
> animation? Is there any speed benefit compared to rendering each frame
> individually without POV's animation feature?

Unfortunately I believe POV-Ray 3.7 does still clean the slate of memory for
each frame.

I recall when persistent variables were introduced in patched versions, and
apparently it's now a feature of UberPOV. Just not something available via P-R
3.7 AFAIK.

Sorry I can't tell you if that would be the possible solution since I can't
remember if declared objects will store in memory frame to frame using
#persistent = [object{model}].

Bob

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:

> Does the program need to parse the scene completely each frame of an
> animation?

Yes.

Imagine the case where there may be SDL that selects completely different
"scenes" depending on clock value or frame number.

I believe in your case, you may want to consider Paul Bourke's article(s) on
frustum culling / clipping  That may help to keep the parse time far lower.

Post a reply to this message

Link:

http://paulbourke.net/miscellaneous/frustum/

Post a reply to this message

Am 04.10.2016 um 00:15 schrieb Mike Horvath:

> This is kind of a stupid question considering I've been using POV-Ray
> for nearly 20 years.

I would call the question anything but stupid.

> Does the program need to parse the scene completely each frame of an
> animation?

As far as official POV-Ray is concerned, yes.

> Is there any speed benefit compared to rendering each frame
> individually without POV's animation feature?

Yes, there still is.

There is always /some/ overhead associated with starting and terminating
a program: The operating system needs to set up a new process, load the
executable file into memory, and then start the process, which itself
may also do some general preparations (as a simple example, POV-Ray's
parser converts the "hand-woven" plain table of keywords into a format
that allows faster access); and upon termination the operating system
must do some cleaning-up.

Even more so, there's the matter of dynamic memory allocation: Whenever
a process needs additional memory, it needs to call the operating system
to allocate the amount needed, which is a comparatively costly matter.
Once the process terminates, all the allocated memory will be re-claimed
by the operating system, so when the process is re-started, it must
request the memory from the operating system all over again.

In contrast, when a process has finished a job and no longer needs all
the allocated memory allocated for it, it will /not/ release the memory
back to the operating system, but just make a mental note that the
memory block is vacant, and re-use it when it needs more memory again.
While there's still a bit of overhead involved in this management of
free memory blocks, it is far faster than acquiring more memory from the
operating system.


That said, the overhead of starting and stopping POV-Ray is fairly low
in magnitude compared to the total parsing and/or rendering time.


> I have a huge LDraw model that takes ~30 hours to parse and ~1 hour to
> render. If each frame doesn't need to the scene to be parsed completely
> I may consider making an animation. Otherwise, I won't do it.

As omniverse already mentioned, you definitely want to check out
UberPOV, which features an experimental (but working) mechanism to
persist data between frames of an animation (or, more precisely, for as
long as the instance of POV-Ray is running, which is the same on Unix
but makes a difference on Windows; but that's more of a side effect than
intentional, and is the sole reason why the mechanism is still
considered experimental).

The mechanism can persist virtually anything you can stuff into a
variable. To my knowledge (and I wrote the thing), the only exceptions
are random number generators (as created by `seed()` and used by
`rand()`) and file handles (as created by `#fopen` and used e.g. by
`#read` or `write`), as in both cases the variables technically just
hold plain numbers, which happen to be valid indices into tables
maintained separately.

The use is pretty straightforward: Simply use `#persistent` instead of
`#declare`, and the variable and its contents will still be around in
the next frame. `#ifdef` should work as expected, so you can e.g. choose
whether or not to include a file depending on whether the variable is
already set, without having to rely on frame numbers.

Post a reply to this message

Le 04/10/2016 à 00:15, Mike Horvath a écrit :
> This is kind of a stupid question considering I've been using POV-Ray
> for nearly 20 years.
> 
> Does the program need to parse the scene completely each frame of an
> animation? Is there any speed benefit compared to rendering each frame
> individually without POV's animation feature?
> 
> I have a huge LDraw model that takes ~30 hours to parse and ~1 hour to
> render. If each frame doesn't need to the scene to be parsed completely
> I may consider making an animation. Otherwise, I won't do it.
> 
> Mike

I do not know LDraw, but I hope any mesh is described as a mesh2
(parsing of mesh{} is kind of exploding parse time as number of
triangles increases (there is a search amongst previous points/vectors
for each new one... ))

There is also some patches somewhere which would cache macro in memory
instead of doing file access. If you have lot of macro in many files, it
might help.

And maybe the obvious: can you have a ramdisk for the scene to parse ?

And to end it: have you check you have not hit the swap of your system ?

Post a reply to this message

Am 04.10.2016 um 19:08 schrieb Le_Forgeron:

> I do not know LDraw, but I hope any mesh is described as a mesh2
> (parsing of mesh{} is kind of exploding parse time as number of
> triangles increases (there is a search amongst previous points/vectors
> for each new one... ))

Most people using POV-Ray to render LDraw models actually use mostly
CSG. (LDraw is a LEGO modelling tool, and export can make use of a
CSG-based parts library for POV-Ray instead of exporting LDraw's own
mesh-based definitions of the pieces.)

Post a reply to this message

On 10/4/2016 11:09 AM, clipka wrote:
> As omniverse already mentioned, you definitely want to check out
> UberPOV, which features an experimental (but working) mechanism to
> persist data between frames of an animation (or, more precisely, for as
> long as the instance of POV-Ray is running, which is the same on Unix
> but makes a difference on Windows; but that's more of a side effect than
> intentional, and is the sole reason why the mechanism is still
> considered experimental).
>
> The mechanism can persist virtually anything you can stuff into a
> variable. To my knowledge (and I wrote the thing), the only exceptions
> are random number generators (as created by `seed()` and used by
> `rand()`) and file handles (as created by `#fopen` and used e.g. by
> `#read` or `write`), as in both cases the variables technically just
> hold plain numbers, which happen to be valid indices into tables
> maintained separately.
>
> The use is pretty straightforward: Simply use `#persistent` instead of
> `#declare`, and the variable and its contents will still be around in
> the next frame. `#ifdef` should work as expected, so you can e.g. choose
> whether or not to include a file depending on whether the variable is
> already set, without having to rely on frame numbers.
>

I must remember to try UberPOV next time. Thanks!


Mike

Post a reply to this message