> 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. 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. > 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. > 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) 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. 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? * Thorsten ------------------------------------------------------------------------------ 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
