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

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