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