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