Re: [Flightgear-devel] Current Weather System...
@ Vivian: 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. Well, call me exceptional then, but I not only read the Flightgear Manual, but especially if something doesn't work to my liking, I try to read any bit of documentation I can find about that feature before I start typing negative comments or complaints. I'm usually quite embarrassed if my 'problem' turns out to be me not understanding the issue. I can't honestly say that I always succeed in reading up before opening my mouth - but I always feel bad if I overlooked something important. The manual is only peripherally for the user who want pretty eye candy (as you say, they're unlikely to read it anyway) - it's primarily intended to document how the system works and what it does for people who want to 'work' with it (i.e. enter discussions how to extend or improve the system, borrow algorithms for their own use, find the Nasal loop which needs to be repaired in case it breaks while I am not around, write their own weather tiles, use specified Local Weather Nasal functions from scenery models,...). 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'. Judging by Forum response, that'd make you a minority - so it's good that both systems are around then. But... just convince me! If you can do anything to the existing textures (placement algorithms, cloud models,...) which makes me go 'Wow!' then I for sure will not reject it because of some ego-thing. Local Weather looks the way it looks because that's the best I can currently come up with given my idea how things should be and my experiments what takes what amount of performance (I could render many things way better - with 4 fps - so I didn't bother to distribute or even keep these trial versions...). @ Stuart: I think that comparison is flawed, as a user starts FG with the intention of simulating aircraft in flight, and weather simulation is really a secondary consideration. (...) Being very blunt, this is after all primarily a _flight_ simulator rather than a _weather_ simulator. ;) The only thing I've ever piloted in real life are gliders, and from that perspective you're just not making sense to me. You can't simulate glider flying in a standard atmosphere - to get anything close to the real thing (planning the route based on what you see, guess which clouds are promising or where new clouds will appear, guess where blue thermals might be, estimate sink and lift in mountains,...) weather simulation is a primary consideration. The fact that there are craft (the Vostok-1 comes to mind...) where that argument is not true doesn't take that point away unless you want to take the position that Flightgear is just not for gliders. Or, from another perspective - yesterday I've flown in RL from Berlin back to Helsinki - and for 1 1/2 hours I have seen... clouds and sky - nothing else. So, for 80% of the flight, the weather engine rather than the scenery engine would have delivered my visual experience and all visual references. But in fact, the scenery engine configuration is at least as complicated (LOD settings, individual shaders on/off/performance - here I don't like the fact that all shaders are controlled by a single performance slider by the way..., ) as the weather config. I think if it is possible and sensible to simplify the configuration, we should do so. Agreed. Now, I suggest we proceed as follows: I've thought about the problem to the degree that I have written and tested a gui in various situations, and I have my opinion why it should be like this and not written in another way. I'll be happy to talk about any concrete proposal what to change which can be demonstated to work in practice (say for both a glider and an airliner flight profile). If anyone shows me a gui that it simpler than mine and doesn't cause problems which are absent in mine, I'll throw away my gui and use the simple one - as complicated as needed, as simple as possible is a very reasonable principle. But I can't get anything more out of abstract discussions of simplicity when I feel that issues which prompted me to make it complicated in the first place are not appreciated. Simple: Keep the options in the dialog simple, but add a advanced button, so everyone will be happy with the dialog! :D I'd be fine with that. Cheers, * Thorsten -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes
Re: [Flightgear-devel] Current Weather System...
On Thu, Jul 14, 2011 at 10:36 PM, James Turner zakal...@mac.com wrote: On 14 Jul 2011, at 12:46, thorsten.i.r...@jyu.fi wrote: 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. Indeed, and I've looked into this - it's a tough problem, but not an impossible one - and well contained - the current Nasal GC is a single source file. As you point out, the amount of scripted code is going to continue increase irrespective of local weather, so we need to bite the bullet sooner or later and fix the GC to be incremental. Fortunately, garbage collection is pretty well researched - the trick is finding an incremental algorithm that's 'simple enough' Note, Anders has created a patch that puts GC on its own thread a while ago. Admittedly that's not incremental, but still nice. -- Csaba/Jester -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[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
Re: [Flightgear-devel] Current Weather System...
-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
Re: [Flightgear-devel] Current Weather System...
On 14 Jul 2011, at 12:46, thorsten.i.r...@jyu.fi wrote: 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. Indeed, and I've looked into this - it's a tough problem, but not an impossible one - and well contained - the current Nasal GC is a single source file. As you point out, the amount of scripted code is going to continue increase irrespective of local weather, so we need to bite the bullet sooner or later and fix the GC to be incremental. Fortunately, garbage collection is pretty well researched - the trick is finding an incremental algorithm that's 'simple enough' James -- 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
Re: [Flightgear-devel] Current Weather System...
Hi Thorsten, Thanks for writing. I've got a couple of comments. On Thu, Jul 14, 2011 at 12:46 PM, Thorsten Renk wrote: 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 think the one reason for this view is the level of integration with the FG core, where you've had to work hard to override the global weather system through no fault of your own. I think with better integration, the local weather package will feel much more part of the whole. The other aspect is usability/simplicity, which I think is the nub of the problem and where we disagree. 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? I think that comparison is flawed, as a user starts FG with the intention of simulating aircraft in flight, and weather simulation is really a secondary consideration. I think if it is possible and sensible to simplify the configuration, we should do so. 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'. On the contrary, I think the two examples you give suggest a very simple heuristic, which is to decrease the resolution of the weather model as speed or altitude increases. I think this could be combined with a performance/quality slider in a similar way to the shader slider. As you say in your documentation, a number of the features (dynamic weather, thermals) are only really of interest to those flying low and slow. 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. Being very blunt, this is after all primarily a _flight_ simulator rather than a _weather_ simulator. ;) As Vivian has mentioned, people don't read the normal manual, and the Local Weather configuration really does require close reading of the documentation. As it stands, most users will not read the documentation, and will struggle to enable and effectively use this feature. I think that is a great shame, as it provides a much more interesting weather environment than the global alternative. IMO, by making some design decisions we can simplify the interface, provide users with the right balance of performance and quality without requiring that they tune every last parameter, and increase the number of people who can make use of this feature massively. I think that is something that is worth working towards, and I am very happy to lend a hand to help achieve this. -Stuart -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup
Re: [Flightgear-devel] Current Weather System...
Simple: Keep the options in the dialog simple, but add a advanced button, so everyone will be happy with the dialog! :D -- 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
Re: [Flightgear-devel] Current Weather System...
I think the one reason for this view is the level of integration with the FG core, where you've had to work hard to override the global weather system through no fault of your own. I think with better integration, the local weather package will feel much more part of the whole. I moved many computations out of the c++ core into XML configuration files, so we already should have enough points to hook into, but if there are any more things to do to open up the core weather system, I'm happy to do so. I think that is something that is worth working towards, and I am very happy to lend a hand to help achieve this. +1 Torsten -- 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
