required SimGear commit 75271c44a82ae0fb1ff9c91e93a12fa8b10099fd
Since the consensus seems to be that the precipitation clipping issue is with the panel code, attached is my proposed update for the precipitation system in SG and FG
* without corresponding control structures in FGData it falls back to default, except I have fixed an inconsistency in freezing behavior - previously rain changed suddenly to snow when the temperature dropped below zero, but the reverse transition was dragged out and gave odd visible motion with the wind as snow gradually changed back to rain with the particle speed not well defined. Now both transitions are sudden. And I see no more particles flow against the wind
* with
<!-- definitions for the detailed precipitation manager -->
<precipitation-control>
<rain-droplet-size type="float" userarchive="n">0.015</rain-droplet-size>
<snow-flake-size type="float" userarchive="n">0.03</snow-flake-size>
<detailed-precipitation type="bool" userarchive="n">false</detailed-precipitation>
<illumination type="float" userarchive="n">1.0</illumination>
<clip-distance type="float" userarchive="n">5.0</clip-distance>
</precipitation-control>
added to Environment/environment.xml, the new system allows to switch more detailed management on. This provides
* explicit setting of rain droplet size and snow flake size by the weather system
* automatic sqrt(r) scaling of the vertical speed of raindrops
* automatic transition to snow when freezing for small droplets but hail for large droplet sizes (looks like snow, but has different particle dynamics)
* an illumination scaling factor to dim the precipitating based on the light we have in the scene (I still need to devise a property rule to set this automatically)
The clip distance is also exposed now and considered at startup of the system - might be useful for e.g. airships when the gas bag provides rain cover (?) or to be simply off for open airplanes
Modify startup sequence, so position can be modified late in the startup process, right before the scenery load starts. This allows two ugly hacks to move to a permanent, less hacky location. If other position init modes required similar late evaluation in the future, this can be accommodated now.
This is a somewhat high-risk change - I've tested both carrier starts and runway-selection based on realwx METAR, but please look out for other position-init issues and test before / after this patch.
New commands request-metar and clear-metar will bind metar reports to an arbitrary property tree path. E.g:
fgcommand("request-metar", var n = props.Node.new({ "path": "/foo/mymetar", "station":"LOWI"}));
so they can instantly adjust to the changed environment.
(Not fully working yet, since some environment settings, like environemnt
pressure/temperature, still changes slowly after a sim reset - instead of
immediately jumping to the new setting. Also, METAR sometimes arrives too
late...).
Various classes derive from SubsystemGroup, but extend the init behaviour. Fix those for the incremental init scheme, generally by forcing their init to be atomic. Can convert them to be truly incremental in the future if it's needed, but probably not.
Remove various hacks and make magvar work like a normal subsystem, as part of the environment manager. Fix the remaining users of the globals->get_mag accessor, and hence kill off the global pointer.
There used to be a hardcoded visibility of 1000m below which the
sky was disabled. This distance is now bound to
/sim/rendering/minimum-sky-visibility with a default value of 1000
- initialize uninitialized properties
- use prefix instead of postfix increments
- reduce visibility of variables
- use empty() instead of size() == 0 for vector and string
- pass string by reference, not by value
