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