Howto talk:Troubleshooting Aircraft Performance Issues

K.I.S.S method to measure Nasal impact on framerate :)

Let me know if you'd like me to include the example of Nasal impact of F15 with Draw-masks off for Model, with/without Nasal file, as a method for measuring impact in a K.I.S.S way. -- Hamzaalloush (talk) 21:06, 14 November 2015 (EST)

yes, sure - renaming/deleting a folder and/or editing the -set.xml is a good and quick way to accomplish that. But I think it would be better that we patch up $FG_SRC/Scripting/NasalSys.cxx to explicitly disable embedded Nasal code in aircraft files, which is 3-5 lines of code and straightforward to do - while it would "cripple" aircraft, it would help tell people what is going on (and what isn't).--Hooray (talk) 07:52, 15 November 2015 (EST)

developer benchmarking tool-chain

I just had an idea, how about we customize the fgviewer to automate making a "score" for aircraft so that we compare them together? -- Hamzaalloush (talk) 21:22, 14 November 2015 (EST)

I do like the idea, but I think it would be better to patch up fgfs to make more features optional (via properties), analogous to the Draw masks, so that fgfs itself could be used accordigly. We also decided that this would be more promising for the "fgcanvas" effort.

To see for yourself, you could view an arbitrary 3D model in osgviewer, compare that to fgviewer (osg) and then compare that with displaying the same model in fgfs using the minimal startup profile.

Obviously, fgfs is going to be heavier than osgviewer/fgviewer respectively, but it would not be too much work to make other features/subsystems entirely optional to turn fgfs itself into a useful diagnostics tool. That could either be a dedicated "developer mode" or just many more relevant diagnostics exposed via the property tree, and made accessible/configurable through it. So that these things could show up during startup.

My main line of reasoning here is that "scoring" is always going to be highly subjective otherwise (see our scoring system on the wiki), so that I would only want to "score" aircraft components in terms of overall performance impact, i.e. using a bare evnironment (analogous to osgviewer) and re-enabling other features to tell how much /relative/ impact these features have in combination. That way, we could come up with numbers like "maximal framerate" and "minimal frame spacing" and quantify that using different aircraft models/airports (locations/scenery).

So that scoring would only ever deal with a percentage in terms of "performance degradation". I think, that would be a much more objective, and positive, metric. And as long as people "score" different aircraft, they can also draw conclusions about the relative impact of an aircraft.

From a rendering standpoint that is easy to do using these "draw masks" (see below), in fact, I did post a patch on the forum to entirely disable PUI using a custom "old-gui" draw-mask[1]. From a main loop standpoint, we just need to make even more subsystems optional, which is in line with Reset & re-init. All this with the added advantage, that this would be built right into fgfs, i.e. everybody could run/use this much more easily. --Hooray (talk) 07:49, 15 November 2015 (EST)

Property browser with Draw masks shown

Another goal is to add more node bits (and a GUI dialog to control them) so various categories of objects can be disabled during the update pass. This will mean the direct hit of, say, AI models vs particles vs random trees can be measured. Of course it won't account for resources (memory, textures) burned by such things, but would still help different people identify slowness on their setups. — James Turner (Jul 19th, 2012). Re: [Flightgear-devel] Rendering passes question. (powered by Instant-Cquotes)