> 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.
Torsten, does that sound viable to you? I'll be happy to write them from Local Weather, but we should agree on a set of names to write. > 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. In my way of thinking: /rendering/scene/overcast The amount of haze color mixed to the sky color. Unless it's very close to 1, the effect is more like a thin haze layer at high altitude not really blocking the sun, if it's close to 1 it can double as a credible but cheap overcast layer from below (doesn't work from above obviously). Not really a good proxy for cloud coverage /rendering/scene/saturation This directly dims the sunlight and is supposed to represent clouds blocking the light. Unfortunately, in many situations it turns out to be an overkill (it doesn't do to dim the whole sky when you're circling below a cloud) so I only use it in low visibility situations such as inside rough weather (heavy rain usually). /rendering/scene/scattering This is supposed to represent the (perception-weighted) light intensity below the clouds, i.e. it selectively dims the terrain only without touching the sky. Probably, this is more or less what you'd like to use. > The math > can be done out in the GPU - there's plenty of scope to offload tasks > from the CPU. Not necessarily. I was a bit shocked yesterday when I flew the IAR-80 and lost 1/3 of my framerate with the skydome scattering shader on - it has never ever affected my framerate that much, but I suspect the IAR80 places a high workload into the GPU to begin with, so suddenly this becomes the bottleneck of the whole operation. As for putting math to the GPU - from an algorithm point of view, something doesn't seem right. Cloud cover is something we want to compute once per minute or so - putting it into a vertex shader means it's computed per frame per vertex, that seems a bit excessive. Is there a way of putting things to the GPU such that they're only computed once per frame? For instance, for every cloud vertex we compute the eye position by multiplying zero with the inverse model view matrix - although it doesn't change from vertex to vertex! That's a few thousand matrix multiplications per frame which we actually don't really need to do. With rendering haze (and some people are thinking of rain already, some asking for cloud shadows) I see us running rapidly out of GPU performance... Cheers, * Thorsten ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
