Some observations I've made in the last couple of days:
* hardcoded terrain presampling: This seems to have died on me after the last pull (probably even earlier?) - currently all I get out is zero everywhere. Since geodinfo() is now 50 times faster than it used to be, falling back to the old system doesn't really make a huge difference in performance though. Whatever you think is best - fixing or going back to geodinfo() - just let me know please. * new water reflection shader - since it doesn't talk too much to Local Weather, I had completely missed it has plenty of features. Great work, Vivian and Emilian - the foam caps look gorgeous. I'd like to talk to the shader better from Local Weather as well. I've had a look what parameters you're probing, and for example you use the wind from the global weather lowest boundary layer config. Now, I can write that from Local Weather, but that's not a clean way to do things and I'd like to avoid going back to writing into the global weather config to get things done, Torsten spent a lot of time on making it possible to avoid that workaround. Instead, we could maintain properties 'surface-wind-fps' and 'surface-wind-direction-deg' under Environment which are continuously updated by the weather system (global weather has also interpolation and continuous time dependence, so if I'm not mistaken the actual value doesn't have to be the one in config/). That set of properties could also be used by any other wind-dependent surface objects (smoke effects on the ground, windsocks,...) - which somebody else on the list wanted to have implemented a while ago anyway. Likewise, with total cloud cover - currently the shader tries to deduce that from a number of sources. But for the weather systems, it'd be rather easy to add the coverage of the individual layers probabilistically to get a total coverage and simply provide that number to be used by the shader. (adding layers probabilistically: say I have a 5/8 and a 2/8 - the total coverage is then 5/8 * 6/8 (I'm hitting first layer but not second) + (3/8 * 2/8) (I'm hitting second but not first) + 5/8 * 2/8 (I'm hitting both); or simply 1 - 3/8*6/8 - which is 0.718 or a bit less than 6/8.) Does that sound like a reasonable way to transmit info from the weather system to shaders? * visibility: Comparing X-plane and Flightgear screenshots for supposedly the same visibility, I've come to think about the definition. In nature, things fade exponential in distance, so the contrast goes away as exp(-distance/lambda) where lambda is the mean free path of photons in the medium. Any physicist would usually take lambda and say that this is the visibility. But after the distance lambda, of course 1/e ~ 36% of the contrast is still there and you can recognize objects. So what's the limit when we conclude we don't see anything any more? 1% of contrast? 0.1%? Dependent on that limit, the relation of lambda to visibility can be a factor 3 different. Flightgear currently seems to fade with exp(-(distance/visibility)^2) by default, which sort of lessens the question by a harder cutoff at the expense of being unphysical for small distances. X-Plane seems to cut visibility even sharper with some kind of smoothed theta-function, so no attenuation up to a point, then sudden fog. So, how's it done in practice for weather reports? Is there a precise attenuation definition, or is it more or less guestimated? Cheers, * Thorsten ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
