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, * Thorsten ------------------------------------------------------------------------------ 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
