Scenegraph optimizations: Difference between revisions
(→Status) |
m (→Status: https://sourceforge.net/p/flightgear/mailman/message/28795619/) |
||
| Line 5: | Line 5: | ||
RFC / 09/2020 | RFC / 09/2020 | ||
== Background == | |||
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. | |||
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 I | |||
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. 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 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 | |||
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.<ref>https://sourceforge.net/p/flightgear/mailman/message/28795619/</ref> | |||
=== Flattening Transforms === | === Flattening Transforms === | ||
Revision as of 11:02, 3 September 2020
| This article is a stub. You can help the wiki by expanding it. |
This page is intended to gather comments related to optimizing our scene graph, which is a long-standing idea to address the issue of FlightGear being CPU bound for many end users.
Status
RFC / 09/2020
Background
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. 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 I 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. 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 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 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.[1]
Flattening Transforms
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!)[2]
The trick is to minimize the number of LOD nodes introduced into the scene graph while avoiding popping effects.[3]
As already discussed this 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.[4]