Why is FlightGear not using more computing power?

Question

I recently downloaded FlightGear as I felt like playing a flight simulation game. I am using Windows 10 and am running into a framerate problem.

The game does never goes above 25 fps and sometimes has 80ms of frame delay but, as you can see in the following image which describes my CPU, GPU and memory usage (this is Process Hacker data, so I am quite confident about it), I still have more than 5GB of available RAM and CPU/GPU usage hardly goes above 20%...

Furthermore, my PC runs very well all the recent games at a steady 60fps, being equipped with an Intel Core I7 3770K and a nice Nvidia GTX780TI, with 16GB RAM. My video drivers (and basically all drivers) are up to date.

I admit I maxed out every single setting I could on the simulator, I will post a link in a comment where you can download my preferences.xml file (I actually am limited by rep). The only changes I did manually is allowing multithreading (by uncommenting one line, and it didn't affect performances), everything else was maxed out in the game itself. I also double-checked I didn't limit the framerate to something lower than 60FPS, my screen framerate.

Why is the game not using more computing power in order to have a smooth game experience as my computer is fully capable of doing so ?

I also checked my graphics card is supported by the game, and, well it is : It is written "NVIDIA Corporation GeForce GTX 780 TI/PCIe/SSE2" in the "Help" tab, and is not mentionned in the "Problematic video cards" page of the game wiki. As I am running the game in windows, it is not possible for me to compile it in order to use the built-in profiler which uses google perf tools, unfortunately :-(

Let me know if I can give more information in order to have this problem fixed. This may help many people running into the same problem. Thank you.

Second screen showing OSG detailed statistics

Answer 1

If it appears that FlightGear isn't using all of the resources it's probably because of an inbalance between the CPU and GPU. Certain operations can become CPU limited, and others GPU limited.

From the screenshot the first observation is that the internal process monitoring is active; this will have a significant effect on the framerate.

The GUI in FlightGear is built using the PUI - which will affect the framerate when you have dialogs on display; especially dialogs that are updated frequently as the PUI isn't that efficient. There is an understanding that the PUI needs to be replaced, but as yet I don't think anyone is working on it.

Use Debug->Cycle on screen statistics to turn on the OpenSceneGraph frame rate counter. You may need to use F10 to hide the menu bar so it is visible as it displays in the top left. This is much more efficient than the PUI based monitor in the screneshot.

There are a 3 rendering engines within FlightGear; basic, ALS and Rembrendt.

I find that ALS (Atmospheric Light Scattering from the View->Rendering Options) will provide the best balance between a good looking scene and a reasonable framerate.

If you have random vegetation slider set to the maximum this will probably result in too much geometry to render. So stick with values of around 3.5 for this and gradually tune this upwards until there is a balance between trees and a good framerate.

If you're using the Rembrandt (deferred rendering that is still officially experimental) then you get emissive lighting and the option of shadows, bloom around light points, but this requires multiple passes over the geometry and will be slower than ALS - but the sunlight model is rather simplistic and ALS is generally better IMO.

Also you get better clouds by using detailed weather that needs to be turned on every time.

Whilst it might seem appealing to simply max out all of the sliders because you've got a high end system- with all respect that's not really why they're there. The sliders are there to allow tuning of the available rendering options to get a balance between framerate and features.

Also 3.6RC and the upcoming 3.8 or 2016 release has reduced memory usage which results in better performance.

It's a shame that 3.6 didn't get released in August (due to lack of manpower) as it is quite an improvement especially with the ALS cockpit and glass effects.

The currently nightly build may be stable; it's worth downloading these and trying them until you get one that is good. If it's no good then the 3.6RC is worth a try.

So as often firstly find out what is the bottleneck (CPU/GPU) and tune accordingly. The OSG on screen statistics can be useful to diagnose this together with system monitoring tools to understand the GPU and CPU usage.

FlightGear currently takes some advantage of multi-core systems; work is under way to improve this - but that's not really going to fix the case where a single core is maxed out feeding the GPU; or when the GPU is maxed out with geometry as pretty much with OpenGL there is only so much that can be achieved by multithreading.

If you look at the picture below you can see that the cyan bars are happening at the same time. This is OSG multithreading. FlightGear (with non deferred rendering) uses two cameras (near and far) - so there is a benefit from OSG multithreading. However you will also notice that my frame rate (i7 2600, R9 290) is only 30 something.

When sitting at KLSV in the cockpit with reasonable rendering settings I'm at 30 to 35 FPS. If I look at the sky (where there is much less geometry) I get 80 FPS.

Referring to your screenshot of the detailed statistics; the two parallel culls tells us that OSG is multithreading; but the GPU times are quite long, even with 104million vertices. So it looks like the GPU is holding things up - which seems odd with your cards. Maybe check the NVidia settings and ensure that everyone looks sensible.

At places where there is high scenery density the random vegetation will add considerable extra load; but even so a decent CPU/GPU combination should be able to handle 3.5.

Try other airports; there's the whole world to visit. ZUBD is quite fun.