20,741
edits
m (cat: Category:Troubleshooting -> Category:Scenery enhancement (should go into "optimization" or something)) |
|||
Line 75: | Line 75: | ||
You can also try to play with osg's frame statistics, you can switch that on from the debug menu. | You can also try to play with osg's frame statistics, you can switch that on from the debug menu. | ||
Being CPU and draw limited means the yellow bar is long. And the blue one grows when cull happens | {{FGCquote | ||
to be a problem. | |The stats in "camera" table are for objects that have survived culling and<br/> | ||
are passed on to OpenGL. Vertices should be the sum of all the vertices<br/> | |||
contained in the primitives. I believe that "triangles" refers to the total<br/> | |||
number of triangles and not triangle sets.<br/> | |||
<br/> | |||
The table on the right contains stats for the whole scene graph that is<br/> | |||
paged in. It is expensive to gather those statistics; you may notice a<br/> | |||
slowdown when you enable them. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33042445/ | |||
|title=<nowiki>Re: [Flightgear-devel] Building of framerate doom</nowiki> | |||
|author=<nowiki>Tim Moore</nowiki> | |||
|date=<nowiki>2014-11-15</nowiki> | |||
}} | |||
}} | |||
Being CPU and draw limited means the yellow bar is long. And the blue one grows when cull happens to be a problem. | |||
A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu. | A simple help is to switch on the onscreen stats in the viewer or flightgear and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu. | ||
Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease! | Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease! | ||
Line 85: | Line 101: | ||
How to achieve that is a very long chain of right decisions. Starting with the | How to achieve that is a very long chain of right decisions. Starting with the | ||
modeler: | modeler: | ||
Avoid having leaf geometry with very small parts. Collapse as much triangles | |||
as sensible for culling into the same leaf geometry. Sure if geometry needs a | Avoid having leaf geometry with very small parts. Collapse as much triangles as sensible for culling into the same leaf geometry. Sure if geometry needs a | ||
different texture or anything that requires a different OpenGL state you cannot | different texture or anything that requires a different OpenGL state you cannot collapse this into the same leaf. May be it makes sense then to collapse the | ||
collapse this into the same leaf. May be it makes sense then to collapse the | |||
textures into a common one. Then you might be able to collapse more geometry. | textures into a common one. Then you might be able to collapse more geometry. | ||
Avoid animations that are not really required. If you need a transform node in | Avoid animations that are not really required. If you need a transform node in between some geometry, the geometry below the transform needs to be drawn | ||
between some geometry, the geometry below the transform needs to be drawn | seperate which takes time on the cpu. Everything that needs geometry to be drawn seperately should be avoided to that level where it stops to make sense | ||
seperate which takes time on the cpu. Everything that needs geometry to be | |||
drawn seperately should be avoided to that level where it stops to make sense | |||
because of culling. | because of culling. | ||
May be introduce some level of detail. Not just avoid the whole model in some | May be introduce some level of detail. Not just avoid the whole model in some distance, but also provide a static model without animations, simple geometry | ||
distance, but also provide a static model without animations, simple geometry | for the mid range. May be provide some more culling friendly and detaild with the animations you need for the short range. | ||
for the mid range. May be provide some more culling friendly and detaild with | |||
the animations you need for the short range. | |||
Keep in mind that culling a model that you are close to should make you split | Keep in mind that culling a model that you are close to should make you split the model into more parts that could possibly be culled away. But for culling | ||
the model into more parts that could possibly be culled away. But for culling | a far away model is probably very sufficient to cull it either as a whole or not. | ||
a far away model is probably very sufficient to cull it either as a whole or | |||
not. | |||
Avoid state changes. Use as much common state as possible. Osg does a good job | Avoid state changes. Use as much common state as possible. Osg does a good job in sorting together draws using the same state, but if the overall scene | ||
in sorting together draws using the same state, but if the overall scene | contains plenty of different state osg cannot change that.A new texture is a new state for example. A new shader is a new state. .... | ||
contains plenty of different state osg cannot change that. | |||
A new texture is a new state for example. A new shader is a new state. .... | |||
Once your orange bar is longer than the yellow one, you can start to care for | Once your orange bar is longer than the yellow one, you can start to care for the shaders and their execution. | ||
the shaders and their execution. | When thinking about shaders, keep in mind that different GPU's perform very different on the same shader. | ||
When thinking about shaders, keep in mind that different GPU's perform very | |||
different on the same shader. | |||
Appart from OpenGL we spend a lot of time in scenegraph traversal. This is | Appart from OpenGL we spend a lot of time in scenegraph traversal. This is mostly due to plenty of structural and often needless nodes in the scenegraph. | ||
mostly due to plenty of structural and often needless nodes in the scenegraph. | The reason or this is that historically the xml files did some implicit grouping for *every* animation in the xml file. To make that reilably work Mathias | ||
The reason or this is that historically the xml files did some implicit | had to introduce a huge amount of group nodes in the xml file loader. These really hurt today as they introduce a whole lot of group nodes that just have | ||
grouping for *every* animation in the xml file. To make that reilably work Mathias | |||
had to introduce a huge amount of group nodes in the xml file loader. These | |||
really hurt today as they introduce a whole lot of group nodes that just have | |||
a single child which need to be traversed for update and for cull. | a single child which need to be traversed for update and for cull. | ||
There's also the long-term plan to flatten the LOD quadtrees and transforms of the tiles. Each tile will get some top-level LOD | There's also the long-term plan to flatten the LOD quadtrees and transforms of the tiles. Each tile will get some top-level LOD groups for all objects (shared and static). I'm hoping in combination with the LOD-scale function in OSG, this will mean we can automatically drop random tress / building and STG objects to keep frame-rate up. (as an optional mode of course!) - we hope to simply get less tiles and models present by a better lod structure. | ||
groups for all objects (shared and static). I'm hoping in combination with the LOD-scale function in OSG, this will mean we can automatically drop random | |||
tress / building and STG objects to keep frame-rate up. (as an optional mode of course!) - we hope to simply get less tiles and models present by a better lod structure. | |||
The trick is to minimize the number of LOD nodes introduced into the scene graph while avoiding popping effects - flattening the transforms is good to do. But some of them are critical to stay like the are or at least similar. The first one that positions objects with respect to the earth centered | The trick is to minimize the number of LOD nodes introduced into the scene graph while avoiding popping effects - flattening the transforms is good to do. But some of them are critical to stay like the are or at least similar. The first one that positions objects with respect to the earth centered coordinate system for precision reasons. Also these coordinate systems coudl for drawing reasons aligned in any direction. But as long as we do simulations using the same tree and geometry alignments that we do for draw this still interferes with the bounding volumes we have for ground intersections. And this axis aligned bounding box implementation gains a lot by having the boxes horizontally aligned. Todays transforms are done so that huger things are aligned with the horizont which serves this purpose. | ||
coordinate system for precision reasons. Also these coordinate systems coudl for drawing reasons aligned in any | |||
direction. But as long as we do simulations using the same tree and geometry alignments that we do for draw this still interferes with the bounding volumes | |||
we have for ground intersections. And this axis aligned bounding box implementation gains a lot by having the boxes horizontally aligned. Todays | |||
transforms are done so that huger things are aligned with the horizont which serves this purpose. | |||
In [[FGViewer]] there's a PagedLOD whole world database tree running. This is similar to osg's marble | In [[FGViewer]] there's a PagedLOD whole world database tree running. This is similar to osg's marble dataset but carefully designed around our tile structure. Using this I think we can really replace a lot of our fine structured scenery tiles with something more croase that is used for tiles more far away. | ||
dataset but carefully designed around our tile structure. Using this I think | Drawback with our current codebase: Our integration of the particle systems need to be rethought as this contains geometry with culling disabled which | ||
we can really replace a lot of our fine structured scenery tiles with something | makes a pagedlod just never expire. Switching the particle systems off works pretty good so far. | ||
more croase that is used for tiles more far away. | |||
Drawback with our current codebase: Our integration of the particle systems | |||
need to be rethought as this contains geometry with culling disabled which | |||
makes a pagedlod just never expire. Switching the particle systems off works | |||
pretty good so far. | |||
Another goal is to add more node bits (and a GUI dialog to control them) so | 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 | ||
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 | ||
mean the direct hit of, say, AI models vs particles vs random trees can be | such things, but would still help different people identify slowness on their setups. | ||
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. | |||
Profiling shows that Group::traverse is the most used function in flightgear. | Profiling shows that Group::traverse is the most used function in flightgear. The lowest hanging fruit could be to optimize away the redundant nodes from | ||
The lowest hanging fruit could be to optimize away the redundant nodes from | the top level model that gets loaded by a database pager request. We cannot do that recursively once a model part is loaded since the mentioned grouping | ||
the top level model that gets loaded by a database pager request. We cannot do | nodes might be referenced in any level in the model hierarchy above the currently loaded model. So only the top level model could do this without | ||
that recursively once a model part is loaded since the mentioned grouping | |||
nodes might be referenced in any level in the model hierarchy above the | |||
currently loaded model. So only the top level model could do this without | |||
braking tons of models. | braking tons of models. | ||