Howto:Use the system monitor: Difference between revisions

Jump to navigation Jump to search
m
Line 148: Line 148:
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
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 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)  
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 (millions of vertices; this however 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