> So whatever we do, we can't override the ability to get low level > granular > control of the weather parameters, and not just so that advanced weather > can manipulate them exclusively, also so that external tools can > manipulate > them without advanced weather getting in the way or overriding the > settings. (...) > And please don't forget, there are command line options like > --visibility, --wind, --random-wind etc. > All those options override the other weather-magic. It took me quite > some time to make all this behave in a somewhat reasonable way with > basic-weather and I'd love to keep all that functionality.
I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed, but the internal control structure of the system shouldn't change. The current structure seems sane to me: * shaders which render the visibility take values from the property tree and are agnostic to how these got there * so does the terrain manager * the weather system has an 'idle' mode in which no properties are set by the system automatically, and it is possible to define weather with the property browser * Basic Weather can run and fill the properties based on interpolation tables * Advanced Weather can run using the idle mode and set the parameters from Nasal - once you stop the Nasal loops, you're back in idle mode and can set properties by hand * any external/future system can likewise use the idle mode to set parameters -> any shader will render these parameters regardless of how they were put into the tree. -> what you can't do is run two different systems at the same time The only problem arising is that Atmospheric Light Scattering uses three visibility-defining parameters to render rather than one, so if you define only one of them on the commandline, the rendering task is ill-defined and the framework falls back to the defaults as specified in environment.xml - which may or may not be appropriate for the weather situation you have in mind. The system is sane in the sense that it will always use the lower of visibility and ground visibility, so if you set visibility to a very low value, you'll not get to see the higher default ground-visibility on the ground. You can in any case specify the info by setting /environment-ground-visibility-m and /environment/ground-haze-thickness from the commandline and you will see the system responding appropriately, and Basic Weather or any external application could likewise set these parameters to other than default if so desired. There's a also host of secondary calculation of light attenuation and color rotation underneath clouds which are pretty complicated, and there's no chance to just set them to the right defaults - so unless you have a system which does the equivalent of these computations as done by Advanced Weather and sets the properties for the shader, you will get implausible lighting under some conditions. But that's an aestetic issue - FG remains usable with the defaults, it just doesn't give you the full eye candy. The whole part of the discussion about the max. visbility slider and realistic visibility checkbox in Advanced Weather is a completely different beast because it refers to Nasal-internal parameters which are not seen when any other system runs and not relevant for the shaders or the FG core. I think we need to keep parameters which are exchanged between subsystems in the discussion separate from parameters which stay inside a subsystem - there are many different wind parameters set by property rules for the water shader, others written for internal reference by Advanced Weather, yet others used to store the config of Basic Weather - but none of them has any relevance for the FDM for instance. So if there's any genuine concern that we might block options for any other development, I'd like to know what it is, because keeping options open is something which is high on my agenda as well. * Thorsten ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
