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

Post a reply to this message

Hmmm, to view other camera angles reparsing is needed because of the
change in rays going to/from objects.  Their profiles are always going
to be different, well that's my guess anyhow.  Parsing was improved as
I recall for multiple frames or renders of the same scene but think
you're talking about keeping a memory map of sorts which considers any
and all changes to camera position.  Of course if a scenes objects,
etc. change with time then the question is probably moot.

Bob

John VanZwieten <Joh### [at] emailmsncom> wrote in message
news:37e135f4@news.povray.org...
> 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
>
>

Post a reply to this message

Bob Hughes <inv### [at] aolcom> wrote in message
news:37e14074@news.povray.org...
> Hmmm, to view other camera angles reparsing is needed because of the
> change in rays going to/from objects.  Their profiles are always going
> to be different, well that's my guess anyhow.

So parsing is view angle-dependent, rather than just scene-dependent.

> Parsing was improved as
> I recall for multiple frames or renders of the same scene but think
> you're talking about keeping a memory map of sorts which considers any
> and all changes to camera position.  Of course if a scenes objects,
> etc. change with time then the question is probably moot.
>

My situation is a "fly through" where the camera location/angle change but the
scenes objects do not.

Thanks for the info,

-John VanZwieten

Post a reply to this message

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.
That makes for a change in parse I believe even when just viewpoint
changes.

Bob

John VanZwieten <Joh### [at] emailmsncom> wrote in message
news:37e142da@news.povray.org...
>
> Bob Hughes <inv### [at] aolcom> wrote in message
> news:37e14074@news.povray.org...
> > Hmmm, to view other camera angles reparsing is needed because of
the
> > change in rays going to/from objects.  Their profiles are always
going
> > to be different, well that's my guess anyhow.
>
> So parsing is view angle-dependent, rather than just
scene-dependent.
>
> > Parsing was improved as
> > I recall for multiple frames or renders of the same scene but
think
> > you're talking about keeping a memory map of sorts which considers
any
> > and all changes to camera position.  Of course if a scenes
objects,
> > etc. change with time then the question is probably moot.
> >
>
> My situation is a "fly through" where the camera location/angle
change but the
> scenes objects do not.
>
> Thanks for the info,
>
> -John VanZwieten
>
>
>

Post a reply to this message

On Thu, 16 Sep 1999 14:23:55 -0500, Bob Hughes 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.
>That makes for a change in parse I believe even when just viewpoint
>changes.

Nope.  But vista buffers are view-angle dependent.  Still, there's not
currently any way to save the results of the parse.  My understanding
is that it wouldn't save as much time as it might seem anyway.

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

There is no simple way how to do this.
POV-Ray is an offline program which reads
its input, computes a pretty output and
terminates. There is an animation loop,
but it is based on reparsing the scene.

I noticed some debates on a binary format
(this is probably what you mean) but it
was never implemented (binary triangle 
meshes are the only exception). Anyway,
a binary format would not lead to a 
significant parsing speedup.

You asked for "any way". OK, there is a 
way how to do a camera animation without 
reparsing the scene. This requires some
programming. You have to write a program
which mimicks POV-Ray but keeps running
unless told to terminate. Such an 
interactive POV-Ray must have an option 
to parse a new file after rendering a
frame, without destroying the original
scene which is still in memory. The new 
file will contain just the new camera.
That's it.

	y.

Post a reply to this message

Ron Parker <par### [at] fwicom> wrote in message news:37e14498@news.povray.org...
> On Thu, 16 Sep 1999 14:23:55 -0500, Bob Hughes 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.
> >That makes for a change in parse I believe even when just viewpoint
> >changes.
>
> Nope.  But vista buffers are view-angle dependent.  Still, there's not
> currently any way to save the results of the parse.  My understanding
> is that it wouldn't save as much time as it might seem anyway.

Why not?  Parsing on a scene I'm working with takes >1.5 hours.

-John Van

Post a reply to this message

On Thu, 16 Sep 1999 14:36:02 -0500, John VanZwieten wrote:
>
>Ron Parker <par### [at] fwicom> wrote in message news:37e14498@news.povray.org...
>> On Thu, 16 Sep 1999 14:23:55 -0500, Bob Hughes 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.
>> >That makes for a change in parse I believe even when just viewpoint
>> >changes.
>>
>> Nope.  But vista buffers are view-angle dependent.  Still, there's not
>> currently any way to save the results of the parse.  My understanding
>> is that it wouldn't save as much time as it might seem anyway.
>
>Why not?  Parsing on a scene I'm working with takes >1.5 hours.

The reason that was given the last time this came up was that profiling
shows that most of the time parsing is actually spent allocating and
shuffling memory around.  Of course this isn't true for all scenes, but
that's what "they" said.

Now that I have access to a copy of vTune for Windows, maybe I'll find 
a big scene to parse and see for myself.

Post a reply to this message

In article <37e149fe@news.povray.org> , par### [at] fwicom (Ron Parker) wrote:

> The reason that was given the last time this came up was that profiling
> shows that most of the time parsing is actually spent allocating and
> shuffling memory around.  Of course this isn't true for all scenes, but
> that's what "they" said.
>
> Now that I have access to a copy of vTune for Windows, maybe I'll find
> a big scene to parse and see for myself.

You can try pyramid.pov in the sample scenes. Just increase the recursion
level if you need a scene taking even longer to parse.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

But what when you render exactly the same scene at a different resolution?
Then it seems a pity that you have to render again.....

Sander

Bob Hughes <inv### [at] aolcom> schreef in berichtnieuws
37e143e8@news.povray.org...
> 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.
> That makes for a change in parse I believe even when just viewpoint
> changes.
>
> Bob
>

Post a reply to this message

You might notice that renders (and parses) tend to be quicker when run
the second time.  This of course might be OS platform dependant and
such, don't know.  Possibly it's only because of memory use
effieciency of the OS and nothing to do with POV-Ray itself.

Bob

Sander <san### [at] the-internet> wrote in message
news:37e1573d@news.povray.org...
> But what when you render exactly the same scene at a different
resolution?
> Then it seems a pity that you have to render again.....
>
> Sander
>
> Bob Hughes <inv### [at] aolcom> schreef in berichtnieuws
> 37e143e8@news.povray.org...
> > 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.
> > That makes for a change in parse I believe even when just
viewpoint
> > changes.
> >
> > Bob
> >
>
>
>

Post a reply to this message

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.

And, while it wouldn't make much difference for scenes with lots of glass or
media, it could be a noticable speed improvement for other scenes, such as
ones with lots of triangles or ones built using extreme recursion (which POV
is slow at parsing).

And, granted, all those light buffers, vista buffers, and the like would
have to be re-computed each time, but I still think it is something that
would benefit POV.

-Nathan

Ron Parker <par### [at] fwicom> wrote
> The reason that was given the last time this came up was that profiling
> shows that most of the time parsing is actually spent allocating and
> shuffling memory around.  Of course this isn't true for all scenes, but
> that's what "they" said.
>
> Now that I have access to a copy of vTune for Windows, maybe I'll find
> a big scene to parse and see for myself.

Post a reply to this message

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

On Mon, 20 Sep 1999 07:07:47 +0930, PoD <pod### [at] merlinnetau> wrote:

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

I prefer the syntax

#static
...
#end

because block syntax is currently restricted to actual entities, and
#-directives are used for procedural and flow-control things.

Post a reply to this message

Ron Parker <par### [at] fwicom> wrote:
: #static
: ...
: #end

  Not bad. This way you could specify anything as static, not just objects.

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

Ron Parker wrote:
> 
> On Mon, 20 Sep 1999 07:07:47 +0930, PoD <pod### [at] merlinnetau> wrote:
> 
> >how about a static block i.e.
> >static{
> >  ...
> >}
> 
> I prefer the syntax
> 
> #static
> ...
> #end
> 
> because block syntax is currently restricted to actual entities, and
> #-directives are used for procedural and flow-control things.

Err. yeah given how the rest of the syntax works, you're right, I've
just never liked that syntax.

The main point is the same though, if this is not the first parsing of
the file then traet this block as a comment.

Cheers, PoD.

Post a reply to this message

Ron Parker wrote:
> 
> On Mon, 20 Sep 1999 07:07:47 +0930, PoD <pod### [at] merlinnetau> wrote:
> 
> >how about a static block i.e.
> >static{
> >  ...
> >}
> 
> I prefer the syntax
> 
> #static
> ...
> #end
> 
> because block syntax is currently restricted to actual entities, and
> #-directives are used for procedural and flow-control things.

Well, if such a thing were really to be implemented, then 
I would suggest #endstatic instead of just #end.
Using #end as a common construct terminator could lead to 
nesting problems, especially if several such contructs
are needed in the future.

The current #if, #while, #ifdef, etc directives are safe
about using a common #end terminator as there is a simple
nesting rule. However, this simplicity could be violated
when adding new constructs like this. Using special 
constructs for specials is perhaps better than using 
special semantics for specials. (Wow, what a sentence.)

	y.

Post a reply to this message

On Tue, 21 Sep 1999 11:12:16 +0200, Tomas Plachetka wrote:
>Well, if such a thing were really to be implemented, then 
>I would suggest #endstatic instead of just #end.
>Using #end as a common construct terminator could lead to 
>nesting problems, especially if several such contructs
>are needed in the future.

But #static is just a fancy way of saying "#if (this_is_the_first_parse)",
so it nests perfectly with other #ifs.  It has to, because otherwise you'll
hit an unmatched #end or an unmatched #if the second time you parse the file.
Unless you're thinking about something horrible like this

#static
  #if (0)
#endstatic
   object {wristband}
#static
  #end
#endstatic

to make the mat object only appear in frames after the first one. (does that
make it an antistatic mat?)  But that's a horrible, horrible corruption of 
the purpose of #static (and wouldn't scale to multiple processors working on
the same animation.)

Post a reply to this message

Ron Parker wrote:
> 
> On Tue, 21 Sep 1999 11:12:16 +0200, Tomas Plachetka wrote:
> >Well, if such a thing were really to be implemented, then
> >I would suggest #endstatic instead of just #end.
> >Using #end as a common construct terminator could lead to
> >nesting problems, especially if several such contructs
> >are needed in the future.
> 
> But #static is just a fancy way of saying "#if (this_is_the_first_parse)",
> so it nests perfectly with other #ifs.  It has to, because otherwise you'll
> hit an unmatched #end or an unmatched #if the second time you parse the file.
> Unless you're thinking about something horrible like this
> 
> #static
>   #if (0)
> #endstatic
>    object {wristband}
> #static
>   #end
> #endstatic
> 
> to make the mat object only appear in frames after the first one. (does that
> make it an antistatic mat?)  But that's a horrible, horrible corruption of
> the purpose of #static (and wouldn't scale to multiple processors working on
> the same animation.)

Now I can't think of a better example...
Uhm. Never mind, I have a more conceptual question:
How do you define an object which is defined in the 
second frame (or 51th frame if you want) and does 
not change (persists) till the end of the animation? 
I think you cannot. (Nor can I.) In other words,
#static will not allow you to insert any static objects
in any other frame except of the first one. Right?

	y.

Post a reply to this message

On Tue, 21 Sep 1999 18:24:40 +0200, Tomas Plachetka wrote:
>Now I can't think of a better example...
>Uhm. Never mind, I have a more conceptual question:
>How do you define an object which is defined in the 
>second frame (or 51th frame if you want) and does 
>not change (persists) till the end of the animation? 
>I think you cannot. (Nor can I.) In other words,
>#static will not allow you to insert any static objects
>in any other frame except of the first one. Right?

Right.  Presumably you could extend it to #static (start,end) 
which would mean the contents of the block are static for clock 
values between start and end.

Post a reply to this message

Ron Parker wrote:
> 
> On Tue, 21 Sep 1999 18:24:40 +0200, Tomas Plachetka wrote:
> >Now I can't think of a better example...
> >Uhm. Never mind, I have a more conceptual question:
> >How do you define an object which is defined in the
> >second frame (or 51th frame if you want) and does
> >not change (persists) till the end of the animation?
> >I think you cannot. (Nor can I.) In other words,
> >#static will not allow you to insert any static objects
> >in any other frame except of the first one. Right?
> 
> Right.  Presumably you could extend it to #static (start,end)
> which would mean the contents of the block are static for clock
> values between start and end.

That's it. Then why not having simply #if (start, end)? 
Let the POV-Ray decide what persists and for how long.
This would also save one keyword. However, when nesting
#if with #if(start, end), one could get in troubles. To 
avoid this, you have to carefully restrict usage of 
#if(start, end).

Note that the above arguments apply to #static(start,end), 
too.

	y.

Post a reply to this message

On Tue, 21 Sep 1999 19:50:19 +0200, Tomas Plachetka wrote:
>That's it. Then why not having simply #if (start, end)? 

I'm not sure I like this syntax.  For one thing, it's too easy to 
mistype a less-than as a comma.  For another, it doesn't convey 
the correct idea.  #if (start, end) seems to imply that it's 
shorthand for #if (start < clock & clock < end) when in fact it's 
another concept entirely: everything inside the #static block 
would be parsed for any frame where the clock is outside the 
prescribed limits, and it would be parsed at most once per 
rendering session with a clock value somewhere inside the limits. 
And keywords are fairly cheap.

>However, when nesting
>#if with #if(start, end), one could get in troubles. To 
>avoid this, you have to carefully restrict usage of 
>#if(start, end).

The only problems I see with nesting would be something like 

#if (clock > .5 )
  #static (.3,.6)
    ...
  #end
#end

or 

#static (.3,.6)
  #if (clock > .5 )
    ...
  #end
#end

and both of these are clearly misuses of the static qualifier:
the things being declared static are not in fact static over 
the declared range, and the user deserves whatever he or she
gets. :)

Post a reply to this message

Ron Parker wrote:
> 
> On Tue, 21 Sep 1999 19:50:19 +0200, Tomas Plachetka wrote:
> >That's it. Then why not having simply #if (start, end)?
> 
> I'm not sure I like this syntax.  For one thing, it's too easy to
> mistype a less-than as a comma.  

The syntax itself is not so important. But you are 
completely right. :-) I would bet that you mistyped
the comma when writing that message, didn't you?

> For another, it doesn't convey
> the correct idea.  #if (start, end) seems to imply that it's
> shorthand for #if (start < clock & clock < end) when in fact it's
> another concept entirely: everything inside the #static block
> would be parsed for any frame where the clock is outside the
> prescribed limits, and it would be parsed at most once per
> rendering session with a clock value somewhere inside the limits.

Not exactly. Actually, I was thinking about 
#if(start,end) as about the shorthand for 
#if (start < clock & clock < end). But it's 
not *only* a shorthand. A special #if syntax 
would also tell the parser to skip the parsing
if the clock value is outside the limits. This
is something what the parser cannot do when it
sees #if (start < clock & clock < end).

Anyway, you are right. The special #if syntax 
does not suggest that the parser will try to
skip the block for a frame outside the limit.
There may be a nested #if inside the block
which does not get parsed, although it should.

Wait a moment... (looking into tokenize.c,
Parse_Directive, Skip_Tokens, Get_Token).
Interesting... I'm lazy to study the code now,
but I would say that all directives, even those
in a FALSE branch of an #if get parsed! Is it
really so? Is it really needed? If it is not
needed, then I would reconsider binding the 
"time limited static feature" to objects,
textures, etc.
(I think that somebody here already suggested 
the same, but this debate had not been so far 
yet that time.)

Damned. I think that we both are overlooking
one important detail. We are discussing the
language. But we should also consider what 
should happen with the objects in memory. When
is an object/texture/etc supposed to be released?
The original idea was to keep static objects
in memory throughout the whole animation. But
if an object should durate just for the time
specified in #static(start,end), then the 
situation is much more complicated. (The clock
function is not necessarily monotone. During an
animation, an object/texture/etc. can be 
sometimes there and sometimes not.)
Howgh.

> And keywords are fairly cheap.

I know. However, extending syntax is usually 
better than adding a new keyword. In this
particular case it is not possible.

When speaking about extended syntax, I would
have a suggestion for the POV-Team which makes 
the POV language more robust. Why should one be
able to say "ambient rgb<0.1,0.2,0.8>" in a 
texture but couldn't say the same for diffuse?!
(This is not just an aesthetical comment, it
really helps sometimes, e.g. when converting
materials from other formats to .pov.)
This is my wish list:
- diffuse in a texture is now a float. It could
be defined for rgb channels separately.
- phong, ditto.
- specular, ditto.
- if there is something I forgot, ditto.

The texture finish memory storage will grow a 
little. However, I do not see a reason for having 
incredibly many textures in a scene. (I may be 
wrong.)

The changes involve extending the parser (in parstxtr.c 
replacing Parse_Float with Parse_Colour will usually 
do), redefining the types in frame.h, and rewriting a 
few routines. I can help by pointing to the critical
places in the code which are to be changed and even 
by sending short code fragments. (I prefer e-mail.) 
The implementation is not difficult. Please pass
this suggestion to POV-Team if you think that it is a 
step forward.

<snip>

	y.

Post a reply to this message

On Tue, 21 Sep 1999 23:22:02 +0200, Tomas Plachetka wrote:
>Not exactly. Actually, I was thinking about 
>#if(start,end) as about the shorthand for 
>#if (start < clock & clock < end). But it's 
>not *only* a shorthand. A special #if syntax 
>would also tell the parser to skip the parsing
>if the clock value is outside the limits. This
>is something what the parser cannot do when it
>sees #if (start < clock & clock < end).

But you don't want to skip the parsing if the clock value is outside 
the limits.  You need to parse it as if it were in the scene but not
static.  For what you want, you'd do

#static (start, end)
#if (start < clock & clock < end)
 ...
#end
#end

The #static says "this code produces the same result for all clock
values from start to end" and the #if says "don't parse this code 
for the other clock values."

This means you can also say

#static (.1,.2)
#static (.3,.4)
  ...
#end
#end

to denote code that produces the same result over clocks in the
interval (.1,.2) and a different (but fixed) result over clocks
in the interval (.3,.4).  It will be parsed once for each of 
those intervals, and for every frame outside both those intervals.
This could represent a figure that moves into the scene, stops, 
turns around, stops, and then moves out of the scene.

>Anyway, you are right. The special #if syntax 
>does not suggest that the parser will try to
>skip the block for a frame outside the limit.

There's a reason for that: it shouldn't try to do so.

>Wait a moment... (looking into tokenize.c,
>Parse_Directive, Skip_Tokens, Get_Token).
>Interesting... I'm lazy to study the code now,
>but I would say that all directives, even those
>in a FALSE branch of an #if get parsed! Is it
>really so? Is it really needed? 

Some must be at least partially parsed, yes.  In particular, anything
that has a corresponding #end (#macro, #while, #ifdef, or #if) must be
at least recognized, so that the correct #end can be found to terminate
the false section.  Comments must also be parsed completely.  Nothing 
more need be done.  Whether it is or not is something I can't answer at 
the moment, not having delved that deeply into the directive-parsing 
code myself.  If #includes (for example) get parsed anyway, that would 
be a bad thing indeed.

>Damned. I think that we both are overlooking
>one important detail. We are discussing the
>language. But we should also consider what 
>should happen with the objects in memory. When
>is an object/texture/etc supposed to be released?

When the usual cleanup is done, objects will only be deleted if they
are either not static or the next frame will have a clock value beyond
the range for which they were declared static.

>(The clock
>function is not necessarily monotone. During an
>animation, an object/texture/etc. can be 
>sometimes there and sometimes not.)

The clock function is indeed monotone, and in fact increases by a fixed
amount for each frame.  If an object is sometimes there and sometimes 
not, then it is not static for that entire duration (but may be static
for a number of smaller durations.)

>This is my wish list:
>- diffuse in a texture is now a float. It could
>be defined for rgb channels separately.
>- phong, ditto.
>- specular, ditto.
>- if there is something I forgot, ditto.

[...]

>I can help by pointing to the critical
>places in the code which are to be changed and even 
>by sending short code fragments. (I prefer e-mail.) 
>The implementation is not difficult. Please pass
>this suggestion to POV-Team if you think that it is a 
>step forward.

The best way to get new code into the official version is to write
it and make it available to the POV-Team.  It helps if you can 
present a case to justify the change, as well, but you obviously 
have one in mind.  If you just say "feature X would be cool" 
you're likely to be ignored, but saying "feature X is cool; here's
why and here's code that does it" is much more likely to get a 
favorable response.

Post a reply to this message

I'm beginning to think that #static as a type of #declare would be more
feasible, after all it is only usefull for things which take a long time
to parse such as complex unions and meshes.

When parsing a #static declaration, check if the name is already in the
symbol table.  If it is then skip to the end of the declaration.

How do you know what's the end of the declaration?
Firstly all declarations should end with a semi colon.  Then each
[#declare|#local|#static] would match up with a semi colon.

#static ST = union{
  #declare A=0;#while(A<360)
    sphere{x*10,1 rotate y*A}
    #declare A=A+12;#end
  }; <- this semicolon marks the end of the #static declaration.

#undef works on #statics the same as #declares
e.g. #if(clock = 0.5) #undef ST #end

Any how, just an idea.
Cheers, PoD.

Post a reply to this message

PoD <pod### [at] merlinnetau> wrote:
: I'm beginning to think that #static as a type of #declare would be more
: feasible, after all it is only usefull for things which take a long time
: to parse such as complex unions and meshes.

  You forget that you can make #while-loops which take hours to parse although
it creates only some simple objects.

: When parsing a #static declaration, check if the name is already in the
: symbol table.  If it is then skip to the end of the declaration.

: How do you know what's the end of the declaration?
: Firstly all declarations should end with a semi colon.  Then each
: [#declare|#local|#static] would match up with a semi colon.

  You still have to parse the entire code to see where is the matching 
semicolon.
  There's no way to avoid parsing other than copying the whole source code
to memory without the static parts of it and then parse this copy.

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

Ron Parker wrote:
> 
> On Tue, 21 Sep 1999 23:22:02 +0200, Tomas Plachetka wrote:
> >Damned. I think that we both are overlooking
> >one important detail. We are discussing the
> >language. But we should also consider what
> >should happen with the objects in memory. When
> >is an object/texture/etc supposed to be released?
> 
> When the usual cleanup is done, objects will only be deleted if they
> are either not static or the next frame will have a clock value beyond
> the range for which they were declared static.
>
> >(The clock
> >function is not necessarily monotone. During an
> >animation, an object/texture/etc. can be
> >sometimes there and sometimes not.)
> 
> The clock function is indeed monotone, and in fact increases by a fixed
> amount for each frame.  If an object is sometimes there and sometimes
> not, then it is not static for that entire duration (but may be static
> for a number of smaller durations.)

This is something I didn't know about (that the 
clock function is always monotone). I thought 
of it as of a variable which is automatically 
declared and has a special meaning... 
Are you sure that the user cannot assign an
arbitrary value to clock in the .pov code?!

> >This is my wish list:
> >- diffuse in a texture is now a float. It could
> >be defined for rgb channels separately.
> >- phong, ditto.
> >- specular, ditto.
> >- if there is something I forgot, ditto.
> 
> [...]
> 
> >I can help by pointing to the critical
> >places in the code which are to be changed and even
> >by sending short code fragments. (I prefer e-mail.)
> >The implementation is not difficult. Please pass
> >this suggestion to POV-Team if you think that it is a
> >step forward.
> 
> The best way to get new code into the official version is to write
> it and make it available to the POV-Team.  It helps if you can
> present a case to justify the change, as well, but you obviously
> have one in mind.  If you just say "feature X would be cool"
> you're likely to be ignored, but saying "feature X is cool; here's
> why and here's code that does it" is much more likely to get a
> favorable response.

For instance, it can prove helpful when converting from
VRML. A material node in VRML looks like:
Material { 
  exposedField SFFloat ambientIntensity  0.2         # [0,1]
  exposedField SFColor diffuseColor      0.8 0.8 0.8 # [0,1]
  exposedField SFColor emissiveColor     0 0 0       # [0,1]
  exposedField SFFloat shininess         0.2         # [0,1]
  exposedField SFColor specularColor     0 0 0       # [0,1]
  exposedField SFFloat transparency      0           # [0,1]
}

I am aware of the difference between POV-Ray and VRML
lighting models. However, let's say that someone wants 
to convert to .pov anyway. As it is now, at least the 
specularColor cannot be properly modulated in .pov for 
each of the RGB channels separately. The extension I 
propose would allow this. I believe that the extension 
could be helpful also in other cases. Moreover, it makes 
POV-Ray more consistent (a colour as well as a 
coefficient could be used not only for ambient but also 
for diffuse, etc.).

As for submitting the patched sources:
If the above argumentation is reasonable enough for 
including the proposed changes into the superpatch, 
I'll do that (otherwise not).

Would patched POV-Ray 3.02 sources be OK for POV-Team?
If not, then which ones?

	y.

Post a reply to this message

On Wed, 22 Sep 1999 17:00:12 +0200, Tomas Plachetka wrote:
>This is something I didn't know about (that the 
>clock function is always monotone). I thought 
>of it as of a variable which is automatically 
>declared and has a special meaning... 
>Are you sure that the user cannot assign an
>arbitrary value to clock in the .pov code?!

POV treats it as a scalar function with no arguments.  I get an
error when I try to assign to it.

>As for submitting the patched sources:
>If the above argumentation is reasonable enough for 
>including the proposed changes into the superpatch, 
>I'll do that (otherwise not).

I'll include just about anything in the superpatch, as long as it
doesn't conflict with something else that's either already included
or otherwise available, in which case I'll have to decide which one
to include so as not to make a total mess.

>Would patched POV-Ray 3.02 sources be OK for POV-Team?
>If not, then which ones?

I don't speak for the POV-Team, so I can't say for sure, but I'd 
guess patched 3.1 sources would be far more useful.  There were 
some fairly large changes between the two (Believe me - I had to 
merge the 3.1 sources into the superpatch as "just another patch 
to 3.02."  It took several hours.)

Post a reply to this message

Nieminen Juha wrote:
> 
>   You still have to parse the entire code to see where is the matching
> semicolon.
>   There's no way to avoid parsing other than copying the whole source code
> to memory without the static parts of it and then parse this copy.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

	Depends what you call "parsing"... For example, you don't have to
execute a #while loop to find the corresponding #end, but executing it
is still a part of scene parsing, so there a #static could bring lots of
improvement... Moreover, I seem to remember Ron saying that what took
the most time was memory allocation, so even if you need to read the
#static parts of the scene you could still gain time since you won't be
allocating any memory for them...

	Just my $0.02
		Jerome

-- 
*******************************
* Always listen to experts,   * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why...          * http://www.enst.fr/~jberger
* Then do it.                 *
*******************************

Post a reply to this message

Ron Parker wrote:
> 
> On Wed, 22 Sep 1999 17:00:12 +0200, Tomas Plachetka wrote:
> >This is something I didn't know about (that the
> >clock function is always monotone). I thought
> >of it as of a variable which is automatically
> >declared and has a special meaning...
> >Are you sure that the user cannot assign an
> >arbitrary value to clock in the .pov code?!
> 
> POV treats it as a scalar function with no arguments.  I get an
> error when I try to assign to it.

I take back some of my previous remarks. They were 
based on a wrong assumption.

> >As for submitting the patched sources:
> >If the above argumentation is reasonable enough for
> >including the proposed changes into the superpatch,
> >I'll do that (otherwise not).
> 
> I'll include just about anything in the superpatch, as long as it
> doesn't conflict with something else that's either already included
> or otherwise available, in which case I'll have to decide which one
> to include so as not to make a total mess.

I see.

> >Would patched POV-Ray 3.02 sources be OK for POV-Team?
> >If not, then which ones?
> 
> I don't speak for the POV-Team, so I can't say for sure, but I'd
> guess patched 3.1 sources would be far more useful.  There were
> some fairly large changes between the two (Believe me - I had to
> merge the 3.1 sources into the superpatch as "just another patch
> to 3.02."  It took several hours.)

I've never seen the 3.1 sources. "Fairly large changes" 
can slow me down but if I find the time, I'll patch the 
3.1 sources soon. Whom should I send them then?

Your last remark confused me. What do you mean by 
merging 3.1 sources into the superpatch? As far as I 
know, the superpatch is based on 3.1, not on 3.02. Or 
am I wrong? 
Then - if the superpatch is really based on 3.02 -
wouldn't it really be easier for POV-Team (or whoever)
to merge yet another 3.02 patch into the superpatch?

	y.

Post a reply to this message

On Wed, 22 Sep 1999 19:39:19 +0200, Tomas Plachetka wrote:
>Your last remark confused me. What do you mean by 
>merging 3.1 sources into the superpatch? As far as I 
>know, the superpatch is based on 3.1, not on 3.02. Or 
>am I wrong? 

It was originally based on 3.02, as were most of the patches included
in it when I first released it.  The first released version was "based
on" 3.1, meaning I had at that point merged 3.1 in and it could be used
as a basis for further patching.  

>Then - if the superpatch is really based on 3.02 -
>wouldn't it really be easier for POV-Team (or whoever)
>to merge yet another 3.02 patch into the superpatch?

I maintain the superpatch; it's an unofficial version that has nothing
to do with the POV-Team, other than that they're rumored to be looking
at it as an aid to making the official version 3.5.   The version they
have is based on 3.1, as are all publicly released versions.

Post a reply to this message

Ron Parker wrote:

> It was originally based on 3.02, as were most of the patches included
> in it when I first released it.  The first released version was "based
> on" 3.1, meaning I had at that point merged 3.1 in and it could be used
> as a basis for further patching.
> 
> >Then - if the superpatch is really based on 3.02 -
> >wouldn't it really be easier for POV-Team (or whoever)
> >to merge yet another 3.02 patch into the superpatch?

...and if you want to be technically accurate everything in POV-Ray is based
on DKBTrace :)

-- 
Ken Tyler

See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Ron Parker wrote:
> 
> On Wed, 22 Sep 1999 19:39:19 +0200, Tomas Plachetka wrote:
> >Your last remark confused me. What do you mean by
> >merging 3.1 sources into the superpatch? As far as I
> >know, the superpatch is based on 3.1, not on 3.02. Or
> >am I wrong?
> 
> It was originally based on 3.02, as were most of the patches included
> in it when I first released it.  The first released version was "based
> on" 3.1, meaning I had at that point merged 3.1 in and it could be used
> as a basis for further patching.

Thanks for an explanation. I'm not confused anymore.
(At least in concern with this.)

> >Then - if the superpatch is really based on 3.02 -
> >wouldn't it really be easier for POV-Team (or whoever)
> >to merge yet another 3.02 patch into the superpatch?
> 
> I maintain the superpatch; it's an unofficial version that has nothing
> to do with the POV-Team, other than that they're rumored to be looking
> at it as an aid to making the official version 3.5.   The version they
> have is based on 3.1, as are all publicly released versions.

I see and am trying to reconstruct the recent
history... I think I got it:
The idea of a superpatch comes from people outside 
of the POV-Team (maybe not, it's not so important). 
A group of volunteers (SPatch-Team) decided to do 
it. You and maybe a few other people of SPatch-Team 
did the integration. This all happened in the times 
of 3.02. Meanwhile POV-Team released an official 
version 3.1. To avoid a divergence of POV-Ray 3.1 
and SPatch 1.0, the official 3.1 sources must have 
been merged with the actual SPatch sources as soon
as possible.

Now I also understand why the merging took you a 
long time and do not envy you the work.

OK, back to the business: When my patch is ready,
whom should I send it to ? To you? Or to 
news://news.povray.org/povray.patches?
In the later case, is there an official procedure 
about how to post patches to the povray.patches?
And if so, where could I read it?
(Forgive my stupid questions, I'm a newbie here.)

	y.

Post a reply to this message

Nieminen Juha wrote:
>   You still have to parse the entire code to see where is the matching
> semicolon.
>   There's no way to avoid parsing other than copying the whole source code
> to memory without the static parts of it and then parse this copy.

How about considering #static as an alternative to #include?
There would be two acceptable forms the parser would expect...

#static /filename/

or

#static (/filename/,/start/,/end/)

If the former was encountered, POV would parse the include file 
indicated by "filename" once on the first frame rendered, then just 
retain it until all frames were completed. 

For the latter syntax, it would behave exactly like #include until 
frame # "start" was reached, then parse one more time and hold until 
either frame # "end" was reached, or all the specified frames were 
completed (whichever comes first, depending on the INI file options 
selected). If more frames than "end" are rendered, just go back to
considering it identical to saying #include after the last rendered
frame.

This way, if the static section does not need reparsing, POV need
only read a single line to discover this and move on. And of course,
it leaves responsibility for deciding what should be static firmly
on the shoulders of the user, where it belongs. 

Charles
-- 
http://www.enter.net/~cfusner
"...Then darkness took me, and I strayed out of thought and time,
 and I wandered far on roads that I will not tell..." 
                              -The Two Towers, JRR Tolkien

Post a reply to this message

On Wed, 22 Sep 1999 23:19:52 +0200, Tomas Plachetka wrote:
>OK, back to the business: When my patch is ready,
>whom should I send it to ? To you? Or to 
>news://news.povray.org/povray.patches?
>In the later case, is there an official procedure 
>about how to post patches to the povray.patches?
>And if so, where could I read it?
>(Forgive my stupid questions, I'm a newbie here.)

You can post it to povray.binaries.programming and post a note
about it in povray.unofficial.patches so we know to look for it
there.  That way everyone can enjoy it, even it if takes me the
usual months to get it into the superpatch. :)  As for how to 
get patches into the official version, I'm not sure there is an
official documented method, but at least one team member will 
see it in the unofficial.patches group.

Post a reply to this message

On Wed, 22 Sep 1999 17:27:23 -0400, Charles wrote:
>Nieminen Juha wrote:
>>   You still have to parse the entire code to see where is the matching
>> semicolon.
>>   There's no way to avoid parsing other than copying the whole source code
>> to memory without the static parts of it and then parse this copy.
>
>How about considering #static as an alternative to #include?
>There would be two acceptable forms the parser would expect...
>
>#static /filename/
>
>or
>
>#static (/filename/,/start/,/end/)

Or, using the syntax I proposed,

#static (start, end)
#include "filename"
#end

Post a reply to this message

Ron Parker wrote:
> 
> On Wed, 22 Sep 1999 17:00:12 +0200, Tomas Plachetka wrote:
> >This is something I didn't know about (that the
> >clock function is always monotone). I thought
> >of it as of a variable which is automatically
> >declared and has a special meaning...
> >Are you sure that the user cannot assign an
> >arbitrary value to clock in the .pov code?!
> 
> POV treats it as a scalar function with no arguments.  I get an
> error when I try to assign to it.
> 

But you can change the clock value and clock delta in an arbitrary manner during
an animation. Just #write the appropriate initial_clock, final_clock,
initial_frame and final_frame options to an ini file.

Margus

Post a reply to this message

On Thu, 23 Sep 1999 01:03:51 +0300, Margus Ramst wrote:
>Ron Parker wrote:
>> 
>> On Wed, 22 Sep 1999 17:00:12 +0200, Tomas Plachetka wrote:
>> >This is something I didn't know about (that the
>> >clock function is always monotone). I thought
>> >of it as of a variable which is automatically
>> >declared and has a special meaning...
>> >Are you sure that the user cannot assign an
>> >arbitrary value to clock in the .pov code?!
>> 
>> POV treats it as a scalar function with no arguments.  I get an
>> error when I try to assign to it.
>> 
>
>But you can change the clock value and clock delta in an arbitrary manner during
>an animation. Just #write the appropriate initial_clock, final_clock,
>initial_frame and final_frame options to an ini file.

But wouldn't you then have to restart the renderer for those options to take 
effect?  If not, I'd say that's a bug.  Even if you can, you shouldn't use
#static if you're gonna play around with the poor thing's mind like that.

Post a reply to this message

Ron Parker wrote:
> 
> But wouldn't you then have to restart the renderer for those options to take
> effect?

Come to think of it, I haven't tried. And I agree, it's too twisted to worry
about :)

Margus

Post a reply to this message

Nieminen Juha wrote:
> 
> PoD <pod### [at] merlinnetau> wrote:
> : I'm beginning to think that #static as a type of #declare would be more
> : feasible, after all it is only usefull for things which take a long time
> : to parse such as complex unions and meshes.
> 
>   You forget that you can make #while-loops which take hours to parse although
> it creates only some simple objects.

You could make a #while loop which takes days to parse and creates no
objects at all

> 
> : When parsing a #static declaration, check if the name is already in the
> : symbol table.  If it is then skip to the end of the declaration.
> 
> : How do you know what's the end of the declaration?
> : Firstly all declarations should end with a semi colon.  Then each
> : [#declare|#local|#static] would match up with a semi colon.
> 
>   You still have to parse the entire code to see where is the matching
> semicolon.

If a #while loop is inside a #static declaration, you'd only have to
look for the matching #end which would not take long at all.
#include would be totally ignored.

>   There's no way to avoid parsing other than copying the whole source code
> to memory without the static parts of it and then parse this copy.

What difference does reading it into memory make?

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

Ron Parker wrote:
> 
> Or, using the syntax I proposed,
> 
> #static (start, end)
> #include "filename"
> #end

True. Three lines instead of one isn't going to make a significant 
difference to parsing, although it's slightly more trouble to type,
so the above would give almost identical results -- *if* the end 
user applies it correctly. 

I only mentioned it as a supplement to #include (analogous to the 
way #local is a specialized supplement to #declare) because problems 
with making it a #static block were brought up. As an alternative 
to #include, there'd be no block, and users would have to
externalize the static info to a separate file because... that's 
just the way it works. 

Whereas, if you require the user to set up a #static block with an 
embedded #include in it, sure as there's rain you'll have people 
who skip the #include and just stuff hundreds of lines of code 
between #static and its corresponding #end and complain that it 
isn't making the kind of difference they think it ought to (and
Warp will have to add something new to the VFAQ). As much as I 
hate "protect them from their own stupidity" style programming... 

Well, I'm a scene coder, not a programmer. I only mention it 
in passing, FWIW. 


Charles
-- 
http://www.enter.net/~cfusner
"...Then darkness took me, and I strayed out of thought and time,
 and I wandered far on roads that I will not tell..." 
                              -The Two Towers, JRR Tolkien

Post a reply to this message