Thorsten > > 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.
Thank you for your kind remarks. They look nice but in practice have a number of defects: an improved version is in the pipeline as Phase II. We had/have a great deal of trouble finding properties in the tree that actually worked with the shader at all - see Issue #445. From our side we picked what was a. surface wind, and b. worked. We had to use wind from N and E because direction and speed don't. We then need to construct both these values inside the shader. We have tried to accommodate Local Weather as best we can, but we would dearly like commonality between Local and Global Weather, using properties that the shader can read. Unfortunately, we don't know what causes some properties to work and others not, just that this is the case. > 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. Yes, surface wind is much needed. We don't mind if it's interpolated or not, we can handle either inside the shader. We expect other users would like an interpolated value. We just hope interpolation isn't what causes values not to be read. We would like surface-wind/speed-kt, /direction-from-deg, /velocity-from-east-fps, velocity-from-north-fps, (please not 'from heading' :-) ), but use whatever is easiest, we can handle the conversions easily enough. > > 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? That would be great - we thought perhaps this is what the property overcast was intended to do, but it's different in Global and Local weather. The math can be done out in the GPU - there's plenty of scope to offload tasks from the CPU. We already adjust the greyness of the sea to reflect the overcast value. (It would also be nice if the visible weather in Global matched the description a bit better: we make the sea grey when it's overcast, but the sky is still mostly blue). > > * 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? See http://www.e-publishing.af.mil/shared/media/epubs/AFMAN15-111.pdf It is estimated by an observer, or measured by an instrument. You can expect the METAR visibility to be a pragmatic estimation of what you will experience at the airfield. We look forward to phase III improvements to the water. We haven't yet tested the improved water shader with the improved skydome shader, but will do so in the near future as part of Phase II. Regards Vivian and Emilian ------------------------------------------------------------------------------ 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
