Board index FlightGear Development Aircraft

New Aircraft: the Extra500

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

Re: New Aircraft: the Extra500

Postby Kabuki » Sat Feb 22, 2014 2:12 am

D-Leon wrote in Thu Feb 20, 2014 8:48 pm:hard to see the discussion "Performance of Flightgear" on the neck of the extra500.

To get more clarity where the performance goes and specially for pilots who can't fly it now.
I will provide a startup switch to disable the IFD's. Hopefully this weekend.
Therfore is some work needed that the autopilot can be controlled via the keypad without the IFD's.

Dirk


I simply went into the property manager and turned off /sim/current-view/internal and used a HUD. It was flyable then.

It seems a shame that such a beautiful MFD is the framerate eater. ALL planes get better framerates in the external view, but it might be possible to
configure it with "steam gauges", but it would be a shame not to use that beaaaauuuuutiful MFD.

Oh, the dilemma!
This is a family-friendly saloon. No talk stink.
Kabuki
 
Posts: 587
Joined: Fri Oct 23, 2009 11:21 pm
Location: Usually on the ground, always in the sky, except when underwater.
Callsign: Kabuki
Version: 3.0.0
OS: Windows 7

Re: New Aircraft: the Extra500

Postby Hooray » Sat Feb 22, 2014 2:32 am

This is not just because of Canvas or the MFD, see the stats I posted - model/cockpit complexity is definitely a factor, as is the resolution of the two canvas regions, but also the way things are updated - so there's some room left for optimizing things, no need to replace the MFD!

Like I said previously, use osgviewer to determine the impact of the model itself, comment out the canvas/Nasal stuff to see how things perform without Nasal/Canvas and then do some profiling.
The aircraft is awesome, no need to worry - it's just doing some things inefficiently at the moment, but that's not impossible to solve.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby D-Leon » Sat Feb 22, 2014 12:46 pm

Thx for all your feedback,

I just finished a commit to strip the plane into its rendering pieces, disable the canvas IFD's and change the IFD resolution.
All put in a Dialog.

https://gitorious.org/extra500/extra500
branch "debug_fps"

Im not sure about the results. The most effect I get when disable the rendering of the IFD's. Or changeing the resolution of the IFD's.

@Hooray : thx for your hints. I compiled the built-in profiler and make some first tests. On the canvas calls i can't see any peaks, but the "_nv019glcore" ,especially "_nv005glcore" seems higher than in other aircrafts.
I don't exactly know what this means but it sounds for me like our "overall rendering" is too much.

"model/cockpit complexity is definitely a factor" thats the point - and we will investigate there, to reduce our vertex count.
D-Leon
 
Posts: 28
Joined: Wed Oct 03, 2012 8:44 am
Callsign: D-Leon
OS: Linux

Re: New Aircraft: the Extra500

Postby Hooray » Sat Feb 22, 2014 1:39 pm

those are nvidia driver calls, i.e. used by OpenGL/OSG - but that's much too low level, it would be better to use an OpenGL debugger, that should tell you what's going on. For starters, you can also dump the scenegraph and inspect it afterwards (see the debug menu)

You could also modify simgear to add two properties for enabling/disabling cockpit/scenery rendering, so that you can better tell what's going on by keeping scenery disabled for example.

PS: Thanks for doing all the tedious work here, I realize it must have been frustrating, but it would surely help us better understand what's going. Overall, it helps to make use of LOD animations, but also to provide switches to make certain things optional at runtime, such as i.e. hiding the canvas or using lower-res textures to see if that has any impact. For starters, I would ignore FG completely and try to load those 3D models via osgviewer and see what's going there performance-wise - only once standalone osgviewer provides good performannce, should you consider optimizing the FG side of things. We've also started to extend the "system monitor" article in the wiki, which should provide some more pointers.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Thorsten » Sat Feb 22, 2014 3:55 pm

You could also modify simgear to add two properties for enabling/disabling cockpit/scenery rendering, so that you can better tell what's going on by keeping scenery disabled for example.


Oh, for god's sake, don't make it complicated. Just set /sim/rendering/camera-group/zfar to a low distance and the scenery will be gone because it's all outside the far camera clipping distance...
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: New Aircraft: the Extra500

Postby Hooray » Sat Feb 22, 2014 4:01 pm

indeed, that would seem like a sensible workaround - maybe I was too much focused on the original draw-otw property :-)
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Hooray » Sun Feb 23, 2014 10:50 pm

don't exactly know what this means but it sounds for me like our "overall rendering" is too much.
"model/cockpit complexity is definitely a factor" thats the point - and we will investigate there, to reduce our vertex count.


The built-in osgviewer stats can be extended with custom stats, that works by subclassing osg::StatsHandler, this is already done in $FG_SRC/Viewer/FGEventHandler.?xx
The class can be extended to add your own stats via osgViewer::StatsHandler::addUserStatsLine()

You can even register totally custom stats via osg::Stats

The main suspects in this case are probably 1) scenery, 2) cockpit, 3) Nasal (GC - bottleneck() function in simgear/nasal )
For the Nasal stats, you'll probably want to register them in FGNasalSys::FGNasalSys() by accessing globals->viewer->
That should give you a better idea about what's going on there, and it's been suggested by core developers, too:

http://www.mail-archive.com/flightgear- ... 37823.html
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.
Last edited by Hooray on Mon Feb 24, 2014 2:09 pm, edited 1 time in total.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby alfagolf » Mon Feb 24, 2014 12:47 am

Great add-on!!!

Just a little bit FPS intensive
alfagolf
 
Posts: 16
Joined: Thu Feb 20, 2014 10:08 am

Re: New Aircraft: the Extra500

Postby D-Leon » Mon Feb 24, 2014 5:28 pm

Updated the debug dialog with a Hz slider for the nasal loops which drive the canvas IFD's. Now adjustable from 1-60Hz.

I although dcimate the 3D Objects. Kicked 8 MB Vertices out of the extar500.

branches :
debug_fps
debug_fps_dcimate = lower 3D Objects

I thought this has a bit more effect. I can't really gain more fps through the less detailed objects.
D-Leon
 
Posts: 28
Joined: Wed Oct 03, 2012 8:44 am
Callsign: D-Leon
OS: Linux

Re: New Aircraft: the Extra500

Postby Thorsten » Mon Feb 24, 2014 6:45 pm

I thought this has a bit more effect. I can't really gain more fps through the less detailed objects.


It depends on what the bottleneck is. A modern GPU can crunch through an amazing lot of vertices, especially if they're part of a single draw. But if the bottleneck isn't in the vertex shader (as I am fairly certain it isn't on my box), then reducing vertex count won't help.

That doesn't mean that the vertex shader couldn't possibly be the bottleneck for others. Also, as you show more terrain and clouds, the vertex pipeline starts filling rapidly.

Still doesn't tell us what the bottleneck is, but unfortunately I'm a bit busy with other stuff, so I can't really dig into this further right now.
Thorsten
 
Posts: 10740
Joined: Mon Nov 02, 2009 8:33 am

Re: New Aircraft: the Extra500

Postby D-Leon » Tue Feb 25, 2014 6:57 pm

I think the bottleneck depends on the canvas rendering.
The PFD screen which has the most amount of elements doubles my rendering time in the osg-graph.
More less screens like the FMS page and the CHKL page which has no elements, directly increase my fps.

Counting the visible elements in the property tree of these pages:

Code: Select all
[b]PFD:[/b]
alignment:72, background:1, bottom:1, bounding-box:431, center:1074, center-offset-x:98, center-offset-y:81, character-size:72, clip:6, cmd:5088, coord:21368, file:1, fill:425, font:72, group:115, hdg:1, id:545, image:1, line-height:72, m:4620, m-geo:2, map:1, max-x:431, max-y:431, min-x:431, min-y:431, mipmapping:1, name:1, node:1, normalized:1, path:356, placement:1, range:1, ref-lat:1, ref-lon:1, right:1, size:4, source:1, status:1, status-msg:2, stroke:356, stroke-dasharray:104, stroke-linecap:102, stroke-width:356, text:148, tf:770, tf-rot-index:537, update:538, view:2, visible:11, z-index:4

[b]FMS:[/b]
alignment:59, background:1, bounding-box:103, center:296, character-size:59, clip:2, cmd:298, coord:693, fill:99, font:59, group:52, hdg:1, id:155, line-height:59, m:1554, m-geo:2, map:1, max-x:103, max-y:103, min-x:103, min-y:103, mipmapping:1, name:1, node:1, path:41, placement:1, range:1, ref-lat:1, ref-lon:1, size:2, status:1, status-msg:2, stroke:41, stroke-dasharray:29, stroke-linecap:32, stroke-width:41, text:124, tf:259, tf-rot-index:150, update:150, view:2, visible:13, z-index:8

[b]CHKL:[/b]
background:1, group:1, mipmapping:1, name:1, node:1, path:0, placement:1, size:2, status:1, status-msg:2, text:0, view:2, z-index:1

          PFD    FMS    CHKL
id:       545    155      0
group:    115     52      1
path:     356     41      0
text:     148    124      0
tf:       770    259      0
cmd:     5088    298      0
coord:  21368    693      0



All Element count of the hole IFD
Code: Select all
alignment:200, background:1, bottom:1, bounding-box:560, center:1844, center-offset-x:102, center-offset-y:89, character-size:200, clip:13, cmd:8197, coord:33642, file:1, fill:694, font:200, group:239, hdg:1, id:939, image:1, line-height:200, m:8628, m-geo:2, map:2, max-x:560, max-y:560, min-x:560, min-y:560, mipmapping:1, name:1, node:1, normalized:1, path:498, placement:1, range:2, ref-lat:1, ref-lon:1, right:1, size:4, source:1, status:1, status-msg:2, stroke:498, stroke-dasharray:201, stroke-linecap:206, stroke-width:498, text:402, tf:1438, tf-rot-index:924, update:925, view:2, visible:65, z-index:5

        All elements
id:        939
group:     239
path:      498
text:      402
tf:       1439
cmd:      8197
coord:   33642



This is although reproduce able in a naked plane with a canvas stress test window with 1200 dme icons as path.

Code: Select all
blend-destination-alpha:1, blend-destination-rgb:1, blend-source-alpha:1, blend-source-rgb:1, bounding-box:1201, cmd:16814, coord:27623, group:2, id:1, m:7206, max-x:1201, max-y:1201, min-x:1201, min-y:1201, path:1201, placement:1, size:2, status:1, status-msg:2, stroke:1201, stroke-width:1201, text:0, tf:1201, type:1, view:2,

id:          1
group:       2
path:     1201
text:        0
tf:       1201
cmd:     16814
coord:   27623


lowering the nasal loop Hz show that the rendering is only affected on changes to the canvas.

Become groups without changes also redrawn?
Is there any way to exclude static elements from rendering?
Is it efficient to replace static elements with images?
How efficient is it to put the static elements in a background canvas and create child canvas on top which carry the animation?
D-Leon
 
Posts: 28
Joined: Wed Oct 03, 2012 8:44 am
Callsign: D-Leon
OS: Linux

Re: New Aircraft: the Extra500

Postby Hooray » Tue Feb 25, 2014 7:17 pm

this is interesting, but you should really check out Gijs' ND code or Philosopher's MapStructure framework: they both solve some of these problems already, and it would make sense to centralize any future optimizations there, whenever we cannot optimize something purely from scripting space, we can still look into C++ changes, TheTom has been really responsive with regard to performance requirements and missing features.

you posed some interesting questions, but most of them you can answer by adding 2-3 buttons to your "fps debug" dialog that a) use removeAllChildren() to empty certain groups via a combo box , 2) that disable/delete a whole canvas, to see if that improves your framerate.

As I previously mentioned, there are some things going on -according to the google-perftools profile- that would seem to suggest that lots of unnecessary updates are made, as in paths being updated (and thus, redrawn) that have not changed. Whenever you write something into a group, it will be marked as "dirty" (in the OSG/GL sense), and so it will be updated.

I really suggest not to micro-optimize a single aircraft here.
But you can also extend CanvasElement.cxx and add two SGTimeStamp::now() calls to see how much time is spent updating each element, you will want to write that to an element-specific property to inspect things at runtime. However, our ND/MapStructure based instruments seem to be much more "dynamic" than yours currently, and we're not seeing any significant performance issues that we don't understand since we adopted MapStructure for most layers - remaining lag can be mostly attributed to "legacy" layers making use of the removeAllChildren() pattern, which is known to be problematic for understandable reasons.
But not even the ND code is particularly optimized currently - it using a single "aggressive" timer that re-runs all updates at least once per frame - just dynamic elements (mapping stuff) are handled by MapStructure and delta-positioned queries.

I suggest to first of all check how often you're really updating your canvases/groups - if there are no surprising updates being done, I suggest to check if disabling (group.hide()) helps solve the problem, otherwise you can also purge groups using group.removeAllChildren().

But overall, you'll really want to team up with us, instead of micro-optimizing something that we've been -successfully- working for several months already :D

Besides, whenever an instruments has multiple instances, MapStructure's SymbolCache approach to reduce canvas overhead is likely to come in extremely handy.
We can help you port things to see if the issues remain or not. In the meantime you may want to check out the 747/777 to see for yourself if things are sufficiently fast there.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Hooray » Thu Mar 06, 2014 10:39 pm

This should basically allow disabling most callbacks triggered via callbacks (timers/listeners), and is really only intended to help with troubleshooting. FGNasalSys::update() will still be called (including embedded Nasal portions in XML files etc), but otherwise Nasal overhead should be fairly small (and consequently, FG itself hardly usable):
--prop:/sim/nasal/disable-listeners=1 (props.nas is not wrapped)
--prop:/sim/nasal/disable-timers=1
Code: Select all
diff --git a/src/Scripting/NasalSys.cxx b/src/Scripting/NasalSys.cxx
index b2f08fe..ca58888 100644
--- a/src/Scripting/NasalSys.cxx
+++ b/src/Scripting/NasalSys.cxx
@@ -449,12 +449,15 @@ static naRef f_fgcommand(naContext c, naRef me, int argc, naRef* args)
 // FGNasalSys::setTimer().  See there for docs.
 static naRef f_settimer(naContext c, naRef me, int argc, naRef* args)
 {
+
+    if (fgGetBool("/sim/nasal/disable-timers",0)) return naNil();
     nasalSys->setTimer(c, argc, args);
     return naNil();
 }
 
 static naRef f_makeTimer(naContext c, naRef me, int argc, naRef* args)
 {
+  if (fgGetBool("/sim/nasal/disable-timers",0)) return naNil();
   if (!naIsNum(args[0])) {
     naRuntimeError(c, "bad interval argument to maketimer");
   }
@@ -474,7 +477,8 @@ static naRef f_makeTimer(naContext c, naRef me, int argc, naRef* args)
 // setlistener(func, property, bool) extension function.  Falls through to
 // FGNasalSys::setListener().  See there for docs.
 static naRef f_setlistener(naContext c, naRef me, int argc, naRef* args)
-{
+{ 
+    if (fgGetBool("/sim/nasal/disable-listener",0)) return naNil();
     return nasalSys->setListener(c, argc, args);
 }
 

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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: New Aircraft: the Extra500

Postby Kabuki » Fri Mar 07, 2014 7:30 pm

I tried turning off te MFD, and my framerate went from 3 FPS to 18 FPS.

I mean I just pushed a button on the panel. :)
This is a family-friendly saloon. No talk stink.
Kabuki
 
Posts: 587
Joined: Fri Oct 23, 2009 11:21 pm
Location: Usually on the ground, always in the sky, except when underwater.
Callsign: Kabuki
Version: 3.0.0
OS: Windows 7

Re: New Aircraft: the Extra500

Postby Hooray » Fri Mar 07, 2014 8:04 pm

We're currently exploring what's having the most impact here and trying to make things increasingly configurable.
Unfortunately, this currently need to be done individually for each aircraft, because we don't have any tools to "look under the hood" to see where/why things are slow, so it may take a while.
But I am confident that most of these issues can/will be solved in time for 3.2 once we fully understand what's going on, which should also help optimize other complex aircraft, like the 777-200.
Note that these are not all automatically Nasal/Canvas related, I have patched one branch that basically disables most Nasal/Canvas, and frame rate/frame spacing are still not too impressive, because there's lost of other stuff going on within the main loop that's slowing things down heavily.
Nasal & Canvas are just "tools", and like any tools, they can be mis-used so that they contribute to bad performance - but properly written Nasal/Canvas code should have negligible impact on performance, I think Philosopher's MapStructure framework has demonstrated that writing well-performing Nasal/Canvas code is indeed possible. Now things just need to be adopted by other aircraft and frameworks, including Gijs' NavDisplay, which still makes use of several "slow" (inefficient) coding patterns.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 8 guests