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