422
edits
Howto:Use the system monitor: Difference between revisions
Jump to navigation
Jump to search
Howto:Use the system monitor (view source)
Revision as of 13:10, 22 February 2014
, 22 February 2014→Interpreting the OSG on screen stats: - clarify Draw impact
m (→Interpreting the OSG on screen stats: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35917.html) |
(→Interpreting the OSG on screen stats: - clarify Draw impact) |
||
| Line 136: | Line 136: | ||
* Update: cpu processing your application is performing | * Update: cpu processing your application is performing | ||
* Cull: cpu processing performed by osg in traversing the scene graph and packaging drawing state | * Cull: cpu processing performed by osg in traversing the scene graph and packaging drawing state | ||
* Draw: cpu processing for sending drawing state to gpu and gpu processing | * Draw: cpu processing for sending drawing state to gpu and gpu processing of the drawing state | ||
of the drawing state | |||
If Update stage is large, you need to determine what part of your application is taking the time and optimize it. | If '''Update''' stage is large, you need to determine what part of your application is taking the time and optimize it. | ||
If Cull stage is large the scene hierarchy is too complex and needs to be optimized - spatial optimization, flatten static hierarchies, ... | If '''Cull''' stage is large the scene hierarchy is too complex and needs to be optimized - spatial optimization, flatten static hierarchies, ... | ||
If Draw stage is large then you need to determine if you are vertex or pixel limited. If you grab the window corner and shrink/expand it's size | If '''Draw''' stage is large then you need to determine if you are drawable/vertex or pixel limited. If you grab the window corner and shrink/expand it's size | ||
and the performance increases/decreases significantly, then you are pixel/fill limited (too much depth complexity/too much pixel processing). | and the performance increases/decreases significantly, then you are pixel/fill limited (too much depth complexity/too much pixel processing). | ||
If the performance doesn't change then you are | If the performance doesn't change then the most likely cause is scene complexity at the object level, '''drawables''' in the osg stats table. This has a far greater impact on Draw (and as stated above on Cull) than the number of vertices in the scene. This impact is such that a scene with '''double the vertex number''', but '''half the drawable number''' of a '''less detailed scene''' renders '''faster'''. This is caused by the fact that for sending each '''drawable''' the OpenGL state machine needs to be reset. Vertex number start having an impact only for extreme values (this doesn't mean you should ignore the possible performance impact caused by them) | ||
''In short, if you want to improve the detail of a scene without causing a big performance drop, make sure you have as little detailed object-material(texture) pairs as needed. Ideally you would merge all meshes that are opaque, share the same material, and are not animated into a single mesh and if needed use a single texture, same for transparent mesh parts that are not animated (they should be split from opaque parts), leaving as individual meshes only those parts that will have animations attached'' | |||
It's actually much more complex than this, but it's how you can start diagnosing performance issues. | It's actually much more complex than this, but it's how you can start diagnosing performance issues. | ||