> I also wonder if the terms "global" and "local" are really applicable. > Would > "static weather modeling" and "dynamic weather modeling be better terms, > or how about simple/complex?
I guess the key differences in philosophy are: * terrain interaction: clouds in Local Weather 'know' terrain type and elevation underneath and react to it, clouds in global weather don't * locality: weather phenomena in Local Weather are genuine local things - you can see rain underneath a cloud from the outside, fly there across a visible border and get wet and fly out again. Can't do using global weather. Also true for e.g. pressure which is interpolated - wasn't so in global weather a while ago, but is now, and the systems have become more similar here * (some overlap with the first point) physics: Local Weather tries to implement an (admittedly crude) model of atmospheric physics and dynamics, Global Weather renders what you specify without trying to make too much sense of it I don't think 'static' vs. 'dynamic' are good labels, I would apply these to how much things change in time, and as compared to the last release, Global Weather has now the interpolation of METAR as well as moving 3d clouds, i.e. a fair share of dynamics. 'simple' and 'complex' would work for me, although it's a bit of an injustice to the 'global' system as it isn't really that simple either. I'm not particularly attached to the current labels, but whatever we choose should capture the essentials. > I think this "launcher" aspect is something that we want to hide from the > end-user. Most people just want to be able to change the weather > system and then press Apply or OK. Having to press "Stop" first is very > different from the rest of the UI. > > I think we'll want to make this implicit, so the user can press (say) > Apply, and > the underlying weather system stops and then is started under the covers > with the new parameters. You can do this, but there'll be a price to pay: The user also expects that he can 'just' change the wind, press okay and it's done without waiting half a minute - but that's not true. The reason is that with terrain interaction you open a can of worms, and especially with moving clouds over time it gets worse an order of magnitude - you need tons of computations in the background - which is no problem as they can be split over many frames, the system just doesn't start or change in a hurry. Take my current project - 3rd generation cloud/terrain interaction http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&start=375#p129648 Each cloud placement takes into account terrain gradient at kilometer scale, terrain elevation, terrain type, wind direction, windspeed and time of the day. If you change the wind, the whole picture changes. You just spent ~1500 frames getting to what you see (which by the way I think is acceptable at startup, as you'd usually start your engines and go through your procedures anyway, so you don't need full framerates). If you change 'just' the wind and press okay, you can implicitly restart the system - it's just going to delete everything and recompute for 1500 frames - there's no way to hide that unless you make probing the terrain a factor 100 faster. So if you can't hide the fact that you have to restart everything, in my view the user is going to be less disappointed if he realizes that he has to restart everything than if the system pretends you can just change parameters and be done with it. > Apart from the stop/start time (which could be handled by a "please wait" > message), is there any reason we couldn't do this? Psychology. In my view it's bad to give the user a false impression. Not realizing it's a full restart, a user will be disappointed that it takes that long to change the wind. Having the info that it's a full restart, he's more likely to accept it. (I see myself waiting at the gate at an airport. Being told that I have to wait foran unspecified amout of time just makes me angry. Being told that there is a severe storm at my destination and we can't land, but if we wait for 2 more hours so that it can be expected to have passed by the time we arrive, I'm fine.) > I think 90% of users are going to struggle to understand what most of > these settings mean. Well, it's a complex system, so its configuration reflects some of the complexity, an it comes with a manual... If some user tells you 'I have trouble to understand what all these gauges in the cockpit of the c172 mean' - do you simplify the cockpit, or do you ask him to read the manual where it is explained? I'd be happy with a limited number of options - but many users can't run the system well with the set of options I like - and that was the point when I started exposing properties so that the system can be customized individually. I took the time to document every option and most algorithms in 42 pages of manual (out of which you are free to read what you need - the description of what a particular option does is shorter) - so that's where I would suggest to start when things are unclear. > Is there one particular setting that you are changing regularly? > Perhaps we could extract it alone and give it a easier to understand > name? 'cloud visible range' is the most effective for performance, followed by 'max clouds in loop' when I start moving clouds. > I think this really highlights the problem - it really isn't obvious > from looking > at the UI that the Local Weather can interpret Real Weather. Fair enough - I agree here. * 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
