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.
|
Objective
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.
|
|
|
osgviewer is a good way to exclude FDM, Nasal and Canvas altogether - so it provides an excellent baselineAnd that is not specific to the Su15, you could just as well do the same tests with the 777 or the extra500, and anybody interested in understanding FG performance issues, is well-advised to use such tests to determine if, how and where certain features are contributing to those
|
|
Approach
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.
Metrics
The main metrics will be osg-stats (link) and frame rate/frame spacing when in FG, as well as ogging performance monitor metrics (link)
Understanding framerate
|
What drags framerate is the number of model vertices in the view frustrum. When you don't look at the larger part of the cockpit because you're essentially looking out of the window with little of the plane in view, you get decent framerate. When you have the lower part of the cockpit and the forward part of the plane in view, you get lower framerate. When you have most of the model in view, you get lowest framerate.Doesn't really matter whether you actually see so much of the plane - vertices blocked by opaque surfaces still count in this game. Even if you see an instrument, the nose wheel a few meters before it will still kill your framerate even if you can't see it.
|
|
Use Cases
We will be using aircraft that were tested on the forum, especially:
- Su-15 vs. F15
- extra500
- 777-2000
standalone FDM
|
usually, the FDM accounts only for a fraction of the execution time over the overall time spent creating the frame, and given the complexity of the 3D model and textures, I would assume that quite some time is spent rendering, not updating FDM state. To see for yourself, you can open the performance-monitor, and post a screen shot here - next, do the same thing with the osg-on-screen stats.If in doubt, JSBSim also provides a way to run in standalone mode, you can basically run a 2 hr flight within a few minutes, and watch the whole thing using a task monitor (top/htop on Linux).This should tell you immediately if you are FDM-bound (which really is a fancy term for saying that you'd be CPU-bound), which seems unlikely as far as I can see.
|
|
osgviewer
fgviewer
Disabling Nasal
Minimal startup profile
Using draw masks
|
people with very powerful hardware who are still getting only ~30 fps may want to hide the aircraft using /sim/rendering/draw-masks to see for themselves how much of an impact the 3D model/texturing vs. scenery/clouds etc has, note that this will not have any effect on running Nasal code
|
|
Core Development
|
Those osg stats should really be dumped to the console during startup, maybe just the aircraft-specific branch, i.e. separated scenery/aircraft to write into the log file how complex an aircraft/airport (location) really is/was.I really believe that this is a useful metric, and the approach could also be suited to understand other issues, i.e. rendering a minimal view of a scene and removing/adding different elements using draw-mass to see if/how they impact overall scene complexity and performance.This would probably also help us understand Rembrandt issues, and it would allow us to identify opportunities for optimiing Canvas further - e.g. by allowing such stats to be gathered "per-canvas" (texture), querying the whole sub-graph for the corresponding cam, which is possible using existing osg APIs)In fact, aircraft/airport complexity I would even log to the splash screen right away, to provide some data to aircraft developers
|
|