On Thu, Aug 4, 2011 at 8:15 AM,wrote: > > 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
Glad you've managed to get the initial placement working > 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. Even though your previous testing showed no perf difference between the default 3d clouds and the models, I am slightly disappointed there isn't some intrinsic perf benefit to the default 3d versions. Hopefully I can improve the terrain probing to make a real difference in tile building time. > 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. That sounds like a very sensible approach. > 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? Yes, you can just use setprop. However, currently the slider maximum is 20km, so if the user opens the Rendering Dialog and then presses OK, it'll be reset to 20km. We should change the maximum to whatever you feel is sensible (40km?), and leave the default as it is (20km). However, I'm not sure we want to be over-riding the user's explicit preferences here. Perhaps we should look at integrating your routine to match a given fps value by adjusting cloud visibility range? > * where's the switch to remove the boundary wrapping of the layer? Not implemented yet. As you've managed to get the general integration done, I'll try to get to it soon. > * 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. >From memory, it's from the appropriate /environement/layer[n]/ property. > * 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? Yes, that's something I need to do. I think you've already implemented this in your codes. Can you point me at the best example shader/Effect? > Otherwise, I think this is very promising, and might be ready in a few > months... Great. Let me know what else you need and I'll put it near the top of my FG todo list. -Stuart ------------------------------------------------------------------------------ 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
