On Tue, Apr 26, 2011 at 10:42 AM, thorsten.i.renk wrote: >> Now, the placed 3D clouds are wrapped, just like the global clouds, so >> if you travel far enough (50km), you'll come across the same cloud >> again. For local weather, that probably isn't what we want. So, I'm >> thinking of adding a new "wrap" property on the cloud layer indicating >> whether the 3D clouds should be wrapped. > > Yes, that would be useful - currently in Local Weather the same cloud can > (theoretically) be in the scenery for 110 km, so a wrapping every 50 km > would be problematic. > >> The question is, should this also affect other clouds movement, >> specifically changes to the layer altitude which current moves all the >> 3D clouds as well, and cloud movement due to wind? > > At least my code is taking care of all these issues, so from my > perspective I'd like to have a switch to eliminate any wrapping and global > shifts in layer altitude (since the implied infinity of the layer is > contrary to the 'local' in 'Local Weather' :-) ).
So when wrap=true the core code will wrap the edges, shift the layer with altitude and move it with the wind With wrap=false, we'll just move it with the wind. OK? > Basically, I'm keeping an Nasal internal record of where the cloud is when > it moves even now, since it's more efficient to compute position updates > from the record and only write into the tree rather than read the position > from the tree, recompute and write back. I also have, thanks to terrain > presampling, a rough internal representation of how the terrain looks > where. So I would know when to remove and respawn clouds even when I use > your code to move them with the wind. You'll want to move the cloud rather than deleting and re-creating as the cloud shape will be different (the sprite distribution and texture coords are random). One function I had on my TODO list was something to return the cloud position in lat/lon. However, it's a bit tricky due to the current limitations in the command interface. Do you see any need for it? Also, Is there value in having the core code handling the vertical movement of clouds due to terrain, as a precursor to removing the "wrap" feature completely ? Where there is stable function that should apply equally to the existing global cloud coverage as much as the local weather I'm keen to migrate it into the core code. In this particular case, I suspect that terrain sampling can be done much more efficiently in the C++ code. > The most important thing in your code for my purpose actually is the cloud > movement, since that is presumably much more efficient than doing hundreds > of setprop() calls per frame from Nasal. It makes sense to be able to > switch that off, because I suspect it also causes some performance > degradation when run by the core, but to my mind it makes sense to be able > to switch that off separately from wrapping, since unlike the other two > features it doesn't make any 'global' assumption for the layer. I'll re-read my code, but I'm pretty sure the perf implications are negligible for wind movement as we just move a single top level transform. > P.S.: Since I'm keen on backward compatibility - is there any easy way to > detect if the running binary has the new functionality? I know how to test > for properties, but to call a function and decide based on the error it > may or may not create is dangerous since the error message tends to alarm > users... I haven't checked what the effect of make an unknown fgcommand() call is, but I'm not aware of any other method to check. Do we have a version property in the tree? It should be pretty trivial to add. ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
