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

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

Post a reply to this message

Bob Hughes <inv### [at] aolcom> wrote:
: I'm not totally inner workings savy, but yes, from what I understand
: the visible scene is calculated so the other stuff can be dropped out.

  You can't do that. You have no way to know if an object will be visible
through reflection/refraction (other than actually raytracing the scene).
If an object was not hit by any ray in the previous frame, you have no way
to know if it will be hit or not in the current frame.
  Automatically declaring objects as "static" depending on whether the clock
value affects them or not is a mathematically impossible problem (AFAIK).
You can always write a program which is not analytically solvable.
Numerical solving would be at least as slow as the actual parsing of the
scene, so no benefits would be achieved.
  You can only be sure that an object is not affected by the clock value
when it doesn't use any identifier which has been "touched" by 'clock'
(or other identifiers which have been "touched", etc). The same thing for
'clock_delta'.
  This is not enought, though. An object may depend on the clock value even
if it doesn't use any identifier. For example:
  #if(clock<.5) sphere { 0,1 pigment { rgb 1 } } #end

  But even this is not enough. The object may depend on the contents of an
external file (which is #read during parsing and which may change from
frame to frame).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> 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."
>
> Of course, even that would be difficult to achieve if you're using any
> kind of complex camera motion, such as Colefax's splines.

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

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.

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.

-Mike

Post a reply to this message

John VanZwieten wrote:
> 
> Is it necessary for POV-Ray to parse a file separately for each view of the
> same scene?  Is there any way to "save" the result of the parsing to use in
> repeated raytracings from different views?
> 
> Thanks in advance for any help with this.
> 
> -John VanZwieten

Hi there,
my default insertion here, like some folks always say 'visit my links
page' I use to say the following:

I object to the statement that POV-Ray is slow in parsing. All that POV
is doing, is saying that it parsed some 1.5h, but most of the time it
did run your code.
It just doesn't tell you 
'your $%*&ing codes runtime: 1.49Hrs
parsing time: 60 sec'

What do we have? By the grace of the POV-Ray Team we have one and only
one interface to the rendering engine, and thats the Scene Description
Language.
Like that name says, it's a language defined to describe a scene. It's
not designed to do heavy numerics or business-transactions.
Throughout it's history (which I experienced not so much of) it has been
extended by more and more programming constructs, giving the users more
and more possibilities. Thanx, guys.
But that stuff doesn't only have to be coded, but it has to be paid for.
And that's simply speed.
Short: the parser is fine, the interpreter is slow. That's fine, I do
prefer a good renderer to yet another interpreter.
Could someone speed it up? No, because there are way too many backdoors,
like pre- and postframe shellouts and #read, so one rarely knows, what
content changed at what time.
So, if you want to stick to portable and simple coding for the users,
you stick to the speed.

More speed would require a serious breaking of compatibility, and in my
opinion, another interface to the engine. POVLegal won't like it, and
most probably the POV-Ray Team won't code it.
(I think of something like a DOM-based CORBA interface)

A short remark on the binary format. It was implemented, but provided
the heterogeneous tree structure of the scene in memory, you have a lot
of work putting all those pointers back into place, and most objects
will be created one by one, so not that much of speedup to expect.

Axel

Post a reply to this message

On 17 Sep 1999 03:13:21 -0400, Nieminen Juha wrote:
>  You can only be sure that an object is not affected by the clock value
>when it doesn't use any identifier which has been "touched" by 'clock'
>(or other identifiers which have been "touched", etc). The same thing for
>'clock_delta'.

clock_delta is a constant for a given animation sequence, isn't it?

>  This is not enought, though. An object may depend on the clock value even
>if it doesn't use any identifier. For example:
>  #if(clock<.5) sphere { 0,1 pigment { rgb 1 } } #end

This can still be detected, of course.  Anything that's inside an #if 
block or a #while block that is dependent on clock is automatically 
dependent on clock.

>  But even this is not enough. The object may depend on the contents of an
>external file (which is #read during parsing and which may change from
>frame to frame).

e.g. by using a preframe shellout, or by writing it during the parse of the
current frame.  And let's not forget #include files that are generated 
automatically by either of those methods.

Obviously such scenes couldn't be rendered with "smart reparsing."  It would 
have to be an option, and probably not a default option.  Alternatively, you
could have a way to explicitly mark objects as being fixed from frame to frame,
and anything that isn't so marked is automatically reparsed.  This wouldn't
even take too much change to the parser.

Post a reply to this message

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

On Fri, 17 Sep 1999 16:07:27 +0200, Tomas Plachetka wrote:
>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...

No, this thread is purely speculative and purely unofficial.  Even if
some of us are members of the POV-Team, we're speaking completely
unofficially here.  But I agree with your sentiment anyway; even an
unofficial patch should be well-thought-out ahead of time.

Post a reply to this message

Nieminen Juha wrote in message <37e1ea11@news.povray.org>...
>Bob Hughes <inv### [at] aolcom> wrote:
>: I'm not totally inner workings savy, but yes, from what I understand
>: the visible scene is calculated so the other stuff can be dropped out.
>
>  You can't do that. You have no way to know if an object will be visible
>through reflection/refraction (other than actually raytracing the scene).
>If an object was not hit by any ray in the previous frame, you have no way
>to know if it will be hit or not in the current frame.
>  Automatically declaring objects as "static" depending on whether the
clock
>value affects them or not is a mathematically impossible problem (AFAIK).
>You can always write a program which is not analytically solvable.
>Numerical solving would be at least as slow as the actual parsing of the
>scene, so no benefits would be achieved.
>  You can only be sure that an object is not affected by the clock value
>when it doesn't use any identifier which has been "touched" by 'clock'
>(or other identifiers which have been "touched", etc). The same thing for
>'clock_delta'.
>  This is not enought, though. An object may depend on the clock value even
>if it doesn't use any identifier. For example:
>  #if(clock<.5) sphere { 0,1 pigment { rgb 1 } } #end
>
>  But even this is not enough. The object may depend on the contents of an
>external file (which is #read during parsing and which may change from
>frame to frame).


Add a 'static' object modifier to the language that can be applied to
anything, for example:

sphere{<0,0,0>, 1 pigment{ rgb 1} static}

 POV-Ray will not reparse any object that contains that modifier after the
first frame of an animation.  If you apply it to an object that does get
changed over the course of an animation, that's your problem, not POV's.

Mark

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
: Add a 'static' object modifier to the language that can be applied to
: anything, for example:

: sphere{<0,0,0>, 1 pigment{ rgb 1} static}

:  POV-Ray will not reparse any object that contains that modifier after the
: first frame of an animation.  If you apply it to an object that does get
: changed over the course of an animation, that's your problem, not POV's.

  I think this is not enough either. Povray will have to parse the entire
file anyways if there's some non-static objects (for example at the end of
the file). One solution to this is, of course, to keep a copy of the scene
in memory with all static objects removed.
  There's another problem: If all objects generated in a #while-loop are
static, that loop doesn't need to be parsed but just once. But how do you
tell this to povray?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
> Mark Wagner <mar### [at] gtenet> wrote:
> : Add a 'static' object modifier to the language that can be applied to
> : anything, for example:
> 
> : sphere{<0,0,0>, 1 pigment{ rgb 1} static}
> 
> :  POV-Ray will not reparse any object that contains that modifier after the
> : first frame of an animation.  If you apply it to an object that does get
> : changed over the course of an animation, that's your problem, not POV's.
> 
>   I think this is not enough either. Povray will have to parse the entire
> file anyways if there's some non-static objects (for example at the end of
> the file). One solution to this is, of course, to keep a copy of the scene
> in memory with all static objects removed.
>   There's another problem: If all objects generated in a #while-loop are
> static, that loop doesn't need to be parsed but just once. But how do you
> tell this to povray?
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

how about a static block i.e.
static{
  ...
}

easy to skip in parsing and can contain anything.
Of course the scene coder has to be extra careful what's put in there.

Cheers, PoD.

Post a reply to this message