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