Board index FlightGear The FlightGear project

FlightGear 3.2 with B777 running extremely slow

Questions about the FlightGear organisation, website, wiki etc.

FlightGear 3.2 with B777 running extremely slow

Postby mftetsudou38125 » Sat Nov 29, 2014 4:18 pm

Hello. Today I updated the FlightGear and went from 3.0 to 3.2. As I always do, I launched the FlightGear with B777-200 on KSFO, and was surprised by the amount of details and realism added to the plane in the cockpit.

The problem is, the frame rate, it says in the right hand side corner, says it is about 4. When I was using FlightGear 3.0, it used to run at 30fps. It seems like when the airport is in sight, it gets extremely slow, because when I was flying in the middle of nowhere, it got to about 15 fps.

Is there a way to lower the quality of the graphics somehow, so that its at least playable? Or should I downgrade to FlightGear 3.0? To be honest I really don't want to downgrade to 3.0 because once you see the cockpit in 3.2 it's hard to get back.
mftetsudou38125
 
Posts: 71
Joined: Mon Apr 08, 2013 10:18 pm
Location: Yokohama, Japan
Callsign: BAW128
Version: 3.2
OS: OS X

Re: FlightGear 3.2 with B777 running extremely slow

Postby Hooray » Sat Nov 29, 2014 4:50 pm

There's so called "draw-masks" which are property-controlled switches for enabling/disabling rendering of certain scene details, including 1) scenery/terrain, 2) aircraft, 3) models, 4) clouds.
This can be used for troubleshooting performance issues - you can basically toggle individual scene graphs on/off, to see if/how performance is affected.
For example, if performance improves dramatically by disabling the terrain, you are mainly affected scenery complexity.
Equally, disabling the (main) aircraft, will tell you if it's the complexity of the 777 3D model (cockpit).



http://wiki.flightgear.org/Howto:Debugg ... up_profile
our beloved wiki wrote:Beginning with FlightGear 3.1+, you can also toggle individual scenegraph traversal masks on/off (these can be changed at runtime using the Property browser:

--prop:browser=/sim/rendering/draw-mask
--prop:/sim/rendering/draw-mask/terrain=0
--prop:/sim/rendering/draw-mask/aircraft=0
--prop:/sim/rendering/draw-mask/models=0
--prop:/sim/rendering/draw-mask/clouds=0


The other thing worth trying is the so called performance monitor, detailed at: http://wiki.flightgear.org/Howto:Use_the_system_monitor
Image

And finally, there's the OSG on-screen stats telling you if you're GPU or CPU bound: http://wiki.flightgear.org/Howto:Use_th ... reen_stats
Image

I would suggest to report back with your findings, which should help the 777 developers to provide more targeted advice, or at least to optimize a few heavy things (e.g. the cockpit is overly detailed).
For people able to build from source, there's also a built-in profiler available which you can use to post a profile here, showing us exactly where FG spends most of its time when updating the scene: http://wiki.flightgear.org/Built-in_Profiler

This kind of feedback should hopefully help improve the situation.

PS: Obviously, it would have helped to state hardware/software specs, so that we can look up what is reasonable to expect for you performance-wise.

And here's a bit of context information, in case you care:

Subject: New Boeing 777 Seattle download site (git)
Johan G wrote:For all those mentioning the complexity of the 3D cockpit model I would really recommend reading this post on the first page of the topic.

To sum it up: Optimisation is the very last step in I-NEMO's work flow in regard to the model. He will get there when he get there. :wink:


Subject: Blurry and Strange Rendering
Thorsten wrote:We've seen this a few times for very detailed models (I would predict that the b1900d fails as well) trying to be rendered using Intel chipsets. My idea was that the problem occurs when the model itself uses more memory than the GPU has graphical memory available (note that the 777 and the b1900d are large models, I think the b1900d uses more than 300 MB of graphical memory whereas the integrated chipsets often have only 256 MB) - Emilian disagrees however since he has seen these aircraft run on low memory cards and thinks there's a different glitch.

The bottomline is that beyond a certain complexity of the model, the Intel chipsets don't render them any more. One idea we suggested previously was to use an image editing program to shrink the texture sheets of the airplane models to reduce memory consumption and see if that helps.




Subject: NavDisplay & MapStructure discussion (previously via PM)
Hooray wrote:: performance-wise, the standalone map-canvas dialog should also give a good idea about the max performance that can be obtained by the ND code and existing issues (lag), and the standalone ND mode should demonstrate what performance is currently possible without optimizing things further there, i.e. regardless of any aircraft-specific issues like cockpit/texture complexity and aircraft specific Nasal code.


Subject: New Aircraft: the Extra500
Hooray wrote: I think the main issue may not be canvas, but rather a highly-detailed 3D model, with lots of textures and effects, and developers not being aware of the complexity they're adding to the scenegraph due to a lack of integrated tools/diagnostics, which really isn't all that uncommon: highly detailed airliners like the 777-200ER are another good example for this: people are creating great aircraft, but they are no longer aware of the impact this has - FG doesn't currently have any built-in LOD management routines, so there's no texture/mesh simplification taking place - it will try to render what you come up with, no matter how complex it is. Which is exactly why osgviewer/fgviewer are such a great diagnostic tools to help troubleshoot what's going on, because they're unrelated to FG, and are not running Nasal, Canvas and/or effects/shaders



Subject: Stop crashing, fgfs.exe
Hooray wrote:The thing is, that even we -as programmers- do not necessarily understand all the reasons for the increasing number of crashes - sure, many seem to be related to lack of resources (CPU, GPU, RAM, VRAM), but others are clearly related to certain subsystems misbehaving, and their developers not being aware of what's happening under the hood, or even worse: threading issues, i.e. a number of threads running at the same time not being properly synchronized/serialized. These are issues that need to be understood to be solved. And right: debugging and troubleshooting is not as exciting as developing new features.

But first of all, we really need to provide the tools and means to enable non-developers to tell what's going on, i.e. in terms of CPU/GPU/RAM/VRAM resources spent when using certain features, and or aircraft/scenery. We have a number of increasingly complex and well-developed aircraft that are highly popular, such as the 777-200ER for example, but there are quite a few things done inefficiently in some of these aircraft. Likewise, we do have new scenery that's adding more resource usage - and then there's new eye candy features, needing massive amounts of resources. But ultimately, we're lacking the tools to determine what's really happening behind the scenes.
Some of us have been raising this even 2-3 years ago when new features like random buildings made the underlying issues more prominent - but overall, we now have a handful of subsystems that are competing -or even fighting- for resources, without their developers really being aware of what's going on.

So the problem is at least two-fold: New eye-candy features being developed, but also more and more complex modeling and base package development going on (shaders, effects, textures, 3D models). At some point, there's no longer a single culprit to blame, but it's a combination of ill-understood features working in conjunction rendering the simulator basically unusable. Keep in mind that we do have massively popular features like effects or particles, that are known among core developers to be leaking resources (i.e. memory).

Thus, it is too easy to say it's because of certain aircraft (extra500, 777-200) or because of certain features (effects, particles, Nasal, Canvas) - you need to be highly familiar with FG internals to understand what's going on here, and D-LEON has demonstrated that it takes a lot of work and time to end up with useful results.

Basically, we need to expose runtime statistics that monitor resource usages for the main suspects (subsystems) like Nasal, AI traffic, Canvas, but also to monitor scenery/aircraft complexity.

Technically, there's no good reason for FlightGear to crash at all - the main problem is that new -popular- features are added, and that they end up being unmaintained, because their original developers are no longer around, so we are seeing them adopted by non core developers, who are obviously not able to troubleshoot things, and our -few- remaining core developers are obviously overstretched in terms of what they can manage/maintain ob behalf of others - no matter if it's particles, effects or threaded code like the tile manager.


Subject: fg3.0rc1 memory usage
Hooray wrote:Obviously, we can tell people that some feature is "heavy" (such as the 777 for example) and that things need to be optimized (complexity reduced) - but then again, that's just as short-sighted as suggesting that we need to stop using Nasal because we're having GC issues - yes, we can fix certain problems, but we cannot tackle the whole problem - we need a design-level solution that allows to inspect runtime footprint of different features, no matter of it's core code (subsystems, features) or if it's "content" (aircraft/scenery/scripts).

OSG itself has certain mechanisms to help with parts of this, such as tracking osg::ref_ptrs, doing LOD management (aircraft/scenery) - but these tools need to be adopted to be useful, which is currently not the case.

Technically, there's really no reason why FG 4.0 shouldn't perform better on 2006-era hardware than FG 1.0 would - just look at other software like your browser or your operating system - in the case of Linux, you can expect Linux 3.x to perform much better on 2000-era hardware than RedHat 7 ... but currently, our programming model is kinda broken, because we keep adding features without being aware of their footprint - and there's nobody to blame, because we are simply missing the tools that would tell us how expensive a certain feature, aircraft or scenery really is.

I am convinced that having exactly this sort of info available would also help people developing more eye-candy features, because they would much better understand where resources are burnt.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear 3.2 with B777 running extremely slow

Postby mftetsudou38125 » Sat Nov 29, 2014 5:40 pm

Thank you for a very detailed response. I used the draw-mask to mask certain things and saw what Framerate I got.

Code: Select all
With Everything: 5-9
No Aircraft: 15-20
No Clouds:  6-11
No Models:  7-15
Terrain: 20-50


To my surprise, disabling the terrain was the most effective. Also, sorry for not mentioning my specs. I have 22GHz Intel Core i7 with 4GB of memory.

Is this somewhat expected frame rate?
mftetsudou38125
 
Posts: 71
Joined: Mon Apr 08, 2013 10:18 pm
Location: Yokohama, Japan
Callsign: BAW128
Version: 3.2
OS: OS X

Re: FlightGear 3.2 with B777 running extremely slow

Postby Hooray » Sat Nov 29, 2014 5:46 pm

Have you also tried disabling everything completely, i.e. what's your performance like then ?
If in doubt, I'd suggest to test the startup profile detailed at: http://wiki.flightgear.org/Howto:Debugg ... up_profile
This should remove any scenery/aircraft induced performance issues, because there will be only very simple scenery loaded, as well as simple aircraft model.
If performance is still mediocre, then, something else is going on (insufficient driver/hardware support/resources, or an integrated GPU handling all the work).

Also, Rembrandt/deferred rendering must be disabled obviously, if in doubt, refer to the property tree to ensure that --disable-rembrandt is effective


PS: any GPU / graphics card info (make/model, VRAM) - you can use the HELP/ABOUT dialog to post this info?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am


Return to The FlightGear project

Who is online

Users browsing this forum: No registered users and 1 guest