A Bounding Volume Hierarchy (BVH) is a tree of nested bounding volumes over a set of geometry. Each leaf holds primitives; each interior node holds a volume enclosing all of its children. A query — “what does this ray hit?”, “what is inside this box?” — descends from the root and prunes any subtree whose volume already fails the test, so cost scales with the answer rather than with the size of the world.
Role in Gargantis#
The BVH is what makes locality of interest implementable. A node subscribes to the parts of a realm it can currently see rather than to the whole world: it walks the realm’s BVH against its view volume and pulls streams only for the partitions that survive. Traffic then scales with attention rather than with world size — a precondition for a peer-to-peer network, where there is no server to do that filtering on anyone’s behalf.
The same structure serves the classic uses: view-frustum culling, collision and picking queries, and level-of-detail selection.
Construction#
Build strategies trade query quality against rebuild cost, which matters because a realm’s contents move:
- Top-down splitting, typically with a surface-area heuristic — best query performance, most expensive to build.
- Bottom-up agglomerative merging.
- Linear / Morton-code (LBVH) — sorts primitives along a space-filling curve; cheap enough to rebuild continuously, at some query cost.
Alternative spatial indexes trade off differently: octrees and k-d trees partition space, whereas a BVH partitions objects and lets sibling volumes overlap.
External links#
Similar concepts and prior art:
- Bounding volume hierarchy on Wikipedia
- Octree, k-d tree, and binary space partitioning — space-partitioning alternatives
- R-tree — the same nested-bounds idea in spatial databases
- Viewing frustum and hidden-surface determination
- Level of detail — the other thing a hierarchy of bounds is good for