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. They're probably mostly style rather than substance, but on the other hand every little helps. I'll go on fixing them and see if it makes any difference. I'm still hopeful that we will get a better GC. Vivian ------------------------------------------------------------------------------ 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
