On Thu, 1 Feb 2007, Curtis Olson wrote: > It's somewhat of a complex C++ inheritance maze to wade through,
Affirmative. ;) Looking at the code I can tell there's years of development in layers on top of each other there, not entirely consistent with a one and same philosophy. > I'm not a big fan of interpolating between nearby stations because as those > nearby station conditions are updated, you will still see discontinuous > jumps in the local conditions ... plus it's complicated, time consuming, > memory consuming, etc. > > What I would like to see is a mechanism that slowly (over the course of a > couple minutes) migrates the "current" conditions towards the most recent > data that is fetched via the metar subsystem. Time interpolating over several minutes on a per plane basis will make pilots on MP each flying in their own weather, even when they are all using METAR weather (which IMO should be mandatory on MP). So they wouldn't even agree on where the flighlevels are. That would mess upp the IVAO stuff Pep Ribal was talking about here recently. As I mentioned in my last message, I'm more into using a combination of geometrical interpolation and time interpolation using a small time delta (seconds) to filter out the remaining transients. But again, we can't get enough data from METAR only. (Think of intercontinental flight) I can also imagine that different users with different needs for a flight simulator would have different needs for weather model. Someone might want to have a detailed simulation of microweather using software like MetPhoMod (http://www.giub.unibe.ch/klimet/metphomod/, GPL'ed), for simulating flight in a mountain area with difficult up- and downdrafts; soaring pilots want realistic thermals that a motor pilot only thinks of as "turbulence". Helicopter landings on offshore oil rigs etc etc. My feeling is that there should first and foremost be a defined interface for weather vs the rest of the sim system. Then people can hook up whatever they like to it using that interface. > > We could do this a number of ways ... we could extend the interpolations > scheme out to another enclosing layer to interpolate smoothly between "past" > and "current" conditions. We could simply move the data values in the > "current" interpolation tables slowly towards the new values as they are > updated. This might be the simplest. We could establish some sort of > reasonable rate of change for each value type and just at that delta every > iteration. > > This doesn't address clouds which are slightly more complex ... you could > slowly move a layer to a new altitude and that should work ok, but how do > you add a new layer or remove a layer smoothly and cleanly ... that get's > tougher with our current scheme. I am currently time interpolating everything weatherish typed as a double using a modified fgSetDouble() with an extra optional argument. (But for some bizarre reason, the sea-level air pressure -- what I particulary want to smooth out -- refuses to be interpolated yet. AAaargh!) Horizontal cloud density is not a double though -- conceptually it's an enumerate rather. Not much I can do about that. But the clouds doesn't knock the aircraft over in a tunnel roll. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
