Ron Parker schrieb in Nachricht <36d70d85.0@news.povray.org>...
>On Fri, 26 Feb 1999 21:17:12 +0100, Rudy Velthuis <rve### [at] gmxnet>
wrote:

>But the reason for the keywords is that they can be
>specified in any order, or not at all.  Consider, say, the smooth keyword
>in a height_field object.  If we instead had
>#declare smooth=1; #declare no_smooth=0;
>then we would always have to specify either smooth or no_smooth.

There are a few cases like this (smooth, open, hollow), where I wouldn't
change the fact they're keywords.

>And
>because they lack any type information, we'd have to be very careful to
>specify it in just the right order.  I don't know about you, but I already
>get confused about order on some of the more complicated object types such
>as bicubic patches. I'd almost rather see a sphere, say, have keywords for
>radius and center as well and make all the parameters optional (but
>defaulted) so I could say:
>
>// a sphere centered on zero with unit radius:
>sphere {}
>// a sphere centered on zero with radius 2:
>sphere {radius 2}
>// a sphere centered on MyVect with unit radius:
>sphere {center MyVect}

Would be very nice indeed. Every "property" should have a default then, so
it could be left out.


In fact we already have this in a limited sense. Turbulence, scale, rotate
etc. act like this. And here, the order of definition is also important
(esp. scale, rotate and translate).

>This is actually pretty close to what you're proposing, I think, and could
>perhaps even be made backward-compatible, but I think it would have an
adverse
>effect on parse time.

I don't quite understand why the parser must be so slow. Some languages have
a syntax like the one you propose (you define an object and then set the
properties you want to change), but they are not that slow. IMHO, what makes
parsing slow is the fact that the syntax is so flexible: "box { -1, 1 }" and
"box { <-1, -1, -1>, <1, 1, 1> }" are equivalent (I don't know where, but
I've seen more than 6 different syntaxes for one definition somewhere) etc.

Your proposal wouldn't necessarily make parsing much slower than it already
is (IMHO).

>I guess what I don't understand is why you ever need camera.lookat.

>I took some liberties with your way to deal with my opinion that there
>shouldn't be any serious order dependencies within the scene description.
>That is, the declaration of your sphere shouldn't be dependent on the
>declaration of your camera having happened first.

Depends (<g>). I might want to define an object and let another object get
close to it, or touch it, or whatever. Then the order of declaration is
important (I must know where the wall is, before I can bounce against it).
So it's not really camera properties I need, it's more the props of all
other objects I'd like to have (if I need them).

>I just don't understand why, if you know you're going to need it, you
>wouldn't just #declare the look_at position and use that when you need
>it, especially since the alternative is to #declare the camera if you're
>going to look at its members (I can't conceive of any usable syntax for
>looking at the members of anonymous scene elements.)

I agree, I do not necessarily need exactly Camera1.position etc., because I
could say

#declare Camera1 = camera {
  position MyCalculatedPosition
  look_at MyCalculatedLookAt
  etc...

But if I have a definition like this:

#declare Rand4 = random(Seed4);
#declare Box1 = box {
  <-1, -1, -1>, <1, 1, 1>
  rotate 30 * y
  scale 20 * Rand4
  // ....
  translate MyVector
 }

it would be nice to be able to say

#declare NearCorner = Box1.corner1;
#declare FarCorner = Box1.corner2;

and then use NearCorner and FarCorner to create another object.

I could of course use the math functions to simulate the rotation, scaling
etc., but this wouldn't make my scene easier to read, even if I knew all the
math involved (I do, in fact, but propably not everyone).

I always think the language should support the human using it, not the other
way round. So if there are complex calculations, I don't want to be required
to do them myself and then apply them to the object. Let the language do it
and then tell me the result, so I can use it.

>And if everyone would just adhere to the simple rule that keywords should
>be all lowercase and identifiers shouldn't, there would never be any
>collisions.  Perhaps there should be a warning (disabled by #version,
>of course) if you #declare something with an all-lowercase name.

Hmmm... Not really my case.

--
Rudy Velthuis

Post a reply to this message