Re: [Flightgear-devel] Sea color
-Original Message- From: Ron Jensen Sent: Saturday, May 19, 2012 2:54 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Sea color On Friday 18 May 2012 10:59:22 Alan Teeder wrote: On the subject of frames rates I have a couple of questions. 2. Is there a mechanism for making the core - fdm, afcs, equations of motion etc. run at a higher priority than the rest of the simulation? The JSBSim FDM and systems coded in JSBSim run at or near a stable 120Hz by running multiple times per graphics frame. Ron Thanks for that. Alan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
Thorsten Conclusion: don't try to optimise, particularly for a poor system - you might make it better for that system, but more likely you will make it worse for everyone else. Judging by framerate comparisons with people in the forum, my system is still somewhere in the upper third - many people have to live with less. Judging by user requests and comments, more than 90% want higher framerate out of the system by any means, you represent a minority of users who would be willing to sacrifice framerate for smoothness. With your scientific background you should know better than cherry-picking that statistic. Those on the forum are a self-selected minority of our users. We have no idea what our users out there are using, neither hardware nor OS. We don't know if they have tried Advanced Weather and abandoned it, or put up with stuttering, or never tried it. Anecdotally, there are plenty of complaints about stuttering, and AFAIKS these are really only apparent with Advanced Weather or Concorde. Most of us are happy to see Rembrandt or lightfields with anything resembling 20 fps. So, just who is that 'everyone else'? And for whom do we optimize? You're basically saying I should optimize things for you - but that would make it worse for everyone else not running a high-end system. No I'm most definitely not. What I'm saying is that by optimising for a subset of users, you run the risk of sub-optimising for the rest. Right now, with Advanced Weather we have a weather simulator with a FlightSim attached. We're spending 10 (yes 10!) times as long in the Events Sub-module with Advanced Weather than in Basic, and 5 times as long as we spend in Flight. That'd probably be because Advanced Weather does ~10 times more complex calculations than Basic weather... And I'm not surprised that it takes more than flight either - flight is comparatively cheap, that ran with decent accuracy 10 years ago. To compute a non-local environment (i.e. that knows that conditions 'here' are different from conditions 'there') is quite a bit more expensive and we could not do that 10 years ago. As for your comment, yes, that's quite true - that's just how the problem is. Teaching thousands of clouds where convection is, or how to flow over terrain obstacles is expensive, even if you do it schematically. That's what's needed to give you semi-realistic distributions of clouds. If you're happy with just clouds in the sky, that's cheaper, but not what Advanced Weather is for. I think Advanced Weather is good. I'd like the opportunity to exploit my (fairly - it's getting a bit long in the tooth now) high end system to enjoy it - not have to put up with an experience that is not as good overall as basic weather. Writing data to the Property Tree is bad. This one is not evidence based That's evidence based (I have done some testing a while ago just how long it takes) - it's currently minimized in my code, but the tree is the interface between menu, C++, Shaders and Nasal, so ultimately some stuff has to be written or read. To be honest, I think there are design difficulties with Advanced Weather. There should only be one loop - the update loop - running at main frame rate which activates/deactivates the various sub-modules as required. I think I have done enough work here to demonstrate that this is a viable way forward. The current design with multiple loops * has robustness (a problem in one submodule doesn't crash the whole system) * has good framerates (which is an issue for the majority of us) * is easy to debug (as it doesn't hand over too many parameters between iterations) Unfortunately, Advanced Weather can and does crash Fg here. I haven't looked into it properly - but there's no obvious reason atm. If running the individual loops at main framerate solves your smoothness problems, then we can start for instance making the loop timers user- configurable. Sacrificing framerate for smoothness is a compromise you might be willing to make, but I am not, I need the framerate. Yup - with bare fg I can see over 200fps (not at KSFO of course). I can spare a few for smoothness. I agree that for your problem, your solution is the correct way forward - but my problems are different from yours. So what do we do about that? For a start we can try to make the Nasal better, I think that might help a bit. I spent an hour or so picking over your code. So far I've found: 88 declared but unused variables 47 declarations of the same or similar variables 427 instances of else if instead of elsif 100 instances of I = I + 1 instead of i+=1 Numerous examples of variables declared inside for loops, and some of those are inside other for loops Variables declared inside condition statements. Nasal is tolerant of those kind of things where other languages/compilers would at least warn you, and might throw an error. Nasal might even optimise them away, I don't know.
[Flightgear-devel] Nasal CG: (Was: Sea color)
On Sat, 2012-05-19 at 10:22 +0100, Vivian Meazza wrote: I'm still hopeful that we will get a better GC. If someone wants to try to improve it this document might help: http://engineering.twitter.com/2011/03/building-faster-ruby-garbage-collector.html Erik -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
With your scientific background you should know better than cherry-picking that statistic. Those on the forum are a self-selected minority of our users. (...) No I'm most definitely not. What I'm saying is that by optimising for a subset of users, you run the risk of sub-optimising for the rest. *sigh* Did you read what I tried to tell you in my last mail? Without optimization, the code would run in single digit framerates. So it has to be optimized, it's not a question of if, just of how. The only system for which I can do this is my own, because I don't have data for any other system. If I get good solid data from your side, I can include that into the optimization. But please remember - we're talking optimizing the last 5% or so here. In brute force mode, it would never ever run fast enough. Generating clouds on a one per frame basis for instance is not an option - it's way too slow. Doing all administrative tasks every frame is not an option - this generates way too much load. I think Advanced Weather is good. I'd like the opportunity to exploit my (fairly - it's getting a bit long in the tooth now) high end system to enjoy it - not have to put up with an experience that is not as good overall as basic weather. And I'd like to support that. So what I need is data how your system responds to certain things, then I can understand what causes the problems, then I can hopefully fix them. What I don't need at this point is your theory what is wrong unless you understand sufficiently well why things are coded the way they are. I have a certain advantage here - I know very well what the individual loops do and how and where they burn performance. Unfortunately, Advanced Weather can and does crash Fg here. I haven't looked into it properly - but there's no obvious reason atm. Never happened to me. Also, I found it very difficult to crash Flightgear from Nasal in general - in all my time coding in Nasal, I have just discovered a single way of causing a segfault. So, I have to leave it to you to figure out the why, I can't reproduce it, and I have logged hundreds of flight hours with Advanced Weather on. For a start we can try to make the Nasal better, I think that might help a bit. I spent an hour or so picking over your code. So far I've found: 88 declared but unused variables 47 declarations of the same or similar variables 427 instances of else if instead of elsif 100 instances of I = I + 1 instead of i+=1 Numerous examples of variables declared inside for loops, and some of those are inside other for loops Variables declared inside condition statements. Nasal isn't C++ and variable declaration isn't the same thing for instance. If you want to speed up code, you have to go where performance is burnt. And that happens wherever you call add-cloud() or geodinfo() or setprop() or getprop(), i.e. the hard-coded stuff - that needs to be carefully distributed across frames for a smooth experience. What you do Nasal-internally is subleading and usually I couldn't ever measure a performance impact. As I said, I am currently going over the code and throwing out stuff which the transition to Stuart's cloud system has made obsolete and which are currently just de-activated by if-statements. That allows to streamline some other processes, because some situation can't occur any more, and that should take some load off the main loops and definitely reduce load for the GC if this is anywhere sensitive to code size. I would expect much more from that than from semantic details (I don't even know whether else if or elseif would be faster in Nasal - has that been tested? ). In the mean time, can we do the following: There are two issues: 1) framerate impact while a weather tile is built (that happens a lot initially as up to 9 tiles are built, and later depends on the speed of your aircraft - the Concorde triggers a new tile every 16 seconds, the C-172 takes a few minutes. 2) framerate impact and smoothness while no tile is built For the time being, I'd like to focus on 2) (because optimizing tile building is *really* tough and I don't even have an idea for a better algorithm which doesn't break in some situations) so you may have to live with stutter/framerate drop caused by tile-building for a while longer. Without tile-building, I'd like to aim at a worst frame duration of 33 ms, so we can have a smooth 30 fps at least (currently we can apparently have 50 ms). If more comes out, the better. To gauge the impact of various measures, I'd like to see framerate and worst frame duration readings without tile building going on. So you have to wait after starting Advanced Weather for about a minute till 9 tiles are built and the visibility has reached its target value and all terrain is loaded, then take the readings. If the log option in the GUI is on, the tile building info is written to the console, so you can see when it's over. Also,
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 73, Issue 8
@/Kle: I downloaded the latest Git yesterday, and by enabling Rembrandt through the 'Internal Properties' dialog I get this lovely multicolored result: http://img515.imageshack.us/img515/8468/fgfsscreen133.png It never worked for me here. I always had to decide before to use Rembrandt or not. Also, I cannot activate it anymore by using the '--prop:/sim/rendering/ rembrandt=true' string on .fgfsrc, it can only be done by the 'Internal Properties' dialog inside the Program. Anyone else experiencing this? Said by Frederic in a previous posting: now: /sim/rendering/rembrandt/enabled instead of /sim/rendering/rembrandt before Indeed, I announced it in this thread. Selecting the renderer at runtime won't ever work. You have to put in in the command line or in your .fgfsrc Regards, -Fred I see, my mistake! /sim/rendering/rembrandt/enabled=true was the correct one... No clue about the colors, though... Thanks, will test and give feedback if neccesary All best! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Head-up: several Rembrandt changes
@/Kle: I downloaded the latest Git yesterday, and by enabling Rembrandt through the 'Internal Properties' dialog I get this lovely multicolored result: http://img515.imageshack.us/img515/8468/fgfsscreen133.png It never worked for me here. I always had to decide before to use Rembrandt or not. Also, I cannot activate it anymore by using the '--prop:/sim/rendering/ rembrandt=true' string on .fgfsrc, it can only be done by the 'Internal Properties' dialog inside the Program. Anyone else experiencing this? Said by Frederic in a previous posting: now: /sim/rendering/rembrandt/enabled instead of /sim/rendering/rembrandt before Indeed, I announced it in this thread. Selecting the renderer at runtime won't ever work. You have to put in in the command line or in your .fgfsrc Regards, -Fred I see, my mistake! /sim/rendering/rembrandt/enabled=true was the correct one... No clue about the colors, though... Thanks, will test and give feedback if neccesary All best! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
