Ken wrote:
/.../ 
> Better yet would be light{}, cam{}, tex{}, pig{}, obj{}, tri{},
> smthtri{}, sph{}, cyl{}, tor{}, sprlips{}, and I think you get the idea.
> 

I think this could be annoying to the user. When I mis-type
superellipsoid, I can logically deduct what's wrong. When I mis-type
sprlips, what next? I can try superlips <g>, suprlps, sprellips, splips,
sprlps etc...
Granted, I'll learn as time goes by, but why confuse matters? Most good
editors have macro keys to save typing.

Margus

Post a reply to this message

Bob Hughes schrieb in Nachricht <36D4526F.97901B37@aol.com>...
>Think you lost me more than I you.
>Simply put, if you had 'light source' instead of 'light_source' and
>there was a way the pvengine would only see it when written that way,
>ie. *not* when typed in as 'source light' or 'light color' (parser would
>say "What the...!? then), I would certainly like that way of things.
>

It is possible and done before, but I'm afraid the parser would even be
slower than it is now (and it really is, IMHO - please let's not discuss the
speed of the parser again, not here).

But radically changing the keywords is not what we need. I'd rather see a
more object oriented approach, where every object (where light_sources and
cameras would also be objects) would have a predefined set of properties,
which can either be set or read and have a default value. I'm not asking for
data encapsulation or inheritance (yet <g>) or any other *real* object
oriented behaviour, just for a slightly different approach. In fact we
almost have this, but now all properties of objects are keywords too. That
would be too much. All the different types in some objects could just as
well be named constants. Also look_at and position wouldn't be keywords
anymore, but simple properties, where the naming conventions could be
different (e.g. Camera1.LookAt and Camera1.Position - my favourites).

camera {
  Position <1, 1, 1> // or even "Position = <1, 1, 1>"
  Up <0, 1, 0>       //         "Up = <0, 1, 0>
  LookAt <0, 0, 0>   //         "LookAt = <0, 0, 0>
}

light {
  ....

#declare MyBlob = blob {
  Threshhold = 0.7;
  Elements =

    sphere

etc. etc.

But on the other side, this would perhaps turn the script language even more
into a programming language. Good for programmers, bad for non-programmers,
who would have an ever steeper learning curve.

It would propably also make the parser faster (because of the stricter rules
applied), but also much less flexible. Although flexiblity can lead to
sloppiness and mistakes which are hard to find.

There are pros and cons to each approach (the current one and the one I'd
like to see).

So propably the best thing would be to leave it as it is and just add more
and more keywords (either with or without underscores). I could live with
that, as long as the parser speed would be improved constantly.
--
Rudy Velthuis

Post a reply to this message

Spider schrieb in Nachricht <36D46A96.FF2A70EC@bahnhof.se>...
>Well, I'm OOP in every-way... (I do JAVA as well :-)
>But, I think POV animations and several other things would be easier o
>acces with .<variable>
>Perhaps only read-only (only an only to many?) but it would still be
>nice.

See my reply to Bob Hughes too (today, 14:17). It would really be nice to
have them, as properties and not as keywords. There are far too many
keywords wasted for this. Every aspect of every object is considered a
keyword, not a property. If they were properties specific to an object (or a
class of objects), there would be less name clashes, so the keywords could
be shorter and simpler. Also the syntax would be simpler and clearer (to me
at least).

The problem with the POV script language is the fact that it was a very
simple language which has grown so radically, that more and more keywords
had to be introduced. This is because the language had a C-like syntax and
didn't treat objects the OO way then. So there either has to be a radical
change to it, making it more like it should be: an object oriented
description language, or the wild growth is likely to continue.

But I'm afraid we won't find many in the POV-Team to agree with us. And we
might also upset old-time users, who often know the keywords by their first
and last names.

--
Rudy Velthuis

Post a reply to this message

On 24 Feb 1999 08:43:25 -0500, Nieminen Mika <war### [at] cctutfi> wrote:

>Peter Popov <pet### [at] usanet> wrote:
>
>  Now, here we have a person who definitively have been raytracing too
>long... ;)

Thank you, Warp! It was about time someone realised it :)


---------
Peter Popov
ICQ: 15002700

Post a reply to this message

Rudy Velthuis wrote:
> 
> Spider schrieb in Nachricht <36D46A96.FF2A70EC@bahnhof.se>...
> >Well, I'm OOP in every-way... (I do JAVA as well :-)
> >But, I think POV animations and several other things would be easier o
> >acces with .<variable>
> >Perhaps only read-only (only an only to many?) but it would still be
> >nice.
> 
> See my reply to Bob Hughes too (today, 14:17). It would really be nice to
> have them, as properties and not as keywords. There are far too many
> keywords wasted for this. Every aspect of every object is considered a
> keyword, not a property. If they were properties specific to an object (or a
> class of objects), there would be less name clashes, so the keywords could
> be shorter and simpler. Also the syntax would be simpler and clearer (to me
> at least).
> 
> The problem with the POV script language is the fact that it was a very
> simple language which has grown so radically, that more and more keywords
> had to be introduced. This is because the language had a C-like syntax and
> didn't treat objects the OO way then. So there either has to be a radical
> change to it, making it more like it should be: an object oriented
> description language, or the wild growth is likely to continue.
> 
> But I'm afraid we won't find many in the POV-Team to agree with us. And we
> might also upset old-time users, who often know the keywords by their first
> and last names.
> 
> --
> Rudy Velthuis

  Since  I don't have the advantage of a programmers background the idea of
assigning properties to a function as opposed to assigning a keyword is
being lost on me. How can you do one without the other ?

  I have always worked with the assumption that it is the job of the scene
file writer, that would be us, to pass commands to the program. It needs
this kind of input from the operater in order to process the information
in a manner consistent with out needs. If you don't have specific terms
(keywords) for assigning properties to a function you are passing to the
program how will it know what you what it to do ?

  On the topic of changing the current scene file language I see the
possibility of heavy opposition. There are the considerations of ease
of learning a difficult program like this because of it's rich, easy to
understand, object oriented language. You don't have to be a programmer
to use Pov it if you are determined enough and it shows what people are
willing to go through to see all of them pretty pictures that come out it.

 Another important point is the incredibly vast amount of resources available
that have been written as support for the program and all of these rely on
the program language not changing. If you change the language you retire the
work of people from the last 8 years many of which have finally begun to evolve
into something useful.

 Additionaly there is the Pov Teams desire to maintain backward compatibility 
with it's own incarnations. This kind of change not only has a clear and
immediate impact on every user out there, it also makes many thousands of
scene files obsolete and useless. The amount of blood, sweat, and tears, that
went into the making to those scene files would make the person who changed
the program into something considerably less than a saint or friend of the
people.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken schrieb in Nachricht <36D62965.52AF9E50@pacbell.net>...
>Rudy Velthuis wrote:
>>
>> The problem with the POV script language is the fact that it was a very
>> simple language which has grown so radically, that more and more keywords
>> had to be introduced. This is because the language had a C-like syntax
and
>> didn't treat objects the OO way then. So there either has to be a radical
>> change to it, making it more like it should be: an object oriented
>> description language, or the wild growth is likely to continue.
>>
>> But I'm afraid we won't find many in the POV-Team to agree with us. And
we
>> might also upset old-time users, who often know the keywords by their
first
>> and last names.
>>

>  Since  I don't have the advantage of a programmers background the idea of
>assigning properties to a function as opposed to assigning a keyword is
>being lost on me. How can you do one without the other ?

I don't see an object as a function. An object is something which has
properties and can do something too (even if it is something silly like
falling sown or breaking).

Now POV is not ready for the doing yet, but IMHO every object has common
properties (texture, size, bounding box) and some specific ones: a sphere
has a radius and a center, a cone two "centers" and two radii, a cylinder
two "centers" but one radius, a box two opposite corners, etc. etc.

I would like to be able to access these properties, like in

#declare MyVect = sphere1.Center

or

#declare MyTexture = box1.Texture



>  I have always worked with the assumption that it is the job of the scene
>file writer, that would be us, to pass commands to the program. It needs
>this kind of input from the operater in order to process the information
>in a manner consistent with out needs. If you don't have specific terms
>(keywords) for assigning properties to a function you are passing to the
>program how will it know what you what it to do ?

I have a different concept of "keyword". In most scripts and programming
languages, keywords are a small set of control words, which define the
language (like "for", "while", "begin", "end", "switch", "object", "struct",
"int", etc.). All other words are just identifiers, which stand for a
string, a character, a numeric, an object/class, a structure etc.

There are many keywords in POV-Ray which are in fact just representations of
a numeric, like
prism's linear_spline, quadratic_spline, cubic_spline, bezier_spline,
linear_sweep and conic_sweep. They are in fact just numerics which were
given a name. In my concept they would be constants or enumeration types,
which (jn this case) represent numbers. It would have done, if the creators
of POV had #declared these words as numerics and had made the PRISM_ITEM
property of a prism a numeric:

#declare linear_spline = 1
#declare quadratic_spline = 2
...


prism { linear_spline, 0, 1, etc...

would be equivalent to

prism { 1, 0, 1 etc...

Rememer, in POV-Ray we often use constants like that: the colors White or
Black, the finishes Shiny or Dull, etc. They are all examples of constants,
representing a POV structure. They are not keywords, although they influence
the output of the program of course. I would liked to have the same kind of
constant definitions for many values which are declared as keywords now. I
would like to get rid of these pseudo-keywords, without upsetting the
language. Of course there could/should be some kind of standard .inc, which
would automatically be defined, even if it were not physically present on
the (hard) disk (some kind of standard "run time" library). To most users it
wouldn't make a big difference, they wouldn't even notice it. Only the
semantics (the true meaning behind it) of the words would differ, not
necessarily their use or their output.

If I decide to #declare a linear_spline now, I'll get an error message. To
avoid these kind of conflicts, the POV creators defined rather extensive
keywords like "linear_spline". If there were only a few keywords, they could
be rather short, and the spline item could just as well be called "linear",
because it would only be valid inside the prism (like any property would
only be valid inside the object it is defined for), and it would be known it
were a spline item:

prism {
  Linear
  // etc.
}

 So you could use the same word in different objects with a slightly
different meaning. But they would not be keywords anymore, they would be
properties of this object (class). And if I would #declare a variable
Linear, it would not be confused with prism.Linear.

>  On the topic of changing the current scene file language I see the
>possibility of heavy opposition. There are the considerations of ease
>of learning a difficult program like this because of it's rich, easy to
>understand, object oriented language. You don't have to be a programmer
>to use Pov it if you are determined enough and it shows what people are
>willing to go through to see all of them pretty pictures that come out it.

I see this too. That's propably why we will have to cope with the old
POV-Ray script language much longer. Although it wouldn't be too hard to
make two different front-ends for the rendering machine. But if I understand
right, the POV-Team objects to this because of the possible danger of people
using (and making money with) their rendering back-end without the proper
front-end (script language parser) and without their consent.

> Another important point is the incredibly vast amount of resources
available
>that have been written as support for the program and all of these rely on
>the program language not changing. If you change the language you retire
the
>work of people from the last 8 years many of which have finally begun to
evolve
>into something useful.

Not really. You wouldn't change POV-Ray 3.1, so it would still be available.
Many programs written for DOS had to be rewritten for Windows. So why
couldn't Moray, sPatch etc. be rewritten for a newer language version? This
is not really very hard. E.g. converting Moray to Windows must have been
much harder.

> Additionaly there is the Pov Teams desire to maintain backward
compatibility
>with it's own incarnations. This kind of change not only has a clear and
>immediate impact on every user out there, it also makes many thousands of
>scene files obsolete and useless. The amount of blood, sweat, and tears,
that
>went into the making to those scene files would make the person who changed
>the program into something considerably less than a saint or friend of the
>people.

These scene files would still render with the current POV-Ray.

And the changes wouldn't be too drastic. POV-Ray has changed in the mean
time too (the treatment of commas, the semicolons in single line #declares,
the demission of halo come into my mind). It would be easy to write a little
conversion utility to translate 3.x source to the new source. Most of the
source wouldn't even have to change. Propably only the syntax would have to
be stricter, perhaps even that would be unnecessary (I know how many would
object to that alone).

BTW, most of my views presented here are not fully though out, but I think
one could get rid of many pseudo-keywords without turning old scenes
invalid. One would perhaps only have to include one or a few new standard
.inc files, doing the #declaration of the pseudos as constants.

But I know, this is propably a very impopular view altogether, so I do not
expect any changes along these or similar lines. It would be nice though, if
we could at least *read* some of the properties of some objects
(camera.position or light_source.color).

 --
Rudy Velthuis

Post a reply to this message

On Fri, 26 Feb 1999 21:17:12 +0100, Rudy Velthuis <rve### [at] gmxnet> wrote:
>There are many keywords in POV-Ray which are in fact just representations of
>a numeric, like
>prism's linear_spline, quadratic_spline, cubic_spline, bezier_spline,
>linear_sweep and conic_sweep. They are in fact just numerics which were
>given a name. In my concept they would be constants or enumeration types,
>which (jn this case) represent numbers. It would have done, if the creators
>of POV had #declared these words as numerics and had made the PRISM_ITEM
>property of a prism a numeric:
>
>#declare linear_spline = 1
>#declare quadratic_spline = 2
>...

In fact, if you look in the appropriate places, you'll find that some of
the radiosity constants are declared just this way, so it will work in a
limited sense.  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.  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}

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 guess what I don't understand is why you ever need camera.lookat.  Consider:

Your way:

  #declare MyCamera=camera {
    location -20*z
    look_at Complex_Slow_Macro_Expression( foo, bar, baz )
  } 

  camera{ MyCamera }
  sphere { MyCamera.look_at, 1 texture {pigment {color red 1}}}

My way:

  #declare camera_look_at=Complex_Slow_Macro_Expression( foo, bar, baz );
  camera {
    location -20*z
    look_at camera_look_at
  } 

  sphere { camera_look_at, 1 texture {pigment {color red 1}}}

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.

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.)

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.

Post a reply to this message

I agree with your ideas and thoughts, and the arguments..
perhaps something for 3.5, together with the c++ code :-)


-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

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

Peter Popov wrote:
> 
> It's strange what things can inspire you when your brain's been
> operpoved.

<snip>

> Now the question is, how the heck do I model all that in just a
> lifetime? And how many Cray supercomputers will I need to render it?

Um.. "A Suffusion of Yellow"?

-Xplo

Post a reply to this message