> I've just committed (thanks to Torsten) an update to the 3D clouds. As > well as fixing a bug that caused the cloud density to be significantly > less than it should have been, the global 3D clouds now move with the > wind, which looks rather nice IMO. > > This update also adds a couple of new commands that can be called from > Nasal using fgcommand() - "add-cloud", "move-cloud", "del-cloud". > This allows you to create individual clouds using the same technique > and parameters as the global clouds. Those interested may want to look > at the README.3DClouds.
That sounds very good - thanks for the work! I'll finish my current open projects and then have a look at the functions in more detail. > 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' :-) ). 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. 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. Well, actually it does since you'd move all clouds with the same windfield, but that windfield can be computed locally, so the error you make by moving everything you see with the winds at your current position is marginal... Hope that helps, * Thorsten 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... ------------------------------------------------------------------------------ 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
