> 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#p124420 (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. 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-d2d-c2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
