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