> -----Original Message----- > From: thorsten.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] > Sent: 14 July 2011 12:46 > To: FlightGear developers discussions > Subject: [Flightgear-devel] Current Weather System... > > > If I may be permitted some personal comments about things which bug me? > I've been thinking quite a bit (possibly more than it's good for me) > triggered by responses on the list during the last days, and I would > perhaps take the time to clarify my position on a few things. > > I get the impression that some people believe that Local Weather is a > temporary, experimental thing. That's actually not my position. I assigned > a version number larger than 1.0 because for me it is a stable, mature, > well-performing system (running on a 3 year old Linux laptop) and no more > or less experimental or temporary than the rest of Flightgear (which means > it can always be better, but doesn't need to be so urgently). I haven't > seen any serious bugs for more than 2 months, it has some quirks (rain > textures sometimes not reaching all the way to the ground, problems when > two thermals overlap, winds being slightly off METAR are the recent ones > which come to my mind) - but I see quirks in many systems (the AP of a > large number of aircraft, global weather producing rain for blue sky > above, turning the view towards the rear in the F-16 introduces a 1 second > lag,...). Judging by forum response, there are other people who use the > system regularly as well instead of Global Weather and likewise don't have > major problems. > > Now, based on what I get to read here, there seem to be issues on other > machines. Largely, I can't fix these because there is not much > machine-specific in Nasal - so what am I supposed to do? Also, that's > hardly unique for weather or Nasal code - for instance, I can't use the > landmass effect - with a quality setting below 3 or so, all I see is black > - above 3 I get to see the relief effect, but I'm down to 5 fps. I have > received something like an explanation by Emilian, but as far as I know > it's not considered a bug which makes the shader effects an immature > feature, but simply something I can't have because of hardware issues - > and clearly not Nasal issue (otherwise, please fix...). > > Having said that, there are many issues of which I am aware, and they are > part of the documentation > > http://www.phy.duke.edu/~trenk/files/README.local_weather.html > > sections 10 and 11 - I try to list each issue, explain where it arises > from and what is planned for a fix or why in my current understanding it > can't be fixed. In 4 out of 5 cases when I get problem feedback, the issue > is listed there already... can occasionally be frustrating. I don't want > to start bitching here, but I think that type of issue list actually not > done by so many people. > > Another part of the reason that the system is considered immature seems to > be that it is coded in Nasal. Now, it's a fact that C++ is in general > faster and that complex heavy-duty Nasal code has issues with garbage > collection which trigger single-frame delays. > > However, I think there is some dislike of Nasal involved which goes beyond > what is covered by these facts. As for speed, my current best estimate is > the comparison in performance between Torsten's hard coded terrainsampling > and my Nasal version - his seems to be about a factor 3 faster. Which > sounds a lot - until one realizes that the difference between efficient > and inefficient code is usually way more. > > As an example, we're to all appearances currently calculating ridge lift > in the core code on a per-frame basis sampling a series of terrain points > along the windline even if the actual value of ridge lift is 10e-6 ft/s > because we are 20.000 ft above every terrain feature (at least I get to > see the value updated per frame) - isn't actually needed with that > precision or sampling rate unless we are much lower and the loop could run > every 100 frames at high altitude or sample just one terrain point - > possible efficiency gain: factor 100 or more. > > Different example - the gradient terrain shader takes a lot of performance > on my system - presumably because it computes a quantity (terrain > gradient) on a per-frame basis which is actually constant across frames > (?). > > Likewise, the dramatic difference in performance between Stuart's and my > ways of moving clouds around has little to do with Nasal vs. C++ - > largely, Stuart has found a much more efficient way to solve the problem, > instead of moving 400 individual models, (as far as I understand) he > combines the whole layer into a model and just moves that. It remains to > be seen how we then fare when the need arises to introduce vertical > movement of clouds - Stuart has provided a move operation, but that seems > to teleports the cloud to a new location - so it must be applied on a > per-frame basis again to get a smooth motion - which may deteriorate > performance. But doesn't really spoil my point - efficient coding is the > key. > > > Nasal has a garbage collection problem. One solution to it is - we avoid > Nasal code wherever possible and try to hard-code everything. But Nasal > crops up on a lot of places - complex aircraft such as the Concorde come > to my mind, interactive AI models, lots of really nifty and useful > applications... - so instead of fixing things in a lot of places, one > could also think about it the other way and fix just one thing, i.e. the > garbage collection such that it doesn't hit a single frame. I fully well > realize that dragging out complicated operations across many frames while > everything else keeps changing is at least an order of magnitude more > complicated (about 1/3 of Local Weather deal with precisely that > problem...) - but I don't believe it can't be done at all. It sort of bugs > me a bit that somehow the fault is always supposed to be in using Nasal... > > I think it's great if we have a discussion where the issues are placed on > the table to give everyone the change to learn and understand more, and > then reasonably decide what to do. Nasal has advantages and disadvantages, > so has C++, sometimes accessibility and safety are worth a factor 3 > performance (to me at least), sometimes not. But I don't really want to > discuss dogmatics where 'truth' is a priori clear. There is a case for > having high-level routines in Nasal, there's a case to be made to switch > low level workhorses to C++ - and there's always the question of what is > the most efficient way of doing something. But I'm clearly not considering > Nasal-based systems immature or experimental per se. > > I have a pretty good idea what task within Local Weather has what > performance footprint - I have several sheets of paper with systematic > test data at home. For some reason, pretty much nobody believes that and > people have their own pet theories (often a variant of 'Nasal is slow') - > I just can't take that very seriously - I am a scientist, I actually > believe in doing experiments, tabulating results and drawing my > conclusions from there. > > The third issue that bugs me is the expectation of simplicity. Usually in > Flightgear, it is just accepted that things can be complicated. Flightgear > is not an arcade game, if I want to fly the P-51D, I have to learn how to > takeoff, that's complicated. Nobody here asks to simplify the FDM so that > everyone can take off. But somehow, for a weather GUI, we should be back > to arcade mode where a mouse click and a single performance slider should > be all it takes. I don't really understand why - the argument for me is > still the same - we're trying to be a realistic simulation, weather in > reality is complicated, so why do you expect arcade-game like > configuration? > > In fact, weather is so complicated that if we introduce more and more > realism one has to make a choice what to focus on (dependent on available > performance, that can be a hard choice or not) - the system isn't designed > to run in 'one mode fits all', it's designed to commit resources to what > is most important, given the type of flight you plan. > > As an example, when I fly airliners, I'm not interested in simulating > cloud movement (doesn't show with 250+ kt airspeed anyway) or thermals (do > not occur at 30.000 ft) - but I am interested in seeing clouds as far out > as possible (because that's what I see from 30.000 ft). I move my sliders > accordingly. > > When I fly a glider, I'm very interested in thermals, moving clouds > (thermals and cap clouds must move with the wind, otherwise the experience > isn't very realistic) - but I am not interested in large visibility range, > since I'm pretty much level with the convective layer anyway - so I do the > configuration drastically different. > > If you take a moment to think about these issues, a system can't make the > choice for you automatically, because it depends on what kind of flight > you want to make. So you have to do it yourself. Or get a system that is > so scaled down in performance that it gives you the minimal 'one fits > all'. > > It seems applying two different measures to me to widely accept that > aircraft systems can be very complicated and that people need to read a > manual to start the engines, but to expect that an (optional!) weather > system is simple to configure and yet delivers best performance. > > Since 'respect' was a topic recently - part of that is in my view to make > an effort to understand why the other person thinks or does things in a > certain way, rather to assume that it's because he doesn't know a thing. I > for once enjoy feedback of the type 'Look, you think this is like that and > that, but I think this could be organized in a better way like this...'
> much more than 'I haven't bothered to read the manual, and I have never > really used it, but I have just clicked myself through a bit, and it > didn't work like I expected, so it must be bad...' (disclaimer: The last > is an exaggerated cartoon - no reference to any specific person here > intended). > > Thanks for reading, Interesting reading. Thanks for sharing it with us. I'm only a computer scientist (now retired), but here are some heuristics for your consideration: 1. No one EVER reads the manual. Not for nothing is our manual called 'The FlightGear Manual' - so we can justifiably say RTFM. Now that I have read your manual, I would say most of it would go right past the average user, who wants to simulate flying, look out of the window and see pretty eye candy. I now know how to do things in Local Weather, but not why I would want to. And btw - we have to fight off those who do indeed want easy-to-fly FDMs 2. The Best is oft the enemy of the Good Enough. The Local Weather stuff is scientifically accurate, but rendered almost unusable here by the stagger in the framerate. In this context I suppose that you are aware of this: http://www.ofb.net/~niniane/clouds-jgt.pdf I don't know if there are any concepts there that might easy the impact on frame rate. 3. C++ good, Nasal bad, to paraphrase George Orwell. We know that a major cause of stagger is Garbage Collection, but I don't think we know how to fix it in the foreseeable future. I would assume that the way to avoid stagger is not to add great chunks of Nasal to an already bad situation. 4. Beauty is in the eye of the beholder. I think clouds are beautiful, particularly Cu. I look at the Global Weather Cu and think: 'Wow' even although I know they aren't quite right, and never tower enough etc. I look at the Local Weather Cu and go: 'Hmmm'. Thanks again for sharing your thoughts. With that - back to tinkering with the existing textures - at least that's something practical that I can do. 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
