> -----Original Message----- > From: thorsten.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] > 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 ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
