POV-Ray : Newsgroups : povray.general : The Language of POV-Ray : Re: The Language of POV-Ray Server Time
11 Aug 2024 03:28:57 EDT (-0400)
  Re: The Language of POV-Ray  
From: Chris Huff
Date: 11 Mar 2000 15:23:44
Message: <chrishuff_99-1F8023.15253111032000@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.