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