Scenegraph optimizations: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 38: Line 38:
serves this purpose.<ref>https://sourceforge.net/p/flightgear/mailman/message/29571579/</ref>
serves this purpose.<ref>https://sourceforge.net/p/flightgear/mailman/message/29571579/</ref>


=== Sky ==
=== Sky ===
In Fred's other terrain engine project, the sky is drawn with a quad  
In Fred's other terrain engine project, the sky is drawn with a quad  
(4 vertices at the corners of the screen). The view direction is  
(4 vertices at the corners of the screen). The view direction is  

Revision as of 11:04, 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]

Sky

In Fred's other terrain engine project, the sky is drawn with a quad (4 vertices at the corners of the screen). The view direction is computed in the vertex shader and then interpolated in a varying and renormalized in the fragment shader. That way there is no wasted computation (except the region overdrawn by the terrain, but that could be optimized with a stencil buffer)[5]

References

References