Cesium is the 3D platform for visualizing globes, from every satellite in space to every building in Manhattan to every crater on Mars. To achieve this Digital Earth vision of connecting the world’s geospatial data, we’re excited to introduce our biggest initiative since Cesium itself: 3D Tiles.
3D Tiles are an open specification for streaming massive heterogeneous 3D geospatial datasets. To expand on Cesium’s terrain and imagery streaming, 3D Tiles will be used to stream 3D content, including buildings, trees, point clouds, and vector data.
3D Tiles are already in progress in Cesium; for example, see:
Point cloud of the Church of St Marie at Chappes, France.
Bringing techniques from graphics research, the movie industry, and the game industry to 3D geospatial, 3D Tiles define a spatial data structure and a set of tile formats designed for 3D and optimized for streaming and rendering. Tiles for 3D models use glTF, the WebGL runtime asset format developed by Khronos, which the Cesium team heavily contributes to.
Loading 3D Tiles in Cesium will be as simple as this:
3D Tiles are
- Optimized for streaming and rendering
- Designed for 3D
3D Tiles are an open specification with an open-source implementation in Cesium. We expect to see other 3D engines and conversion tools use 3D Tiles.
Development of both the spec and implementation are in-progress, and we encourage open discussion on the Cesium forum. We expect them to stabilize in spring 2016.
Optimized for streaming and rendering
The primary purpose of 3D Tiles is to improve streaming and rendering performance of massive heterogeneous datasets. The foundation of 3D Tiles is a spatial data structure that enables Hierarchical Level of Detail (HLOD) so only visible tiles are streamed - and only those tiles which are most important for a given 3D view. Tile payloads can be binary and context-aware compressed, e.g., using Open3DGC or oct-encoding.
3D Tiles are designed by a team that has used WebGL since its start, and OpenGL for many years before that. As a result, like glTF, the pipeline from receiving a 3D Tile to rendering it with WebGL is streamlined to be fast and simple, and to minimize client-side processing. To reduce the number of WebGL draw calls, tiles may be pre-batched or batched on-the-fly.
3D buildings in Cambridge.
Bounding volumes for tiles in a sparse grid layout. Each tile is one WebGL draw call.
A zoomed in view looking at Harvard Yard.
A zoomed out debug view shows that only a subset of the Cambridge dataset needed to be rendered in the above Harvard Yard view.
Designed for 3D
From the ground up, 3D Tiles are designed for true 3D with a free-roaming camera; they are not limited to cases such as 2.5D perspective.
Instead of relying on 2D constructs such as zoom levels, 3D Tiles are based on geometric error for Level-Of-Detail (LOD) selection and a tunable pixel error. This allows performance/visual-quality tuning and is built for multiple “zoom levels” in the same view.
In 3D Tiles, bounding volumes are 3D, not 2D cartographic extents. In 2D, the tiling scheme is often based on the Web Mercator projection. Web Mercator is not ideal for 3D because the poles project to infinity and also because the NGA does not recommend Web Mercator for DoD application. In contrast, in 3D Tiles the tiling scheme is adaptable, in all three dimensions, depending on the models in the dataset and their distribution.
Traditional geospatial features, such as polygons and polylines, can be extruded or drawn above the surface. But 3D Tiles go beyond points, polylines, and polygons, to account for full 3D models with meshes, materials, and a node hierarchy.
3D Tiles support interactive selection and styling. Even with WebGL optimizations such as batching, 3D Tiles allow for individual model interaction such as highlighting on mouseover, or removing a 3D building. Tiles can contain metadata for each model to allow additional interaction, such as querying third-party web services using a building ID.
Mouseover highlighting demonstrating 3D Tile interaction.
Metadata for individual models, such as building height or year built, can be used for shading at runtime without writing code. Styles can be changed on-the-fly.
Height-dependent building color demonstrating 3D Tile styling.
Traditional quadtree subdivision, used in TMS for example, is sufficient for map tiles and 2D, but it is suboptimal for 3D and non-uniform dataset distributions.
3D Tiles enable adaptive spatial subdivision in 3D, including k-d trees, quadtrees, octrees, grids, and other spatial data structures. Instead of rigid spatial subdivision, conversion tools can adaptively subdivide a dataset, for example, based on the cost of rendering each model and the distribution of models, resulting in a balanced data structure. A runtime engine like Cesium is generic and works with all subdivision techniques.
An adaptive quadtree-like subdivision based on the distribution of buildings in Cambridge.
With traditional 2D map tiles, when the user zooms in, the visible map tiles are replaced with new higher-resolution map tiles. This is called refinement. In a sense, a subset of the same content is downloaded again, but at a higher resolution. We call this replacement refinement, and it is a reasonable solution for imagery tiles and even 3D terrain.
However, more flexibility is needed for other 3D datasets such as buildings and point clouds. For example, instead of essentially downloading the same building multiple times as the viewer zooms in, 3D Tiles rather stream just new buildings. We call this additive refinement. Additive refinement has the additional benefit that child tiles can be rendered as they are downloaded, as opposed to replacement refinement, which requires that all of a parent’s children be downloaded first.
3D Tiles allow both replacement and additive refinement.
The root tile for buildings in Miami contain the most "important" buildings.
As the viewer zooms in, child tiles containing the next most important buildings are streamed in using additive refinement. The root tile and its closest child are shown here.
As the viewer zooms in even closer, grandchildren tiles are loaded (blue). Note that child tiles are not loaded in the distance.
3D Tiles are heterogeneous because there is no one-size-fits-all for 3D datasets. Batched models (e.g., buildings) need a different representation from instanced models (e.g., trees), which need a different representation from point clouds, and so on.
3D Tiles support heterogeneous datasets by enabling adaptive subdivision, flexible refinement, and an extendable set of tile formats.
The heterogeneous nature of 3D Tiles allows discrete levels of detail combined with HLOD so, for example, a 3D building could be a billboard and label at one LOD, an extruded footprint at a higher LOD, a 3D model at the next LOD, and a textured 3D model at the highest LOD.
Cesium is designed for time-dynamic visualizations, such as of satellites and UAVs. The next step is to extend this to 3D Tiles so users can, for example, see topography or snow cover change over time with massive time-dynamic terrain and point clouds.
For more demos, see our demos using 3D buildings from CyberCity 3D:
For the nitty gritty details, check out the 3D Tiles spec, and prepare to build amazing apps with 3D Tiles and Cesium.
Also, the Cesium team at AGI is hiring in all areas, including 3D Tiles. Contact me to learn more about working with us.