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