To follow up Stuart, here are some of my thoughts: > FYI I'm currently looking at adding support for creating a 3D shader > cloud > using Nasal, to bypass the need to have XML wrappers etc. I'm hoping > that this can off-load some of the low level quad-tree work you > currently > have to do. (...) > We should discuss exactly what API makes most sense for this.
The following is meant to be a list of thoughts what amount of control I'd consider useful and why, and in addition some explanations of what does what in Local Weather. I) Basic building blocks - texture sheets I assume the basic strategy is to use the rotation in the existing shaders in all cases, i.e. a texture sheet is brought into the scenery which always is rotated to be perpendicular to the view direction. What would be useful to specify then is 1) texture type 2) shader type and 3) a basic size, perhaps also 4) the amount of random size variation and 5) if a random rotation around the view axis can be done. I'm currently composing clouds by mixing different texture types, for instance a Cumulus cloud is a mixture of feathery textures, mature bulky Cumulus textures and dark diffuse bottom textures - other clouds use other mixtures, and by changing the mixture, one can nicely model the impact of the amount of turbulence in the air. That explains why control over texture type is useful. I found that texture sheets can be reused: One texture sheet for instance is used for Altocumuli by using a very light shader and scaling each x,y,z with 0.25. The same sheet produces good stratiform clouds by scaling the z-axis only with 0.4 and using a darker shader to simulate thicker clouds. Thus, it pays off to specify shader (or shader parameters) independent of texture sheet. The basic size is needed to determine how large a cloud should be. To induce more variation, I always thought it would be useful to let textures randomly vary +- 30% in size, and for those textures which have to clear up-down distinction also to allow a random rotation around the axis perpendicular to the surface. Not essential, but maybe useful. II) Basic placement I understand that the default clouds are currently built up from filled boxes. In Local Weather, I use a large variety of techniques to place clouds, e.g. stacked cylinders, randomized trapezoid grids, Markov-chains, two-level core-periphery clustering, Monte Carlo terrain interaction,... in fact, I'm inventing a new method every month or so. But I think it's most useful to keep the exotic stuff in Nasal, and a basic box interface would reduce the overhead of writing into the property tree significantly. So the parameters which I think would be useful then are 1) latitude and 2) longitude of box center 3) altitude of box bottom, 4) box size in x direction 5) box size in y direction 6) box size in z-(altitude) direction 7) angle by which the box is rotated around the z-axis 8) number of individual textures to be distributed inside the box. III) Movement If clouds are to be moved, for each box the following additional parameters seem useful: 1) direction 2) speed 3) target altitude. 1) and 2) are self-evident, 3) is a bit tricky. Basically, if you start moving clouds around, you have to monitor the terrain elevation such that they react in a credible way to obstacles. Since terrain interaction is computationally really expensive (and the model how clouds should interact with the terrain should be allowed to evolve, as it is a bit simple right now), what I have found useful is the following: I use a very slow loop to inspect every cloud now and then (once per minute is enough) and then decide if I want to send it to a new target altitude, and the cloud movement routine picks up this info and if the current altitude deviates from the target altitude, it also introduces a slow vertical movement. Works fine and doesn't cause much computational overhead. IV) Fading in and out A weakness of my current approach is that clouds appear suddenly when they are created. It would be much nicer to have them appear gradually (if that can be done...) - so a parameter [0:1] like 1) target visibility would be nice - if set to 1, the cloud would be slowly faded in, if set to zero, it would slowly fade out. I don't know if that is possible on a per-cloud basis, and I for sure haven't found a way to do it from Nasal, but it's something worth thinking about. Other things that might be interesting is passing the fade-out ranges with distance runtime to the shader, as currently done for the default clouds (I haven't really figured out how to do it runtime from Nasal, so for me it's all hard-coded numbers in the shaders. Hm, I guess that would be more or less all I can dream up. :-) Hope that helps for your design plans! Best, * Thorsten ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
