Re: [Flightgear-devel] Future Weather System

[Vivian M. <viv...@li...>]

> -----Original Message-----
> From: tho...@jy... [mailto:tho...@jy...]
> Sent: 12 July 2011 09:18
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Future Weather System
> 
> > What I'd really love to see in the mid-to-long-term range is some kind
> > of unified weather system. It does not really make sense for an average
> > user to have two systems to choose from.
> 
> Well, there's also a reason - the different design philosophy - and at
> some point you may want to consider that before you merge.
> 
> If you compare a system that tries to understand atmospheric conditions
> and terrain interaction with one that draws what you specify, then there
> are pros and cons to each:
> 
> * currently Global Weather guarantees (I think) that winds at a station
> position are exactly as reported in the METAR string. Local Weather
> computes the boundary layer wind slowdown locally dependent on terrain and
> can't guarantee that the winds will work out - by the time a METAR is
> received, the terrain at the station usually isn't even loaded and can't
> be probed, so the system has to make a guess what the boundary effect at
> the station location will be, and the wind at destination is only good up
> to that guess (that could in principle be addressed by correcting the
> guess once the terrain is loaded - it's just a nasty question of timing
> and subtly changing interpolation points...).
> 
> * same with cloud cover - if a system computes cloud placement dependent
> on terrain type and altitude, you can't guarantee that the end result will
> really be a 4/8 - it could come out 3/8 or 5/8 - again, it depends on
> guessing a factor before doing the placement
> 
> * on the other hand, if you place and drift clouds without terrain
> interaction, they'll just go through a mountain and emerge on the other
> side - isn't quite right either. If you compute winds without local
> boundary layer effect, the boundary layer will be as effective on a
> mountaintop as down in the valley - isn't correct either.
> 
> Maybe I am lost in seemingly irrelevant detail - but I think there's a
> good reason to have two systems dependent on what you need - either
> accuracy with respect to weather reports, or some physics model of the
> atmosphere interacting with the terrain.
> 
> (There is of course a proper solution, which is a proper physics model of
> atmosphere/terrain interaction - it's just computationally too heavy...).
> 
> >> Do you see this as a problem with the 3D clouds generated by the Local
> >> Weather system specifically, or 3D clouds in general?
> > It's 3d clouds in general but the local weather has the biggest impact
> > on frame rate. I think (better: guess) it's because Local Weather draws
> > more cloudlets. It's getting worse btw. the closer one gets to a cloud
> > and the more space on the monitor is occupied by a cloud.
> 
> I'm not sure about what's different in multiple monitors, but:
> 
> http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&start=345#p12442
> 0
> 
> (visual comparison with closed layers in METAR mode - Local Weather gets
> almost 25% better framerate)
> 
> In a single monitor setup, it's just not true that Global Weather is
> generically faster. In equal Cumulus conditions, I observe about the same
> performance hit (when slecting the same visual range to display clouds -
> when I compare 55 km visibility with 20 km, naturally 20 km are better).
> In overcast layers, I observe that Local Weather is sigificantly better -
> sometimes twice as fast.
> 
> I think cloudlets go the other way round - Stuart uses many (20-30 per
> cloud) small cloudlets, whereas I use few large ones (typically 4-8) with
> asymmetric rescaling to get the layering right.
> 
> If the problem gets worse when a single cloud is in view, it could be down
> to texture resolution - a single cloudlet texture used by Stuart is
> probably 120x120 whereas some of my large Cu cloud lets are ~1024x512 -
> that should give you a different performance footprint... Some people had
> issues with GPU memory, in which case dds textures helped (didn't help for
> me).
> 
> Apart from that, I can't really guess what makes it worse with more
> screens.
> 
> So - future plans:
> 
> Stuart has written a very nice interface from Nasal, which I plan to use.
> Since that requires newly arranged texture sheets, I will ask some people
> who have more experience with graphics software to help me re-extract
> textures from my cloud photographs - at that stage, we can also
> systematically test with dds vs. rgb and optimal resolution.
> 
> My current understanding is (I haven't tested too much) that Stuart's
> interface doesn't address issues which are related to number of cloudlets
> or texture size - once a model is in the scene, these should be the only
> difference. I can of course use the same clouds and textures as currently
> in global weather, but then you run into the same performance and visual
> issues (i.e. cloudlets are too small to effectively form layers, no
> developed Cu or Cb clouds, ...). What the system will most likely do is
> 
> * improve loading times
> * provide a conceptually clean interface
> * move clouds in the wind almost for free
> 
> In principle, one could try to code terrain interaction into here as well
> - but as I said, moving clouds interacting with the terrain opens a can of
> worms...
> 
> So, that's in a nutshell the plan for the mid-future.
> 

Here, with a Core 2 Quad, 4Gb RAM, nVidia GTx285 with 2Gb VRAM there is a
huge difference in performance. At EGMH and using METAR, I get 75 fps with
Global Weather, but when I use Local Weather, using the same METAR, I get a
little over half that. The loss of frame rate wouldn't be so bad, but for
the stagger in the frame rate with very noticeable pauses. These pauses make
Local Weather a very much less pleasant experience to fly with than Global
Weather. I would even sacrifice a few more fps for the sake of smoothness.

And if we could loose the hard edges around some of the textures that would
help. Right now, the Cu look like a series of cardboard cutouts stacked one
behind the other, flicking on and off. OTOH, I love the appearance of Ci/Cc.


For me the main issue is not so much the framerate, as the way the framerate
is being delivered. Second to that, the flicking on/off detracts greatly
from the overall impression of what is potentially a very good system.

Vivian