In article <38CA2519.7A4AFCB5@pacbell.net>, lin### [at] povrayorg 
wrote:

> I think you would be surprised to learn I had more problems thinking 
> in terms of 3D than I did learning POV's scripting language.

Hmm, my biggest problem was remembering all the keywords. :-)
I still can't remember off hand whether no_shadow or shadowless is used 
for an object...the thinking in 3D was actually the easiest part for me.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38ca2675@news.povray.org>, "Bob Hughes" 
<per### [at] aolcom?subject=PoV-News:> wrote:

> I had to wonder about your viewpoint on this for a moment but my 
> sentiments lean toward the hashmark (#) as being one of the things 
> that shows the person, not the parser alone (however that works), 
> where each of those special keywords are.

On the other hand, newbies might be scared away by a file full of 
mysterious commands with hash marks in front of them. :-)
Remember that the reason you use them as visual cues is that you are 
familiar with the language.


> But what may be getting overlooked is how POV has a programmer 
> language of sorts simply by being what it is: textual interface.  The 
> continuance of that into more features isn't the issue I'm sure, it's 
> the syntax that is the hub of this discussion.  By that reasoning it 
> should not ever be a hard-core programming language, instead it 
> should always be a common vocabulary most of all.

Well, it definitely shouldn't become a "hard-core programming language", 
since it's purpose is to describe scenes. But some of the features of 
more advanced languages would make the description of complex scenes 
including trees, plants, particle effects(like the Liquid Spray include) 
much easier. You wouldn't even have to understand them, you could just 
use include files written by others.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA3F4E.54F5C535@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> wrote:

> My own ventures in OO programming and other advanced programming 
> indicate that, though there's no discussion on the necessity of it 
> when it comes to programming efficiency, it also requires a *much 
> higher* level of abstract thinking. This may be natural to full-time 
> programmers, but for many people (including me) these ways of 
> thinking are extraordinary hard, if not impossible, to grasp. Many of 
> the concepts discussed in this thread (or in the programmers' wish 
> lists) are simply out of my intellectual reach.

I think you are getting scared off by the "inheritance" features of most 
object-oriented languages. They are the main source of complexity in 
programming languages, and I don't think they would be necessary or 
useful in POV. What I am talking about(and what I think most other 
people who want OO features are talking about) is adding the ability to 
bind macros and variables to objects, and access the attributes of the 
object. Which seems more intuitive:
#declare MyObject = object {MyObject translate y*3}
or
MyObject.Move(y*3);

You could have a separate Move() macro for a specific object which would 
do things like change the color depending on the distance moved. (like 
in steam dispersing or fire turning into smoke) The code would be much 
less complex, and easier to understand. Copies of the object would have 
the same macros and copies of the variables, but that would be the only 
inheritance-like feature, and is not difficult to understand.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:

> I am not sure if some of these things, like cloud objects, fur, trees,
> etc, would be a good language feature. It would be faster parsing, but
> that is about it. It would be more difficult to modify, if you want to
> customize it you would have to become a patch programmer. These seem
> like things best taken care of by include files and macros.

Well we have features like sky_sphere, rainbow, background, and
fog which are limited in scope but are still included with the
program and serve a purpose. Even limited functionality is better
than no functionality when you have no idea how to code it yourself.
Not everyone who uses POV-Ray has an internet connect nor do they
visit these groups. Many find the program on shareware CD's that
do not have a collection of the include files that we take for
granted. Some of these features like you mentioned can be better
handled and optimized internaly. Have you ever tried Gilles tree
macro with a recursion level over 7 ? MAN! it takes forever to parse.

> Now, something like an L-system object would be a different matter...it
> would still be quite flexible but would also parse much faster and
> probably consume less memory.

And as much material as is available on L-Systems I am surprised a
patch hasn't been presented.

 
> > Good point(s). What I also fear is that if the programming language
> > is extended in POV-Ray to include OO programming, for () loops, and
> > all of the other programming suggestions that have been addressed
> > in this thread, is what is going to happen when some non programming
> > literate POV-User comes to the news groups seeking help and some
> > programmer type gives them an example in the form of these new
> > features ? The programmer types (and there a lot of them here in the
> > groups that answer questions on a regular basis) will quickly adopt
> > the attitude that everyone thinks like them and give examples in
> > their language style of choice, while the real truth of the matter
> > is that they could express themselves in a way that the people
> > seeking help will not understand a word they are saying.
> 
> Do you really think the #for() loop would be harder to understand than a
> #while() loop? I think it would be easier to understand, at least, I
> found it easiest to understand and use when I was learning programming.
> (in Tandy and Commodore BASIC, yuck)

As I mentioned to Mr. Hubert what is easy for you is not always going
to be easy for everyone. Years ago I used for() loops and have completely
forgotten how to use them. AS time goes by I remember and miss them
less.

> And why all the paranoia about object-oriented features? What does a POV
> script do? It manipulates *objects*. The object oriented features would
> only make this simpler. 500 pages? Try 5 pages, for the in depth
> description including examples. I'm not talking about inheritance, that
> wouldn't be necessary. I'm talking about the ability to have objects
> have accessible data(like MyCamera.location) and to attach variables and
> macros to objects.

And I keep seeing the same tired example. What else can you do with OO
that you can't already do in POV-Ray ? How many of the current users will
be able to understand a scene example from you using OO if you provided
one ? Even other programmers balk at the idea. Shouldn't the non programmer
user also worry ?
 
> > I would probably not use the new version if it became to hard to
> > learn. This would restrict me to using the older versions of the
> > program and I would miss out on new features.
> 
> Few of the feature requests I have seen would cause problems with
> backward compatability...

Ok, you maintain backward compatibility but how much bloat will it
add ? Will POV-Ray run faster ?

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Chris Huff wrote:

> object. Which seems more intuitive:
> #declare MyObject = object {MyObject translate y*3}
> or
> MyObject.Move(y*3);

To me the first example is more intuitive. Where does Move come from ?

I don't like the idea that I would have to make a macro just to move an
object. Seems like extra work to me. Point still not conceded.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CA6435.A9A33FAA@pacbell.net>, lin### [at] povrayorg 
wrote:

> Well we have features like sky_sphere, rainbow, background, and
> fog which are limited in scope but are still included with the
> program and serve a purpose. Even limited functionality is better
> than no functionality when you have no idea how to code it yourself.

I don't see how they compare...clouds can be done with the sky_sphere, 
if that is the type of thing you are talking about. If you are talking 
about actual clouds, instead of a background effect, I don't see how 
this could possibly be done and be easier or faster than media clouds. 
Are you talking about a kind of sky_sphere with a special cloud 
generating algorithm for it's pigment? Then why not just add a new kind 
of pigment and use the current sky_sphere? Less features to learn and 
keywords to memorize...and you would be able to use it with other things.

Clouds are just something better put in the scene file than in hard to 
change source code. There are even include files that come with the 
program that do clouds...fog, background, rainbow, and sky_sphere would 
also be bad things to hard-code, since they need to be changed 
frequently. Maybe you want something like a "cloud box", which would be 
an automated way of putting a layer of media in the sky?


> Not everyone who uses POV-Ray has an internet connect nor do they
> visit these groups. Many find the program on shareware CD's that
> do not have a collection of the include files that we take for
> granted. Some of these features like you mentioned can be better
> handled and optimized internaly. Have you ever tried Gilles tree
> macro with a recursion level over 7 ? MAN! it takes forever to parse.

Actually, I haven't. But I have tried my own tree macros with recursions 
of over 20. And some of my particle simulations have had extremely long 
parse times.
Why would it have to be included in the program itself? It could be part 
of the standard includes. If it was added to the program itself, it 
would have to be written so it is flexible enough to be used in 
different kinds of scenes.


> > Now, something like an L-system object would be a different matter...it
> > would still be quite flexible but would also parse much faster and
> > probably consume less memory.
> 
> And as much material as is available on L-Systems I am surprised a
> patch hasn't been presented.

As am I. I think the main reason is the parser for the L-System script, 
they would certainly be a nice feature. And even if they were hard to 
control, a few starter objects could be put in the include files.


> And I keep seeing the same tired example. What else can you do with 
> OO that you can't already do in POV-Ray ? How many of the current 
> users will be able to understand a scene example from you using OO if 
> you provided one ? Even other programmers balk at the idea. Shouldn't 
> the non programmer user also worry ?

You can do this in POV-Ray now, true...but it is sloppy and hard to 
read. It is also prone to producing bugs if you modify the scene later.
POV is object oriented now. This would just remove a few limitations on 
it.
And I think that the only reason for a scene example with a hard to 
understand OO portion would be to demonstrate that hard to understand OO 
portion. And really, if you are already using POV, you shouldn't have 
any problem understanding these features.


> Ok, you maintain backward compatibility but how much bloat will it
> add ? Will POV-Ray run faster ?

Current scenes shouldn't parse noticeably slower, and if the parser is 
significantly rewritten in the process of adding these features, they 
might actually parse faster...render speed would not be affected at all.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA66D7.9E1F957C@pacbell.net>, lin### [at] povrayorg 
wrote:

> To me the first example is more intuitive. Where does Move come from ?
> 
> I don't like the idea that I would have to make a macro just to move an
> object. Seems like extra work to me. Point still not conceded.

Who said the macro was required? You could still redeclare and translate 
it if you wanted, you just would have a harder time keeping track of 
things.
Say you have a long string of objects that are linked together. You move 
one, and it affects all the others. You can calculate the positions and 
transformations for all of them(maybe enclosing the whole thing in a 
macro), or you can have each one be manipulated by a macro and only call 
the base macro. A macro and variable would be attached by doing 
something like this:
object {
    #local DistanceMoved = 0;
    #macro Move(Direction)
        translate Direction
        #local DistanceMoved = DistanceMoved + vlength(Direction);
        // or this... :-)
        #local DistanceMoved += vlength(Direction);
    #end
}

To do something like this without OO features, you would have to make a 
special macro and set of variables for each object, separated only by a 
unique name.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38CA6435.A9A33FAA@pacbell.net>, lin### [at] povrayorg
> wrote:
> 
> > Well we have features like sky_sphere, rainbow, background, and
> > fog which are limited in scope but are still included with the
> > program and serve a purpose. Even limited functionality is better
> > than no functionality when you have no idea how to code it yourself.
> 
> I don't see how they compare...clouds can be done with the sky_sphere,
> if that is the type of thing you are talking about. If you are talking
> about actual clouds, instead of a background effect, I don't see how
> this could possibly be done and be easier or faster than media clouds.
> Are you talking about a kind of sky_sphere with a special cloud
> generating algorithm for it's pigment? Then why not just add a new kind
> of pigment and use the current sky_sphere? Less features to learn and
> keywords to memorize...and you would be able to use it with other things.
> 
> Clouds are just something better put in the scene file than in hard to
> change source code. There are even include files that come with the
> program that do clouds...fog, background, rainbow, and sky_sphere would
> also be bad things to hard-code, since they need to be changed
> frequently. Maybe you want something like a "cloud box", which would be
> an automated way of putting a layer of media in the sky?

I think you missed my point. We already HAVE sky_spheres, rainbows and
fog but their usefulness is limited. They are however features of the
program that are used and appreciated. What Gilles was talking about
in terms of clouds is a feature that is present in Terragen that produces
some absolutely awesome clouds. It uses a method unknown to me, that not
only render quickly but are configurable, easy to use, and are absolutely
believable. I would hazard a guess that they are similar to the sky_sphere
feature we have now but with enhancements (Gilles ?).

If you are not familiar with Terragen stop by their web page and look
at the image gallery - http://www.planetside.co.uk/

> > Not everyone who uses POV-Ray has an internet connect nor do they
> > visit these groups. Many find the program on shareware CD's that
> > do not have a collection of the include files that we take for
> > granted. Some of these features like you mentioned can be better
> > handled and optimized internaly. Have you ever tried Gilles tree
> > macro with a recursion level over 7 ? MAN! it takes forever to parse.
> 
> Actually, I haven't. But I have tried my own tree macros with recursions
> of over 20. And some of my particle simulations have had extremely long
> parse times.
> Why would it have to be included in the program itself? It could be part
> of the standard includes. If it was added to the program itself, it
> would have to be written so it is flexible enough to be used in
> different kinds of scenes.

  Lets say for a moment that some brilliant programmer has the patience
and drive to write a patch that would add a tree object to the program.
Even if the tree patch couldn't do every tree on earth do you really
think that there is not one person out there using POV-Ray that wouldn't
try using this feature at least once ?

 Gilles tree macro only requires that you make a handful of declarations
and fill in the space for initializing the macro itself. The diversity
available with the macro itself is incredible because it was well thought
out and is easy to use. Why could something like this not be included with
the program ? Why would it be undesirable to have a feature like this that
ran faster internally instead of waiting 20 minutes for the code to parse ?

I understand the desire to do it all yourself in native Pov but do you
understand the desire of some who don't want to hassle with it or simply
are not intellectually capable of doing so ?


 I see four maybe five major areas that POV-Ray is weak in that still
need to be improved upon.

An easy method of mechanically roughening/smoothing a surface - displacement
mapping and subdivision.

Clouds and Smoke - yeah we have seen media do it but it is far from
easy, it is not intuitive, and the render time is still expensive
even with Nathan's enhancements. From what I have seen so far only
the *expert* users of the program come close to achieving believable
results with media while everyone else is still going "huh ?".

Irregular shapes creation - Isosurfaces sure - if you are some kind
of mathematical genius.

Some form of organic modelling system - a tree generator, L-Systems,
whatever.

While I am drifting off topic a bit here there is a reason for it.
You say add better language abilities to the program to achieve these
things. I say improve the program by adding these things to it. I
think this is the point that Gilles was trying to make. This is the
vital difference between a programmer mentality and a user mentality.
Why should I have to learn even more POV-Ray scripting options like
OO and for() loops when the program is supposed to be doing the
thinking for me ? The program is supposed to speed up scene development
and image creation not acting as a programmers development environment.
Let us not lose sight of this.

> > And I keep seeing the same tired example. What else can you do with
> > OO that you can't already do in POV-Ray ? How many of the current
> > users will be able to understand a scene example from you using OO if
> > you provided one ? Even other programmers balk at the idea. Shouldn't
> > the non programmer user also worry ?
> 
> You can do this in POV-Ray now, true...but it is sloppy and hard to
> read. It is also prone to producing bugs if you modify the scene later.
> POV is object oriented now. This would just remove a few limitations on
> it.
> And I think that the only reason for a scene example with a hard to
> understand OO portion would be to demonstrate that hard to understand OO
> portion. And really, if you are already using POV, you shouldn't have
> any problem understanding these features.

  This will remain to be seen. I do hope that once a patch is written
for OO that it is given a fair treatment in the patch community before
it is added to the official version. I am going to maintain a "wait and
see" attitude until then.


-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken wrote:

> You say add better language abilities to the program to achieve these
> things. I say improve the program by adding these things to it. I
> think this is the point that Gilles was trying to make. This is the
> vital difference between a programmer mentality and a user mentality.
> Why should I have to learn even more POV-Ray scripting options like
> OO and for() loops when the program is supposed to be doing the
> thinking for me ? The program is supposed to speed up scene development
> and image creation not acting as a programmers development environment.
> Let us not lose sight of this.

Very good points, Ken.

If you look at Terragen or Vue d'Esprit, very realistic cloud effects can be
done
very fast and very effectively. I don't have a clue about how it's done but we
know it's possible. Actually these were just examples of what, as a pov user,
I would *really* need, because my goal is to make images, and not to code them.
Commercial programmes offer many bells and whistles of this kind because
they have a user base that requires them (and pays for them). In fact, all
of the features I quoted are taken for granted in one or another commercial
application, in the programme itself or in its plugins.
You can have a look at the vegetation engine in Vue d'Esprit for another
example.
http://www.e-onsoftware.com/Gallery/Day.php3?Index=0

Remember the AWESOME ROLLEX story ? The ocean pic was made with a plugin
for Max/Maya/Lightwave/Softimage. People got very excited because
it looked so great in pov, but, as far as I know, nobody ever got close
to that quality in pov.
You can see the ocean original here http://www.areteis.com/gallery/otw.jpg

I'm not asking for anything, just want to make clear that there are lots of
areas to
investigate for people with programming talent, and many of them have to
do with pov ability to render images. And this, for me would be much more
important that any syntax streamlining.

Most of us can live with a=a+1 instead of a +=1, but sorely miss being able
to render a good sky, or a good ocean, or a good fur,  at an acceptable
coding/computing price.

I'll add something : many aspects of programming that may appear sloppy to
the professional programmer are often very much appreciated by non-programmers.
I don't like to declare variables. I don't like variables having "types". I
don't like
shortcut operators. I may prefer verbose and redundant statements to clean,
streamlined ones if the latter seem obfuscated to me. And generally speaking I
tend to get lost with complex, abstract constructs which may be heaven-sent for
people with powerful brains, but not for me. Why is that ? Because, as a user,
I like to restrict my coding to its scene-oriented questions. I don't want the
code
to be a burden (for instance by multiplying the abstraction levels). I don't
want
obscure messages that will tell me that something was not instanciated (uh?)
or that some class wasn't defined. Even a "type mismatch" error should be
superfluous.
In database management, we know for instance that there is a trade-off between
the conceptual purity of the database design and its usability. We
can get carried away by designing databases that are both formally perfect and
unusable. As I previously said, I think that the very (relative) clumsiness
of the pov syntax is also one reason for its present success in the
non-programming world.

G.



>
> > > And I keep seeing the same tired example. What else can you do with
> > > OO that you can't already do in POV-Ray ? How many of the current
> > > users will be able to understand a scene example from you using OO if
> > > you provided one ? Even other programmers balk at the idea. Shouldn't
> > > the non programmer user also worry ?
> >
> > You can do this in POV-Ray now, true...but it is sloppy and hard to
> > read. It is also prone to producing bugs if you modify the scene later.
> > POV is object oriented now. This would just remove a few limitations on
> > it.
> > And I think that the only reason for a scene example with a hard to
> > understand OO portion would be to demonstrate that hard to understand OO
> > portion. And really, if you are already using POV, you shouldn't have
> > any problem understanding these features.
>
>   This will remain to be seen. I do hope that once a patch is written
> for OO that it is given a fair treatment in the patch community before
> it is added to the official version. I am going to maintain a "wait and
> see" attitude until then.
>
> --
> Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Chris Huff wrote:

> Say you have a long string of objects that are linked together. You move
> one, and it affects all the others.

<snip>

> To do something like this without OO features, you would have to make a
> special macro and set of variables for each object, separated only by a
> unique name.

Or to do this you can use a graphical modelling environment which is much
better suited to this task than a text based scripting language is for example
Moray with it's new animation plugin and it's IK abilities.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CA8F7A.D6CC37D6@pacbell.net>, lin### [at] povrayorg 
wrote:

> > To do something like this without OO features, you would have to make a
> > special macro and set of variables for each object, separated only by a
> > unique name.
> 
> Or to do this you can use a graphical modelling environment which is 
> much better suited to this task than a text based scripting language 
> is for example Moray with it's new animation plugin and it's IK 
> abilities.

Ken, Ken, Ken. You should know better than that. I will just skip the 
comment about using a modeller instead of hand coding and get to the 
point: this was just an *example*. Even if your solution was valid for 
all platforms and all cases objects need to be linked together, this 
isn't the only reason for object oriented features. If it was, I would 
be suggesting a way to link objects together instead.(which may actually 
not be such a bad idea...)
Also, wouldn't a tree generator also be better implemented in a 
graphical modelling environment? :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:

> Ken, Ken, Ken. You should know better than that.

The Devil made me do it...

> Also, wouldn't a tree generator also be better implemented in a
> graphical modelling environment? :-)

Absolutely not. I have no patience for positioning 30,000 objects
by hand in a GUI modelling program.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CA8CFB.D837BDD2@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> wrote:

> If you look at Terragen or Vue d'Esprit, very realistic cloud effects 
> can be done very fast and very effectively. I don't have a clue about 
> how it's done but we know it's possible. Actually these were just 
> examples of what, as a pov user, I would *really* need, because my 
> goal is to make images, and not to code them.
> Commercial programmes offer many bells and whistles of this kind 
> because they have a user base that requires them (and pays for them). 
> In fact, all of the features I quoted are taken for granted in one or 
> another commercial application, in the programme itself or in its 
> plugins.
> You can have a look at the vegetation engine in Vue d'Esprit for another
> example.
> http://www.e-onsoftware.com/Gallery/Day.php3?Index=0

Actually, the first thing I noticed was the stone texture...that is 
quite nice. :-)
Are Terragen and Vue d'Esprit raytracers? Some effects like clouds and 
complex plants are easier to implement and faster to render in 
scanline-type renderers, they may not be applicable to POV-Ray.
Would you be satasfied with a special "cloud pigment" that you can apply 
to a sky_sphere?


> Remember the AWESOME ROLLEX story ? The ocean pic was made with a plugin
> for Max/Maya/Lightwave/Softimage. People got very excited because
> it looked so great in pov, but, as far as I know, nobody ever got close
> to that quality in pov.
> You can see the ocean original here 
> http://www.areteis.com/gallery/otw.jpg

I remember that, although as I recall, it was spelled "AWSOME ROLLEX". 
:-)
I have seen better water in POV, although I can't remember exactly 
where... This looks "frozen" to me, and kind of like plastic, probably 
because there aren't any clouds to reflect and the highlights seem 
constant all the way to the horizon. A simple isosurface using a 
wrinkles pigment scaled larger in one direction for displacement(or a 
*huge* resolution height field) would work well.


> I'm not asking for anything, just want to make clear that there are 
> lots of areas to investigate for people with programming talent, and 
> many of them have to do with pov ability to render images. And this, 
> for me would be much more important that any syntax streamlining.
> Most of us can live with a=a+1 instead of a +=1, but sorely miss 
> being able to render a good sky, or a good ocean, or a good fur,  at 
> an acceptable coding/computing price.

If you have a few features to request, then go ahead and request them!
One of the reasons features are not added is that nobody says they want 
them. You way there are other things you would consider more important 
than syntax streamlining, what are they? You mention clouds, oceans, 
fur, etc but didn't really give much information on what you want to see.
(You want clouds? What kind? A texture type, a background effect, an 
object type...?
You want oceans? What kind? A texture type, a height-field feature, a 
separate object...? Fur is pretty obvious, the main reason it hasn't 
been done is probably the difficulty of implementing it in a raytracer.)

With things like angle-dependant reflection and isosurfaces, good oceans 
are possible. Good skies are possible now, and quite fast if you use 
pigments to do them. Fur is possible using media, although a bit 
difficult. 
Do you want some kind of starter scenes with the basic code in place? I 
really don't think an "ocean" primitive is a good idea...but if you can 
give a good reason for it's existance and some example syntax someone 
might code one.


> I'll add something : many aspects of programming that may appear 
> sloppy to the professional programmer are often very much appreciated 
> by non-programmers.

Like what? I really don't know what you mean...
Do you want a goto statement or something?


> I don't like to declare variables. I don't like variables having "types". 
> I don't like shortcut operators. I may prefer verbose and redundant 
> statements to clean, streamlined ones if the latter seem obfuscated 
> to me. And generally speaking I tend to get lost with complex, 
> abstract constructs which may be heaven-sent for people with powerful 
> brains, but not for me. Why is that ? Because, as a user, I like to 
> restrict my coding to its scene-oriented questions. I don't want the 
> code to be a burden (for instance by multiplying the abstraction 
> levels). I don't want obscure messages that will tell me that 
> something was not instanciated (uh?) or that some class wasn't 
> defined. Even a "type mismatch" error should be superfluous.

I have never seen either of those errors with POV, and haven't seen any 
suggestions which would cause them except for the requested addition of 
types. And even then, the suggestion was for a way to override the 
normal typing system, you could continue to write the way you do and 
never see any type-checking messages.
Not even more object oriented features would require adding types. It's 
just attaching variables and macros to shapes.


> In database management, we know for instance that there is a 
> trade-off between the conceptual purity of the database design and 
> its usability. We can get carried away by designing databases that 
> are both formally perfect and unusable. As I previously said, I think 
> that the very (relative) clumsiness of the pov syntax is also one 
> reason for its present success in the non-programming world.

I am not so sure about this...many of these things are not being 
introduced to add "conceptual purity", but to make things easier on 
people writing complex includes.


There is another alternative which is being discussed in 
povray.off-topic which I am surprised hasn't been mentioned here: making 
a new language, starting from the basics and ensuring a clean design, 
probably similar to C(I suggested POV-CSDL, for POV C-like Scene 
Description Language), and using a translator program to convert files 
written in it to POV-Script files to be rendered. Programmer type people 
could make their includes in this environment and distribute both the 
POV-CSDL and the POV-Script files. That way, non programmers wouldn't be 
complaining about features being added that they can't/won't use, and 
programmers would have a more powerful and flexible environment for 
scene and include development. I have actually considered writing a 
program like this, the main thing stopping me is that I know virtually 
nothing about writing parsers. :-(

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Gilles Tran wrote:
> 
> Johannes Hubert wrote:
> 
> > And the "non-programmers" would get a language for which the manual
> > would actually be *thinner* than it is now, a language that is more
> > approachable and easier to learn (because frankly I think, that many of
> > you here who advocate POV-Script as an easy language to learn have lost
> > perspective a bit, since you alreay *know* POV-Script: sure, newbies
> > *can* learn POV-Script, but the language is far from being easy to learn
> > and could be much more so in my opinion).
> 
> It's obvious that there's a general consensus about the fact that the pov
> syntax,
> having evolved from a simple scene description language to a "programming"
> language has now problems of its own. And you're right, it was never easy to
> learn, and I know of people who downloaded pov and were scared right away.
> However, I think that the original construct "primitive transform texture",
> written in such a way, is very intuitive. I know of teachers who use it at
> school
> to teach maths to kids. I guess it's intuitive because it's close to actual
> language :
> "the sphere is big and blue".
> 
> My own ventures in OO programming and other advanced programming indicate
> that, though there's no discussion on the necessity of it when it comes to
> programming efficiency, it also requires a *much higher* level of abstract
> thinking.
> This may be natural to full-time programmers, but for many people
> (including me) these ways of thinking are extraordinary hard, if not
> impossible, to grasp. Many of the concepts discussed in this thread
> (or in the programmers' wish lists) are simply out of my intellectual reach.

Time to add my own two cents, I suppose.

The POV scene language is a bit of an engineering nightmare, since its
usefulness is more or less inversely proportional to its ease of use.
(As is usually the case with such things.) Fortunately for us, you're
not required to access *all* of the complexity to use the language; you
can define very simple scenes very easily without having to mess with
any of that "weird programming stuff".

I don't think we need to add a zillion ways of doing the same thing;
this is almost certainly the idea of some well-meaning but foolish
programmer who thinks that POV should look more like a "real language"..
as if he has the authority to decide what that is. What we DO need is
some polish. This is a raytracer meant for end users, not a
correspondence course in computer science. Either the package should
include a comprehensive set of tutorials (particularly on things like
isosurfaces, realistic skies and water, media, lighting techniques and
complicated crap like that), or it should be provided as a separate download.

And it would be nice if POV-Ray had some sort of plugin architecture so
that if someone wanted to hard-code a tree-generator or fur-generator to
save parsing time, rendering time, and/or memory, they could do it.
Patches could use the same architecture, since they would basically work
the same way (extension to the parser and some custom code to do the
actual work). It wouldn't prevent you from using #includes, and since no
casual user is going to be able to figure out how those things work
anyway, if it's that important to be able to modify the plugins, the
creators could always provide source code.

Finally, it's my opinion that the POV language is *already* OO. I would
love for anyone who disagrees to explain to me how

object
	{
	dimensions { foo }
	transformation { foo }
	texture { pigment { foo } }
	texture { pigment { foo } normal { foo } }
	whatever { foo }
	}

...is in *any* way fundamentally different from something like

object.dimensions = foo
object.transformation = foo
object.texture[0].pigment = foo
object.texture[1].pigment = foo
object.texture[1].normal = foo
object.whatever = foo

-- 
Xplo Eristotle
http://start.at/xplosion/

Post a reply to this message

In article <38CAA340.E350695A@pacbell.net>, lin### [at] povrayorg 
wrote:

> The Devil made me do it...

Uh-oh, you had better start running your self diagnostics and virus 
detection routines more often.


> Absolutely not. I have no patience for positioning 30,000 objects
> by hand in a GUI modelling program.

I said a tree *generator*...I didn't say anything about hand placing all 
the objects.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

True, but what if you had to type:

ediBatchFile->Text = ediBatchFile->Text + "There is more..";

wouldn't you like to have to type only:

ediBatchFile->Text += "There is more..";

you even don't have to copy & paste, then.

--
Regards,
Sander


Matt Giwer <jul### [at] ijnet> schreef in berichtnieuws
38C994D0.C4A06309@ij.net...
> OK. Any what is the value beyond saving a few keystrokes?
>
> The time required for extra keystrokes is the last thing that
> worries even the best of programmers.

Post a reply to this message

Chris Huff wrote:

> If you have a few features to request, then go ahead and request them!
> One of the reasons features are not added is that nobody says they want
> them. You way there are other things you would consider more important
> than syntax streamlining, what are they? You mention clouds, oceans,
> fur, etc but didn't really give much information on what you want to see.

Before we had many people doing patches, the common idea was to not
bother the pov-team with feature requests (and the pov-team is very shy,
for good reasons) and, in fact, most of what have appeared in the development
of pov were very logical improvements. The other problem is that
non-programmers can't tell what's possible from what isn't and may be afraid
to look silly.

Want some ideas ? I've got a trunk full of them...

Clouds : we don't have presently a good system to make them.
Apart the old bozo/granite method (which works
very well sometimes), the 2 current methods (media and multiple planes)
share the same problems : they take ages (forget about using them in large
resolution pictures), may look grainy and they're basically scene-dependent.
These methods have led to impressive pictures but they're very difficult to set
up.
However, I'm pretty sure that something like a cloud
pattern with its specialized parameters would do (think of the brick pigment).
It wouldn't need to interact with the environment (only with the light position

and color) and we wouldn't be able to fly through.
But it would be enough for all the scenes that needs a realistic sky background

that doesn't look too much painted over.
Of course, it would come with cloud structures (cumulus, cirrus etc.),
variable fluffiness, and maps for the most common cloud effects
(white bright clouds, storm clouds, sunset clouds,  silver lining etc), and it
could be animated. Several cloud layers could be added.

Ocean and water : some on-the-fly height-field generation would do, provided it

gives the proper aspect of a 3D ocean surface. Add a foam and spray ability
too...
It could be animated.

Tree generation : if someone has a PhD about this, it should be possible
to create a general purpose tree growth model (Cf PlantStudio for a general
purpose
plant model) whose parameters could be stored in text files (and provided
with the general pov distribution). There would be a tree fonction that would
call
the model parameters and be fed some variables :
tree("oak",age,season,wind, trunktexture,leaftexture, randomvalue)

Look at AMAP for instance
http://www.cirad.fr/produits/amap/genesis/genesisen.shtml
Pov would then generate a mesh, but like in Nathan Kopp's implementation
of radiosity and photon map, you could save the optimized mesh between
sessions.

Other stuff :
- a specialized pattern for dirty walls and concrete. There's no way to
properly
add marks and splotches in a way that doesn't seem regular (unless you use
image_maps, or add layers and layers and layers)
- a way to project a pigment on a particular spot of an object (some sort of
decal ;
to do this with pov now it's necessary to cut out the part, apply the pigment
and reinsert the part)
- a improved brick pattern, that would allow for not-so-square bricks not
fouled up by turbulence
- a snake scales pattern (used directly, or through uv mapping)
- a cracks pattern (there's one in Leveller)

Hmmm. I guess that's enough wishful thinking for tonight !

G.

Post a reply to this message

>Of course, it would come with cloud structures (cumulus, cirrus etc.),
>variable fluffiness, and maps for the most common cloud effects


Variable fluffiness, that sounds so cool. =)

Ah, I'm to tired...


--ll

Post a reply to this message

In article <38CAC206.1E895C99@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> wrote:

> Before we had many people doing patches, the common idea was to not 
> bother the pov-team with feature requests (and the pov-team is very 
> shy, for good reasons) and, in fact, most of what have appeared in 
> the development of pov were very logical improvements. The other 
> problem is that non-programmers can't tell what's possible from what 
> isn't and may be afraid to look silly.

That is one of the things the TAG team is for, to get feature requests, 
filter out the outrageous, useless, or impossible ones(like, um, a 
graphical modelling interface as an example.), and let the POV-Team know 
this is a desired feature.


> Want some ideas ? I've got a trunk full of them...

Good, maybe some will get on my to-do list. :-)


> Clouds : we don't have presently a good system to make them.
> Apart the old bozo/granite method (which works very well sometimes), 

Actually, I kind of like wrinkles for clouds.

> the 2 current methods (media and multiple planes) share the same 
> problems : they take ages (forget about using them in large 
> resolution pictures), may look grainy and they're basically 
> scene-dependent. These methods have led to impressive pictures but 
> they're very difficult to set up.

Using media with method 3 sampling gets rid of the graininess and is 
faster(it is much like the old atmosphere or halo), and any method which 
does 3D clouds is going to be slow. You aren't going to get much faster 
than media method 3.


> However, I'm pretty sure that something like a cloud pattern with its 
> specialized parameters would do (think of the brick pigment).
> It wouldn't need to interact with the environment (only with the 
> light position and color) and we wouldn't be able to fly through. But 
> it would be enough for all the scenes that needs a realistic sky 
> background that doesn't look too much painted over. Of course, it 
> would come with cloud structures (cumulus, cirrus etc.), variable 
> fluffiness, and maps for the most common cloud effects (white bright 
> clouds, storm clouds, sunset clouds,  silver lining etc), and it 
> could be animated. Several cloud layers could be added.

Maybe just a general "sky" feature, which would replace(or enclose?) the 
current sky_sphere and rainbow.(I consider "background" to be a separate 
feature from these) You could add cloud layers, and adjust density, 
type, etc. Maybe also stars, nebulae, aurora's, etc. There would also be 
a "sun_light", which wouldn't illuminate the scene but would affect the 
clouds. This would greatly simplify that part of the feature.


> Ocean and water : some on-the-fly height-field generation would do, 
> provided it gives the proper aspect of a 3D ocean surface. Add a foam 
> and spray ability too...
> It could be animated.

Height fields using the pattern feature in MegaPOV can be animated. By 
"on-the-fly", do you mean parse-time or render-time? The "pattern" 
feature is parse-time, isosurfaces can be used to get render-time height 
fields. As for the foam and spray...I have been wondering what a 
particle system syntax could be like.


> Tree generation : if someone has a PhD about this, it should be 
> possible to create a general purpose tree growth model (Cf 
> PlantStudio for a general purpose plant model) whose parameters could 
> be stored in text files (and provided with the general pov 
> distribution). There would be a tree fonction that would call the 
> model parameters and be fed some variables :
> tree("oak",age,season,wind, trunktexture,leaftexture, randomvalue)
> 
> Look at AMAP for instance
> http://www.cirad.fr/produits/amap/genesis/genesisen.shtml
> Pov would then generate a mesh, but like in Nathan Kopp's implementation
> of radiosity and photon map, you could save the optimized mesh between
> sessions.

"the result of tens of years of research in plant growth simulation."?
I think a growth simulating algorithm like this would be a little 
excessive. And what about different leaf types? And fruit/flowers/seed 
pods/willow branches?
The usual recursive growth algorithm should be enough, if you modify it 
so you can specify "avoidance regions" occupied by an object which the 
plant would grow around. Something like this:
plant {
    base_position VECTOR
    start_radius FLOAT
    recurse_depth INTEGER
    max_branches INTEGER // maximum number of times to branch per "node"
    branch_probability FLOAT
        //the probability the algorithm will branch at each "node"
    max_branch_angle FLOAT
    radius_scale FLOAT // the factor the radius decreases by each level
    direction VECTOR // specifies the direction growth starts in
    gravity VECTOR // causes the plant to grow against or with gravity
    gravity_change VECTOR
        // allows the gravity effect to change, so for example,
        // tips of branches grow upwards more than main branches
    random_seed SEED // allows you to get a specific plant
    leaf_object {...}
    trunk_texture {...}
    avoidance_object {...}
        // The plant will "grow" to avoid penetrating this object.
        // Use union here to avoid multiple objects.
}
Of course, there would be default values for all of these...


> Other stuff :
> - a specialized pattern for dirty walls and concrete. There's no way 
> to properly add marks and splotches in a way that doesn't seem 
> regular (unless you use image_maps, or add layers and layers and 
> layers)

My blob pattern could be useful for this, it is included in MegaPOV. You 
could hand place the splotches or make a macro or just a loop to create 
them automatically.


> - a way to project a pigment on a particular spot of an object (some 
> sort of decal ; to do this with pov now it's necessary to cut out the 
> part, apply the pigment and reinsert the part)

You could use the object pattern to confine the pattern to a specific 
place. The object pattern is included in MegaPOV. You might also be able 
to do what you want with the blob pattern.


> - a improved brick pattern, that would allow for not-so-square bricks not
> fouled up by turbulence

I don't like the brick pattern at all...I just use real bricks. :-)


> - a snake scales pattern (used directly, or through uv mapping)

Don't forget fish scales. I think this is possible with a combination of 
texture maps and repeat warp, or with function patterns, but a 
specialized pattern might be useful.


> - a cracks pattern (there's one in Leveller)

Hmm, have you tried agate? Or kinds of turbulence?
Or are you looking for a branching type of crack, that looks sort of 
like lightning? That could be done with the blob pattern and a macro or 
two.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

David Fontaine wrote:
> 
> Tor Olav Kristensen wrote:
> 
> > How about making the editor do the re-typing for the lazy ones?
> 
> 1) What if you want to change it later? You have to do it twice.
> 2) People can use whichever syntax they prefer.
> 3) If more and more fancy features are added to the editor it will consume more
> resources.
>    a) I'm not saying I don't like column-select and all that; very useful!
>    b) I don't like it when the computer modifies my work.
> 4) :-p

People can press whatever keys they like.

So if you preferred not to hit that function key, then the computer
wouldn't modify your work...

;-b

Tor Olav

mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message

Hmmm...Your for loops looks like c-syntax to me.

Would you suggest that one allowed similar things 
to be allowed in a for-loop declaration in the 
POV-language that one allows in C?

E.g. initialize several variables, call other 
functions/macros within the declaration itself etc. ?

If not, then I my opinion is that one should 
choose another syntax for the for-loop that doesn't 
make the users believe that the same rules applies 
as in C.

And: Wouldn't it be better that the control 
variable(s) in a for-loop is local to the for-loop?

Tor Olav

mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html


Chris Huff wrote:
> 
> In article <38C816BE.35E35A1C@hotmail.com>, Tor Olav Kristensen
> <tor### [at] hotmailcom> wrote:
> 
> > But what if the loop control variable is a vector that is shared
> > between several nested loops? (See my example macro below.)
> >
> > Would this be possible with nested for-loops?
> 
> It would be possible, but not necessarily the best way to do it.
> Something like this:
> 
> #macro ObjectSplit(Thing, Point1, Point2, nnv)
> // Cuts an object into several "box"-parts
> // Result is returned in an array of such parts
> 
>   //#local nnv = <nx, ny, nz>;
>   #local ThingArray = array[nnv.x][nnv.y][nnv.z]
>   #local dPoint = (Point2 - Point1)/nnv;
> 
>   #for(Cntv = <0,0,0>; Cntv.z < nnv.z; Cntv.z += 1)
>     #for(Cntv.y = 0; Cntv.y < nnv.y; Cntv.y += 1)
>       #for(Cntv.x = 0; Cntv.x < nnv.x; Cntv.x += 1)
>         #local ThingArray[Cntv.x][Cntv.y][Cntv.z] =
>           intersection {
>             object { Thing }
>             box { Point1 + dPoint*Cntv, Point1 + dPoint*(Cntv+Unitv) }
>           }
>       #end // for
>     #end // for
>   #end // for
> 
>   ThingArray
> 
> #end // macro ObjectSplit
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

Post a reply to this message

>I particularly like the ideas posted above of adding the C-style FOR loops
and
>such.  I would find these particularly helpful as I am just getting my feet
wet
>with C programming and I could work on my C coding with POV.

I mentioned how great for-loops would be about a year ago. My idea was
rejected at the time. I personally prefer writing

#for(C,C<N,C++)
[block]
#end

to writing

#declare C = 0;
#while (C<N)
[block]
#declare C = C + 1;
#end

And I think that it would help a lot of code to look cleaner. What the heck,
why not make it so you write for-loops, but POV reads it in like a while
loop for its own internal purposes?

Post a reply to this message

>Like what? I really don't know what you mean...
>Do you want a goto statement or something?


<cringe> <shudder>

Post a reply to this message

In article <38C### [at] unforgettablecom>, 
inq### [at] unforgettablecom wrote:

> Either the package should include a comprehensive set of tutorials 
> (particularly on things like isosurfaces, realistic skies and water, 
> media, lighting techniques and complicated crap like that), or it 
> should be provided as a separate download.

Remember though, that POV-Ray is created by people in their free time. I 
wouldn't want them to delay the releases so documentation like that 
could be written. Maybe a basic manual which describes the features of 
the scene language, and which would be included with and updated for 
each release, and separate tutorials for skies, water, isosurfaces, and 
other "complicated crap", which could be released one by one after the 
main release. :-)


> And it would be nice if POV-Ray had some sort of plugin architecture so
> that if someone wanted to hard-code a tree-generator or fur-generator to
> save parsing time, rendering time, and/or memory, they could do it.
> Patches could use the same architecture, since they would basically work
> the same way (extension to the parser and some custom code to do the
> actual work). It wouldn't prevent you from using #includes, and since no
> casual user is going to be able to figure out how those things work
> anyway, if it's that important to be able to modify the plugins, the
> creators could always provide source code.

This is a nice idea, but would be nearly impossible to implement. An 
include/scene file is the closest thing to that which wouldn't require a 
large amount of effort to do. Remember that the solution would have to 
be cross-platform...a kind of "virtual machine" like Java might work, 
but would probably be a lot of work to write(although it could be much 
faster than ordinary script).

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CAF26F.AF099263@hotmail.com>, Tor Olav Kristensen 
<tor### [at] onlineno> wrote:

> Hmmm...Your for loops looks like c-syntax to me.

Yes.


> Would you suggest that one allowed similar things 
> to be allowed in a for-loop declaration in the 
> POV-language that one allows in C?
> 
> E.g. initialize several variables, call other 
> functions/macros within the declaration itself etc. ?
> 
> If not, then I my opinion is that one should 
> choose another syntax for the for-loop that doesn't 
> make the users believe that the same rules applies 
> as in C.

I don't see any reason not to support the full C syntax(other than 
possible difficulty in supporting some things). The only differences 
would be the # in front of the keyword and a #end instead of a {} block.


> And: Wouldn't it be better that the control 
> variable(s) in a for-loop is local to the for-loop?

Hmm, I'm not sure here...I think it would be a good idea when considered 
alone, but no other variables are local to a loop or conditional. As far 
as I know, #local only affects include files and macros. Having a single 
exception made for the #for(;;) loop might not be a good idea.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38cb0321@news.povray.org>, "TonyB" 
<ben### [at] panamac-comnet> wrote:

> >Like what? I really don't know what you mean...
> >Do you want a goto statement or something?
> 
> 
> <cringe> <shudder>

:-)
Don't worry, I am definitely not suggesting that a #goto feature be 
added.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Ken wrote:

> Strangely the GOTO command is one of the few in Qbasic I ever understood
> how to use successfully... Imagine that !

Well, under Qbasic, the use of GOTO is probably much more needed.

Switch to something like Java, or Smalltalk, or lisp...

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Chris Huff wrote in message ...
>I still can't remember off hand whether no_shadow or shadowless is used
>for an object...the thinking in 3D was actually the easiest part for me.


I fixed that one in my personal version of POV -- either one can be used ;-)

Mark

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote...
>
>There is another alternative which is being discussed in 
>povray.off-topic which I am surprised hasn't been mentioned here: making 
>a new language, starting from the basics and ensuring a clean design, 
>probably similar to C(I suggested POV-CSDL, for POV C-like Scene 
>Description Language), and using a translator program to convert files 
>written in it to POV-Script files to be rendered. Programmer type people 
>

I was thinking about seperating the parser and the renderer, thus 
allowing multiple parsers, write you own parser using your own 
favourite programming paradigm. It could allow the ability to save 
a parsed script, so you could parse one day and render another, or pass 
the parsed file to someone else. Parse on one architecture, Render on 
another. Distributed rendering of animations by passing the parsed files 
of different times to different CPU's in a rendering farm.

Dave
-- 
Posted By NewsBe 1.6.3 Alpha
http://www.vargol.freeserve.co.uk/newsbe/ 
* I need a drink

Post a reply to this message

Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
: From the viewpoint of a computer scientist (I'm one) this is a not a
: syntactically correct defiend for-loop. The variable of a for-loop
: belongs to the for-command and should be never _changable_ by the user. 

  Is there some reason to prevent the user from changing the loop index?
Why should flexibility of the language be delimited?

  As with all features: You don't have to use it if you don't want to. The
fact that a feature exists doesn't mean you have to use it.

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

Matt Giwer <jul### [at] ijnet> wrote:
: 	Introducing additional syntaxes raises more problems than it
: solves.

  I don't think so.
  A more compact and clearer syntax makes the code more readable and minimizes
the possibility of errors.
  For example, suppose you have this:

#declare XLoopIndex1 = 0;
#while(XLoopIndex1 < 100)
  ...
  (30 lines of code)
  ...
  #declare XLoopindex1 = nextValue();
#end

  When one reads the code he will most probably not remember the name of
the loop index after reading the 30 lines of code and the typing mistake
will most probably pass unnoticed. Povray will not issue any error since
there's no syntax nor semantic error. However, the parsing will perform an
endless loop.

  Compare it to this:

#for ( XLoopIndex1 = 0; XLoopIndex1 < 100; XLoopindex1 = nextValue )
  ...
  (30 lines of code)
  ...
#end

  Now since all the commands related to the loop index are at the same line,
noticing the typing mistake is more probable.
  Also understanding the functionality of the loop is much easier to see now,
since you don't have to search for the end of the loop to see how does the
loop index change.

  Also this new syntax would be very handy sometimes:

#do
  ...
#until(whatever)

  There really are times, where you want to execute the body of the loop at
least once before the ending condition is tested (for example the condition
is calculated in the body of the loop).
  With the current #while-loop you would have to calculate the condition
in two places: First before the loop, and then inside the loop. Copying the
same code to several places is not a good thing.

  In a similar way the +=, -=, etc. operators will allow to avoid copying of
code to several places (specially if the variable to modify is a very long
statement).

: 	Next, complex conditional if then else statements.

  What's this?

: Can GOTO be far behind?

  I don't think that goto will be needed. I do think that #break and #continue
statements inside a loop would be handy.

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

Ken wrote:
> 
> Greetings,
> 
>   As we all know the language used by POV-Ray is not only easy to use
> but offers a lot of flexibility. There are often many ways to describe
> an object or attribute of an object because of the "looseness" of
> it's language.
> 
>  Now many in the past have argued that it is too primitive for thier
> needs and suggest that it become more of an official programming
> language. They also suggest it should become more object oriented
> or stricter rules should be applied to the language from what it is
> now. Some say the syntax is too loose for all practical purposes.
> Some even suggest it should move to a binary format that needs to
> be compiled before being parsed (heaven forbid).
> 
>  I say the one thing that attracted me to POV-Ray was the fact that
> it's text based input was both easy to learn, was intuitive from the
> beginning, and I never had to learn a programmers language to use
> the program. I like the way that you can describe something in several
> ways to achieve the same results. In my opinion this loose and very
> flexible language makes it a very powerful program to use.
> 
> Would you have difficulty re-learning POV-Ray if it's language format
> changed ?
> Would you resent it or maybe even quit using the program completely ?

Ken, if I had to re-learn the language, then it would probably be a
fairly large inducement for me to change over to RenderMan. One of
the reasons I like POV-Ray is that it is much easier to use (and
has a quicker turnaround time, if you're using the procedural RI
API) than RenderMan. It's easier to get raytracing effects, too.
However, if everything I know about POV-Ray (and admittedly it isn't
as much as I'd like) were thrown out in the street, then I'd
look around.

Post a reply to this message

You are right.
  However I think there are some places where the use of goto (at least in
C and C++) is more or less reasonable:

- Case 1:

  for(cond1)
    for(cond2)
      while(cond3)
        if(skip) goto end_loops;

end_loops:
  ...

- Case 2:

recalculate_initial_values:
  make_some_calculations;
  for(cond1)
    for(cond2)
      while(cond3)
        if(wrong_values) goto recalculate_initial_values;

- Case 3:

  calculation1;
  if(error) goto end_calculations;
  calculation2;
  if(error) goto end_calculations;
  calculation3;
  if(error) goto end_calculations;
  calculation4;
  if(error) goto end_calculations;

  handle_results;

end_calculations:
  clean_up;


  However, I haven't needed the goto-statement in years, though (and I make
a LOT of C++ code). I can only deduce that usually goto is not needed.

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

Chris Huff <chr### [at] yahoocom> wrote:
: I think union could be used for this if the ability to bind variables 
: and macros to objects was added. I would also like to see a pointer-like 
: feature added(with checking for valid accesses, of course). I think this 
: is what you meant by "reference-type data types". Probably something to 
: think about for POV 4.0...(or 4.1) :-)

  Yes, a pointer type, but a limited one. More like a reference type in Java.

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

In article <38cb9a68@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   A more compact and clearer syntax makes the code more readable and 
> minimizes the possibility of errors.
>   For example, suppose you have this:
> 
> #declare XLoopIndex1 = 0;
> #while(XLoopIndex1 < 100)
>   ...
>   (30 lines of code)
>   ...
>   #declare XLoopindex1 = nextValue();
> #end
> 
>   When one reads the code he will most probably not remember the name of
> the loop index after reading the 30 lines of code and the typing mistake
> will most probably pass unnoticed. Povray will not issue any error since
> there's no syntax nor semantic error. However, the parsing will perform 
> an endless loop.

I suppose this is a good place to bring up another feature I have been 
thinking of. It has bothered me for some time that the same keywords 
that create variables are used to modify them, maybe a #set directive 
should be added. It would act exactly like #declare or #local, except it 
would produce an error if handed an undefined identifier. The keyword 
would always use the most local version of the identifier, of course, 
and local variables would stay local, and #declared variables would act 
as if you used #declare. This also would be backward compatible, 
#declare and #local could still be used to modify variables, it just 
would mean more typing, less clear code, and harder debugging.
That code would be rewritten:
#declare XLoopIndex1 = 0;
#while(XLoopIndex1 < 100)
  ...
  (30 lines of code)
  ...
  #set XLoopindex1 = nextValue();
#end
The #set would produce an error, since XLoopindex1 is not defined. And 
POV would not go into an infinite loop, and you could tell exactly what 
the problem was by looking at the error message.


>   Compare it to this:
> 
> #for ( XLoopIndex1 = 0; XLoopIndex1 < 100; XLoopindex1 = nextValue )
>   ...
>   (30 lines of code)
>   ...
> #end
> 
>   Now since all the commands related to the loop index are at the same 
> line, noticing the typing mistake is more probable.
>   Also understanding the functionality of the loop is much easier to see 
> now, since you don't have to search for the end of the loop to see 
> how does the loop index change.

This alone is a perfectly good reason for adding a #for loop, in my 
opinion.


>   Also this new syntax would be very handy sometimes:
> 
> #do
>   ...
> #until(whatever)
> 
>   There really are times, where you want to execute the body of the loop 
> at least once before the ending condition is tested (for example the 
> condition is calculated in the body of the loop).
>   With the current #while-loop you would have to calculate the condition
> in two places: First before the loop, and then inside the loop. 
> Copying the same code to several places is not a good thing.

I actually have run into this situation a couple times with POV. 
Debugging and extending two separate yet nearly identical chunks of code 
is *not* fun. This loop structure would probably be even easier to add 
then #for(), since it is basically a backwards #while() loop.


> In a similar way the +=, -=, etc. operators will allow to avoid 
> copying of code to several places (specially if the variable to 
> modify is a very long statement).

And maybe -- and ++ operators. I am really not sure about these, they 
don't exactly enhance readability except in highly compact code which 
you are unlikely to attempt in POV(all those # signs and #end's make the 
language too bulky to write highly compact code that is still readable). 
They probably would not be very useful, especially since I don't think 
separate prefix and postfix notations would be possible in the POV 
language(CSDL would be different, of course).


> : Can GOTO be far behind?
> I don't think that goto will be needed. I do think that #break and 
> #continue statements inside a loop would be handy.

There is a #break statement for switch statements, and from the 
description, it doesn't seem like it would be too difficult to extend to 
#if statments and loops. Maybe even macros(have you ever wanted to jump 
out of a macro early?)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Nieminen Juha wrote:

>   You are right.
>   However I think there are some places where the use of goto (at least in
> C and C++) is more or less reasonable:
>
> - Case 1:
>
>   for(cond1)
>     for(cond2)
>       while(cond3)
>         if(skip) goto end_loops;
>
> end_loops:
>   ...
>
> - Case 2:
>
> recalculate_initial_values:
>   make_some_calculations;
>   for(cond1)
>     for(cond2)
>       while(cond3)
>         if(wrong_values) goto recalculate_initial_values;
>
> - Case 3:
>
>   calculation1;
>   if(error) goto end_calculations;
>   calculation2;
>   if(error) goto end_calculations;
>   calculation3;
>   if(error) goto end_calculations;
>   calculation4;
>   if(error) goto end_calculations;
>
>   handle_results;
>
> end_calculations:
>   clean_up;

Of those, only case 3 looks like possibly decent use.  Case 1 and 2 look very
problematic.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

"Jon A. Cruz" wrote:
> 
> Ken wrote:
> 
> > Strangely the GOTO command is one of the few in Qbasic I ever understood
> > how to use successfully... Imagine that !
> 
> Well, under Qbasic, the use of GOTO is probably much more needed.
> 
> Switch to something like Java, or Smalltalk, or lisp...

I would rather fight than switch (I'll be that really dates me).

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:
: There is a #break statement for switch statements, and from the 
: description, it doesn't seem like it would be too difficult to extend to 
: #if statments and loops.

  The #break-statement should NOT jump out of the current #if-statement, but
only out of the current #while-statement (and whatever else loop statement
this enhanced language would have).
  Why?
  Because usually you do this:

#while(whatever)
  ...
  #if(ending_condition)
    #break
  #end
  ...
#end

  It's obvious that if the #break just jumps out of the #if-statement, it
will be mostly useless.

  Unless...
  ... you could specify how many blocks do the #break jump out of. For
example:

#while(cond1)
  #while(cond2)
    #while(cond3)
      #if(cond4)
        #break(3)
      #end
    #end
  #end
  ...
#end

  Supposing that the #break also jumps out of the current #if-statement (and
it's counted as one block), the #break in this code will jump to the line
after the second last #end (ie. the line after the #while(cond2)-block,
marked with "...").

  Of course a simple #break that just jumps out of the current loop would be
mostly enough.

: Maybe even macros(have you ever wanted to jump 
: out of a macro early?)

  I don't know how this could be done. As far as I know, #macro is just
a text-replacement command. The macro call is just replaced with the body
of the macro with the parameters changed to their proper values.
  If you would #break a macro, it would mean that the body will literally be
broken, ie. with missing #end-statements (probably from the #if inside which
the #break was) thus causing problems to the parser.
  If macros were more like function calls, it would be more easier to add
a #return-statement.

  Now, that's an idea:

#function Abs(x)
  #if(x>=0)
    #return x
  #else
    #return -x
  #end
#end

  Hmm... Does this make sense? :)

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

>
> Of those, only case 3 looks like possibly decent use.  Case 1 and 2
look very
> problematic.

Java handles case 1 with a labeled break, doesn't it?

Johannes.

Post a reply to this message

In article <38cbd2ee@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   It's obvious that if the #break just jumps out of the #if-statement, it
> will be mostly useless.
> 
>   Unless...
>   ... you could specify how many blocks do the #break jump out of. For
> example:
...
>   Supposing that the #break also jumps out of the current 
>   #if-statement (and it's counted as one block), the #break in this 
>   code will jump to the line after the second last #end (ie. the line 
>   after the #while(cond2)-block, marked with "...").
> 
>   Of course a simple #break that just jumps out of the current loop would 
> be mostly enough.

Yes, that would be enough for just about anything. I guess I was 
thinking about Java-style multi-level breaks when I mentioned #if 
statements. I don't think they would really be needed in POV, but they 
might be a possibility in CSDL.


> : Maybe even macros(have you ever wanted to jump 
> : out of a macro early?)
> 
>   I don't know how this could be done. As far as I know, #macro is just
> a text-replacement command. The macro call is just replaced with the body
> of the macro with the parameters changed to their proper values.
>   If you would #break a macro, it would mean that the body will literally 
> be broken, ie. with missing #end-statements (probably from the #if 
> inside which the #break was) thus causing problems to the parser.

Wouldn't this problem with missing #end statements also occur with a 
loop? In both cases, there would probably be data in the parser that has 
to be reset.


>   If macros were more like function calls, it would be more easier to add
> a #return-statement.
> 
>   Now, that's an idea:
> 
> #function Abs(x)
>   #if(x>=0)
>     #return x
>   #else
>     #return -x
>   #end
> #end
> 
>   Hmm... Does this make sense? :)

I do like this better, since it works more like a function. But I am 
sure some people would consider it a needless complexity...maybe for 
CSDL though. :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:
: But I am sure some people would consider it a needless complexity...

  You are right. And I wonder why?
  If someone adds some new object, pattern or other feature, everyone praises
it and says "oohh... cool... great!". If someone even suggests adding something
to the syntax, everyone is immediately saying "no, no, no!".

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

Nieminen Juha wrote:
> 
> Chris Huff <chr### [at] yahoocom> wrote:
> : But I am sure some people would consider it a needless complexity...
> 
>   You are right. And I wonder why?
>   If someone adds some new object, pattern or other feature, everyone praises
> it and says "oohh... cool... great!". If someone even suggests adding something
> to the syntax, everyone is immediately saying "no, no, no!".

Like I said elsewhere you have a clear conflict between the Programmer
mentality and the User mentality. Programmers not only want to know how
it works but they also want to be able to force it to work as they want
it to.
  Users just want to be able to use it and don't care how it works. Users
want features that are easy to apply and the program takes care of the
details. Users want a big list of features to choose from without having
to do a big song and dance routine to get it to work.

Programming features are big song and dance routines !

That's how I see it anyway.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Nieminen Juha wrote:
> 
>  Now, that's an idea:
> 
> #function Abs(x)
>   #if(x>=0)
>     #return x
>   #else
>     #return -x
>   #end
> #end
> 
>   Hmm... Does this make sense? :)
> 

I like the idea of functions, but I suspect there would be a lot of
resistance to their introduction.
Why? they look rather like macros and people will get confused.  I'm not
saying people are dumb but a lot of POV users are not programmers and
might not appreciate the difference between macros and functions.

PoD.

Post a reply to this message

Sorry, I'm a coder. I can't do anything about it... ;)

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

Ken wrote:
> 
> Gilles Tran wrote:
> 
> 
> Good point(s). What I also fear is that if the programming language
> is extended in POV-Ray to include OO programming, for () loops, and
> all of the other programming suggestions that have been addressed
> in this thread, is what is going to happen when some non programming
> literate POV-User comes to the news groups seeking help and some
> programmer type gives them an example in the form of these new
> features ? 

How many times have you seen someone ask 
"I have nested #while loops and the inner one doesn't work" ?
This is a problem that would go away with for() loops.

I fully agree that programming features are just a part of POV-Ray, but
who doesn't appreciate the efforts of people like Chris Colefax.  How
much more productive would such #include writers be with better tools?

I also don't think anyone is advocating that the POV-team drop
development of the render engine in favour of the programming interface,
we all want faster, more realistic  renders with more features ;^)

Cheers, PoD.

Post a reply to this message

Spend a minute thinking about the requirements for a POV-Ray L-system
(but make sure you're sitting down first)

PoD.

Post a reply to this message

PoD wrote:
> 
> Spend a minute thinking about the requirements for a POV-Ray L-system
> (but make sure you're sitting down first)
> 
> PoD.

Oops,
That should have been requirements for the syntax of POV-Ray L-system.

PoD.

Post a reply to this message

In article <38CBF353.539F926F@merlin.net.au>, PoD <pod### [at] merlinnetau> 
wrote:

> Spend a minute thinking about the requirements for a POV-Ray L-system
> (but make sure you're sitting down first)

What about them?
I think it would be hard to understand unless you have experience with 
L-System scripts, but the POV syntax would be pretty simple. And a 
couple predefined objects and some macros for controlling l_system 
objects should probably be included...

Writing the actual l_system object would be much more difficult than 
deciding on a syntax.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38CBF353.539F926F@merlin.net.au>, PoD <pod### [at] merlinnetau>
> wrote:
> 
> > Spend a minute thinking about the requirements for a POV-Ray L-system
> > (but make sure you're sitting down first)
> 
> What about them?
> I think it would be hard to understand unless you have experience with
> L-System scripts, but the POV syntax would be pretty simple. And a
> couple predefined objects and some macros for controlling l_system
> objects should probably be included...
> 
> Writing the actual l_system object would be much more difficult than
> deciding on a syntax.
> 

Show me a simple syntax that lets you create a tree with different
textures for trunk, branches, twigs, leaves, fruit, flowers.
And has declarations of objects to use for the above.

I think that if the syntax was invented, then implementing it would be
simple.

PoD.

Post a reply to this message

Tor Olav Kristensen wrote:

> People can press whatever keys they like.
>
> So if you preferred not to hit that function key, then the computer
> wouldn't modify your work...

Okay, but what about 1, 2 and 3a? :-p

--
___     _______________________________________________
 | \     |_          <dav### [at] faricynet> <ICQ 55354965>
 |_/avid |ontaine        http://www.faricy.net/~davidf/

"The only difference between me and a madman is that I'm not mad." -Dali

Post a reply to this message