Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSG not caching bounding volumes when using ComputeBounds #1162

Open
TP-David opened this issue Apr 17, 2024 · 1 comment
Open

VSG not caching bounding volumes when using ComputeBounds #1162

TP-David opened this issue Apr 17, 2024 · 1 comment

Comments

@TP-David
Copy link

In our application we are calculating bounding volumes every frame/when the camera moves, due to how our scene graph is structured. Moving to VSG from OSG has caused a major slowdown we've discovered.

We've found that the ComputeBounds visitor is not caching bounding volumes, causing them to be constantly re-calculated upon new calls and iterating every triangle in the mesh, unlike OSG.

@robertosfield
Copy link
Collaborator

vsg::ComputeBounds is not meant to be used on the whole scene graph every frame.

I chose not to implement bounding volumes on all nodes like the OSG does as with modern scene graphs that can contain both compute subgraphs and graphics subraphs, and even the graphics subgraphs may have shaders that move them from their original vertex positions so computation of bounds on the CPU requires extra work to do the equivalent of what the shaders do.

Another factor is most nodes don't actually require culling or make little difference to the end result, and the bounds (vsg::box or vsg::sphere) would consume memory, these two factors actually slow scene graph traversal down. Instead the VSG reserves bounding volumes for CullGroup/CullNode/LOD/PagedLOD and these must be explicitly placed into the scene graph by the developer.

Now these cull nodes all have a bounding sphere associated with them, and the vsg::ComputeBounds by default actually uses them when computing bounds rather than traversing the whole subgraph below them. So while not "caching" the bounding volume it can serve a similar purpose.

You haven't specified why you need/what you use a bounding volume for, it might be that whatever you require can be tackled in different way.

If you really do need to compute the bounds of the whole scene graph then perhaps the new vsg::RegionOfInterst node might be use.

The other alternative is to place a CullGroup/LOD above each of main parts of your scene graph, and if the subgraphs get updated then use ComputeBounds on that subgraph to find out what the new value should be for the cull node. This way the overall scene vsg::ComputeBounds can terminate early by just checking the topmost cull nodes bounds. You also get to leverage the VSG's view furstum/lod culling as part of this as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants