Howto:Troubleshooting Aircraft Performance Issues
|This article is a stub. You can help the wiki by|
| Note In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).
While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible.
We are seeing more and more complex aircraft/features developed by aircraft developers, with non-obvious impact on overall FlightGear performance. Many aircraft developers don't fully understand how to draw correct conclusions from interpreting their findings, i.e. if performance issues are related to the FDM, texturing/3D model complexity or other aspects like systems simulation (e.g. Nasal).
|Someone who uses 4096x4096 texture sheets for aircraft usually knows pretty darn well that they cost lots of resources. He just thinks that that's how he wants to spend resources.
Document the main steps to understand performance issues at the aircraft level, i.e. FDM, 3D modeling, texturing and Nasal scripting.
|you can use the osg-stats and use osgviewer/fgviewer in standalone mode to draw your own conclusions
|you can only draw reliable conclusions once you do multiple tests doing different settings/configurations, which includes all tools at your disposal - including different model viewers like osgviewer/fgviewer.
|in conjunction with viewing the model in osgviewer, fgviewer and fgfs using different settings, we can draw reliable conclusions.
We will be testing different components, and features, of each aircraft in isolation, to exclude certain factors and determine if/how performance is affected by certain features.
For instance, when loading an aircraft in osgviewer, we can basically determine the maximal theoretical rendering speed that can be obtained (flightgear using osgviewer internally), without adding any flightgear specific subsystems/overhead (e.g. no scenery/terrain).
Equally, when running a FDM in standalone mode, we can look at the FDM overhead without graphics and/or scripting playing any role.
And once we load the same aircraft in fgviewer, we can look at it without Nasal playing any role.
|We do have some fairly heavy/complex models, some unnecessarily so - i.e. in areas that add little to the overall realism (e.g. 777 or extra500).To see for yourself, you could dump the scene graph to a file using the debug menu, and inspect the whole thing in osgviewer. Which is also a good way to see how much of this is due to FlightGear itself.To see the impact of your model in relation to scenery/terrain etc, you can use the draw masks /sim/rendering/draw-masks and the minimal startup profile: Troubleshooting crashes#Minimal startup profileTo see the impact of enabling/disabling Rembrandt, you would obviously have to re-do the test accordingly.But overall, this should give you a fairly good idea for your hardware, especially in conjunction with using the osg stats: Howto:Use the system monitor#Interpreting the OSG on screen stats
The main metrics will be osg-stats (link) and frame rate/frame spacing when in FG, as well as ogging performance monitor metrics (link)
We will be using aircraft that were tested on the forum, especially:
- Su-15 vs. F15
osgviewer is the basic tool that you should use to measure performance of a 3d model, it comes with compiling Openscenegraph with the -DBUILD_OSG_APPLICATIONS option, it provides the basic OSG stats interface, FPS/Cull/Draw being the most important ones for the ultimate bearing load of your model on your machine.
If you want to compare models, for consistency, it is better to use a static camera view(default camera angle/pov is fine), with the wire-frame option enabled to measure the Draw for both visible and hidden faces, wait for a perfect moment and press 'c' to capture the screenshot. Also it is helpful to watch metrics as you disable/enable textures.
|1||Select 'Trackball' camera manipulator (default)|
|2||Select 'Flight' camera manipulator|
|3||Select 'Drive' camera manipulator|
|4||Select 'Terrain' camera manipulator|
|5||Select 'UFO' camera manipulator|
|Drive: Space||Reset the viewing position to home panel hotspots|
|Drive: a||Use mouse middle,right mouse buttons for speed|
|Drive: q||Use mouse y for controlling speed|
|Escape||Exit the application|
|Flight: Space||Reset the viewing position to home|
|Flight: a||No yaw when banked|
|Flight: q||Automatically yaw when banked (default)|
|Trackball: +||When in stereo, increase the fusion distance|
|Trackball: -||When in stereo, reduse the fusion distance|
|Trackball: Space||Reset the viewing position to home|
|Z||If recording camera path stop recording camera path, save to "saved_animation.path"|
|b||Toggle backface culling|
|c||Take screenshot and write to file.|
|v||Toggle block and vsync|
|w||Toggle polygon fill mode between fill, line (wire frame) and points|
|z||Start recording camera path.|
This tool is the easiest because you don't need to have osg binaries compiled, just navigate to where you installed Flightgear to find it, it is based on osgviewer but with some Simgear integration, it is not sophisticated and i don't think you can allow it to display aircraft and scenery together, use it as you would osgviewer, except you have to define FGROOT before using it.
C:\Users\JonDue> "C:\Program Files\Flightgear 3.7.0\bin\fgviewer" C:\Location\Of\Aircraft\Model.ac
vblank_mode=0 ./fgviewer ~/build/fgbuild/install/flightgear/fgdata/Aircraft/ufo/Models/ufo.ac
Minimal startup profile
Using draw masks
See Fgtape for the main article about this subject.