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

-- 
*******************************

* 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