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