I've finally (I guess you all know the feeling of too much other stuff to do...) managed to start some tests with Stuart's Nasal interface for 3d cloud generation. Right now there is only a very rough placement structure and no real management (no removal, no distinction of cloud size, all same textures, no evolution,...).
Basically, it works as advertized: http://www.phy.duke.edu/~trenk/pics/3dclouds-lw.jpg (it's not abundantly visible in the pic, but the layer shown differs from a normal layer in that it doesn't extend over the ocean, so the cloud position distribution is computed using the Local Weather MC code) In performance tests, I've been unable to see a significant effect (the default 3d clouds were maybe 5% better - but since we're comparing different number of cloudlets and different texture resolution, it's not clear to me what that actually means), I didn't notice any difference in tile building time (that's currently for Cu clouds dominated by terrain probing anyway) - but cloud movement in the wind is for free. I can't easily convert the whole system (texture sheets are not ready), but I'll write a parallel system for managing cloud generated with this technique and convert the system to that over time. Some issues: * naturally the clouds obey the visibility range as specified in the rendering dialog - which isn't far enough for my purposes. Can I simply override that number by a setprop() (will it snap back if someone opens the menu?) or is there a better way? * where's the switch to remove the boundary wrapping of the layer? * what property determines the visible motion? When I created the layer using Local Weather, clouds were moving with corrent heading and possibly also windspeed - so I assumed that it's wind settins as specified in /environment/ . However, I then switched Local Weather off, used the property browser to set windspeed to zero and assume the clouds would then stop - they didn't however. So I don't understand what I need to set to get the correct behaviour. * for layered clouds, I really would need the z-rescaling parameter *after* the rotation matrix has been applied (there's no way to do without, you're losing performance quadratically with area, so cloudlets need to be large without making layers ridiculously thick) - can we extend the parameters to be passed to the shader by that? Otherwise, I think this is very promising, and might be ready in a few months... * Thorsten ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
