Bounding boxes on CPU and GPU

[dov]

While examining why bounding box calculation is so slow for large models, e.g. a CAD model I have worked on has 4.5M triangles, which takes about 0.2s to do on the host. I started wondering why the calculation is done in the CPU and not on the GPU. I asked Github Copilot about it, and I got the response that calculating the bounding box is feasible by using a Compute shader and parallel reduction. I will try to implement such a shader for my own application, but I was wondering whether this could not be generalized for the ComputeBounds visitor as well in VSG? Perhaps I'll find out after doing such an implementation, but I was still curious if someone has tried doing this?

[robertosfield]

0.2s is pretty low if you are only doing the calculation when you are first loading the model.

Are you calculating it often for some reason? Perhaps caching it would help. As a general note, if you have CullNode/CullGroup/LOD/PagedLOD in the scene graph these have bounding spheres that are used by ComputeBounds visitor by default to create the bounding volume of the scene graph, this produces a less tight bound but is faster as you don't have to visit the mesh leaves of the scene graph.

Moving these type of computation to the GPU is possible but would require a round trip from the CPU to GPU and back to the CPU, this round trip will likely negate any possible performance improvements.

The times when computing bounding volumes on the GPU makes sense would be when you have data that is being computed on the GPU and remains resident on the GPU, and then can be used by shaders in their work.

[AnyOldName3]

If you're changing the transform, you can just transform the old bounding box rather than recomputing it from scratch. Most of the things the VSG uses bounds for work this way already.

[dov]

Sorry, I should have said axis aligned bounding box. It changes depending on the orientation.

[dov]

The VSG's culling nodes - CullNode, CullGroup, LOD & PagedLOD all use a vsg::dsphere for their bounding volume. This is provides fastest in frustum test you can do when view frustum culling.

Convex hulls are very useful for their own tasks but less useful for high level scene graph culling. What do you need convex hull for?

ִYou're right, I don't really need it for display purposes. But I'm kind of mixing the algorithms and the visualization, and thinking about how to make use of the GPU for calculations. E.g. my application has a functionality align-to-tray, which should transform the min-z coordinate of a model to 0. So if the user rotates the model, I have to calculate the axis aligned bounding box. Right now, I'm doing it with ComputeBounds, but since the model is on the GPU, I could in principle calculate it through a kernel. And regarding, convex hull, it typically has much less vertices than the original model, and by definition its AABB is equal to the AABB of the original model, which means that I can use to speed up the calculation of the AABB. But this has nothing to do with its display.

[robertosfield]

For your specific usage case it may be worth having a ConvexHull class/node that you can decorate a subgraph with, the have a custom compute bounds visitor use this to compute the bounds.

[AnyOldName3]

As Robert said already, it's generally fairly slow to transfer data to the GPU and back again, so there's quite a lot of leeway for a CPU-side approach to be slow and still work out faster in the end. Also, while a GPU can chew through a lot more data at once, there are memory access patterns that will slow it to a crawl, but a CPU can handle just like any other, so certain algorithms won't be viable. Based on what you've said so far, I'd expect there to be more fertile ground if you look into spatial acceleration structures that let you recompute an AABB faster when it's reoriented rather than trying to make a naive approach faster by having a GPU deal with it.