Howto:Use the system monitor: Difference between revisions

Jump to navigation Jump to search
Line 142: Line 142:
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 drawable/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 geometry (drawable or 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 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)  
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 count''', but '''half the drawable count''' 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 count starts having an impact only for extreme values (this doesn't mean you should ignore the possible performance impact caused by it)  


''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''
''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''
422

edits

Navigation menu