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 tiles 1, such as this one between Quebec and the North Pole, which improves upon the bounding sphere:
In practice, for terrain tiles, we see anywhere between a 0% and 50% (typically around 10%) reduction in number of tiles rendered, depending on the camera view. This improvement applies to terrain tiles and tiles procedurally generated using the WGS84 ellipsoid.
|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|
|oriented bounding box, ellipsoid||79||215||268||300|
|bounding sphere, ellipsoid||86||222||303||486|
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:
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%|
1 Visually, it appears here as if the bounding box does not fully enclose the terrain tile. However, the part of the terrain mesh which extends downward is not part of the terrain, but a "skirt" which extends downward around the tile to reduce visual artifacts in terrain rendering.