Ron Parker wrote:
> 
> On Thu, 16 Sep 1999 23:27:41 -0400, "Nathan Kopp" <Nat### [at] Koppcom>
> wrote:
> 
> >But skipping the parsing step would also remove the need for all of this
> >memory shuffling.  Once you've got a scene parsed and allocated in memory,
> >it would be nice to render scenes of an animation by simply changing what's
> >already in memory instead of destroying it all and rebuilding it for each
> >frame.
> 
> I agree, in the animation case.  I've long thought about how to modify
> POV so it only parses the static parts of a scene once.  It would
> definitely be nice if you could somehow say "The whole scene is
> static, so only reparse the camera definition for each frame."

I know about at least one such implementation (my own).
During a research project I implemented a parallel version
of POV-Ray (I call it POV||Ray) which used an incremental 
parsing concept (see my note Xref: news.povray.org 
povray.general:14892). My version went never public as the 
implementation was somewhat experimental, based on some not 
well supported components, some of the original POV-Ray 
functionality would not be preserved, etc. (For instance, 
animations based on a #clock variable would not work at all.) 
Parsing was a tricky part of the implementation and I spent 
some time on it. For a camera animation, the parsing times 
dropped from 15 minutes to cca 3 seconds or less.

POV-Ray is not dependent on a particular interactive modeler,
therefore there is the pre- and post- processing overhead 
that can be avoided if a raytracer is used within an 
integrated environment. The right way lies perhaps in between 
these two extremes.

My idea was/is making POV-Ray *persistent*. ;-) 
I mean a termination upon request only. There could be an 
interface which allows changing the scene which persists, 
incremental adding of new objects, etc. The interface 
could even be the same as up to now - an (incremental) 
.pov file.

> Of course, even that would be difficult to achieve if you're using any
> kind of complex camera motion, such as Colefax's splines.

Not necessarily. However, I am afraid that some of the
backward compatibility would have to be given up (so if 
you mean this, you are right). Many already existing tools 
would thus become outdated (those which have something to 
do with animations). But maybe even not.

A #clock variable would not be used by a preprocessor
anymore, at least not the way it is used now. However,
it could be used for generating an incremental .pov file
(or a script file or whatever the interface looks like).
Unless... unless there is a true 4D extension made to
POV-Ray. (Some extensions, like adding IDs to 
objects/textures will be needed anyway.)

Mike wrote:
> That sounds feasable to me, provided that special case is made.  You know how
> POV-Ray allows one atmospheric media?  Maybe you could allow one static {}
> block...

I do not know how POV-Ray allows one atmospheric media, 
but I think I know what you mean. It's probably the same 
as in the case of camera, right?

> I guess the problem is when does POV release the stuff that is in
> memory...unless you went so far as to add a keyword to tell it to do so.  Like
> #if (clock = 100) clear_memory

This can be done.

> Seems to me that things could get messy though.  Until recently there were all
> those global variables that weren't getting cleared (I wouldn't doubt there are
> still some).  Now that I think about, that kinda' shows how it could be done -
> since POV in the windows version is running from the time you start it, then if
> the parsed scene wasn't freed it would be used the next time you
> render...assuming you didn't try writing stuff to the same areas in memory.

Yes, I mean something like this. With one objection -
the solution should not be bound to windows.

> I really don't know enough about how it manages memory or parses or...just about
> everything, so I guess I'm not one to talk.

I know something about it. Feel free to ask me (a direct 
msg or CC, please - I don't read news very regularly).

A final (useless) remark: If you (I guess you guys are
members of the POV-Team) decide to go the way I sketch
here, make a clear concept before making any quick
and dirty optimizations. As Mike said, things could get 
messy...

	Tom

Post a reply to this message