On Wed, Mar 30, 2011 at 12:56 PM, Thorsten Renk wrote: > > To follow up Stuart, here are some of my thoughts: >
Thanks. Comments below, significantly colored by what I've managed to implement in a couple of hours of hacking here :) <snip> > 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. Yes, in fact, my basic strategy was to use the existing default 3D cloud code almost untouched from the perspective of creating a set of sprites that are built up into a cloudlet. So, you can define (amongst other things) - the texture sheet to use, - the number of sprites, - min/max width and height of each sprite, - the width and height of the distorted sphere to place the sprites on. - shading of the bottom of the cloudlet - lat/lon/alt of the cloudlet. I'm sure you are very familiar with the capabilities and limitations of that approach, but it would be worth having a look at the README.3dclouds so see the API available. Note that I'm just considering expositng the bottom level cloudlet, so building them up onto multi-part clouds and boxes of clouds will be done externally. As it happens, I've already got this approach working, along with a Nasal interface and a dynamic (single level for the moment) quad tree. It's quite neat. > 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. To match the existing global 3D clouds, it would be easier for each "cloudlet" (cluster of sprites representing a cloud puff) to use a single texture sheet containing multiple sprite textures. However, there is control over the uv coordinates of each sprite, where the x-axis is random, but the y-axis is controlled by the vertical location of the sprite. So you can create a cloudlet with a mixture of textures, and have a fair bit of control of those textures. > 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. We could certainly add new parameters to the shader. I'd prefer to do that rather than generating a number of very similar shaders. Also, note that there is control over the shading of the cloud in the existing shader, so you can make the bottom of the cloud darker that the top irrespective of the texture. > 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. I've already got support for random variation in texture size. I did think about allowing additional rotation but never implemented it - should be pretty straightforward. > 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. I'm thinking of not tying the cloud placement and parameters into the the property tree at all. So while the Nasal interface would use a property hash to define the initial cloud position, the cloud position etc. isn't tied into the property tree. Instead I'm thinking of the creatCloud() call returning some correlator that can be used by the Nasal client to reposition or delete the cloudlet. Of course, this doesn't stop the client from using a property tree to keep track of position etc. but it does mean it's optional, which may be important if we have to track thousands of cloudlets, or the Nasal code just wants to create the cloud and then forget about it. > 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. I'm thinking the base API will be the lon/lat/alt of an individual cloudlet, possibly with an additional x/y offset to save lots of costly calculations when creating a series of cloudlets next to each other . The Nasal code would then be free to group these as it wished. > 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. Certainly we could include horizontal movement on a per-layer basis, so you would add a series of clouds to a layer, which would move together. I wonder if the terrain elevation code would be any faster in the C-code. Is the movement of clouds to follow terrain a straightforward model? e.g you could mark a layer as following the terrain, and then apply some algorithm to determine cloud vertical movement as it travels? > 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. In the plib days where we just had Cu clouds, they were faded in and out to represent the Cus forming and dissipating. > 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. Well, we'll get that for free by using the default cloud code :) -Stuart ------------------------------------------------------------------------------ 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
