Terrain Culling with Oriented Bounding Boxes
Cesium 1.11 will include network and rendering performance improvements for terrain and imagery. Previously, Cesium used bounding spheres around terrain tiles for view frustum culling to avoid processing tiles out of view. In Cesium 1.11, we added support for culling tiles using arbitrarily-oriented bounding boxes.
For a quick comparison, this GIF shows both types of bounding volumes for a tile[1] at Crater Lake in Oregon:
It even works fairly well for much larger tiles1, such as this one between Quebec and the North Pole, which improves upon the bounding sphere:
| Tiles rendered at 1920x1080 | Directly downward | Toward horizon, high altitude | Toward horizon, low altitude | Below horizon |
|---|---|---|---|---|
| oriented bounding box, terrain | 73 | 218 | 279 | 307 |
| bounding sphere, terrain | 77 | 226 | 330 | 599 |
| improvement | 5.2% | 3.5% | 10% | 48% |
| oriented bounding box, ellipsoid | 79 | 215 | 268 | 300 |
| bounding sphere, ellipsoid | 86 | 222 | 303 | 486 |
| improvement | 8.1% | 3.1% | 12% | 38% |
The bounding box optimization turns out to provide the greatest benefits (around 50% reduction) when the camera is looking down at an angle below the horizon. Without the new bounding box, the bounding spheres of tiles which are above the camera's view have a high chance of intersecting with the camera frustum even though the tiles themselves are not visible. This can be seen in this comparison:
Camera view:
The tiles rendered in the above view when using bounding spheres (599 tiles):
The tiles rendered in the above view when oriented bounding boxes (307 tiles):
Bounding Box Computation and Testing
For terrain tiles, our current method for computing oriented bounding boxes is conceptually simple: create the bounding box in the local east-north-up reference frame at the center of a tile, then compute the extents necessary to completely enclose the tile. This is done once for each tile.
To check whether a bounding box is outside the view frustum, we use the method from Eric Lengyel's Mathematics for 3D Game Programming. Each frustum plane is checked for intersection with the oriented bounding box. This is basically the same as the method previously used for bounding spheres.
Though this method is almost as simple, computing intersections with a bounding box is more expensive than with a bounding sphere. As such, there is some additional CPU overhead in the intersection test, which is traded for fewer draw calls and network requests.
| Volume used for terrain tiles | Frame time spent in intersectPlane() |
|---|---|
| oriented bounding box | 2.1% |
| bounding sphere | 1.6% |
