Cesium-3dTiles格式详解

3D Tiles is an open specification for sharing, visualizing,fusing, interacting with, and analyzing massive heterogeneous 3D geospatial content across desktop,web, and mobile applications. 3D Tiles is built on glTF,

an open standard for efficient streaming and rendering of 3D models and scenes.

3D Tiles是一个开放规范，用于在桌面、web和移动应用程序之间共享、可视化、融合、交互和分析大量异构3D地理空间内容。3D Tiles是建立在glTF之上的，glTF是一个开放的标准，用于高效地流式处理和渲染3D模型和场景。

3D geospatial content, including photogrammetry/massive, models, BIM/CAD, 3D buildings, instanced features, and point clouds, can be converted into 3D Tiles and combined into a single dataset for seamless performance and real-time analytics including measurements, visibility analysis, styling and filtering.

三维地理空间内容（包括摄影测量/海量、模型、BIM/CAD、三维建筑、实例要素和点云）可以转换为三维分幅，并组合成单个数据集，以实现无缝性能和实时分析，包括测量、可见性分析、样式设置和过滤。

This overview summarizes the main concepts that are supported by the 3D Tiles specification:

本概述概述了3D瓷砖规范支持的主要概念：

The general concepts of tilesets and tiles, and how they make it possible to organize massive datasets into elements that can be streamed efficiently

tilesets和tile的一般概念，以及它们如何将大量数据集组织成可以高效流式传输的元素

How 3D Tiles implements hierarchical spatial data structures that are used for efficient rendering and interaction.

3D瓷砖如何实现用于高效渲染和交互的分层空间数据结构。

The concept of a Hierarchical Level of Detail (HLOD), which makes it possible to balance rendering performance and visual quality at any scale.

层次细节层次（HLOD）的概念，它使得在任何尺度上平衡渲染性能和视觉质量成为可能。

How the concepts behind 3D Tiles can be implemented for efficient rendering and interaction

如何实现3D切片背后的概念以实现高效的渲染和交互

The technical details of the different tile formats in 3D Tiles

3D切片中不同的切片格式的技术细节

The possibility to extend the base specification with additional features

使用附加特性扩展基本规范的可能性

The capabilities for information visualization by styling the content based on metadata

通过基于元数据设置内容样式实现信息可视化的功能

How basic elements like geospatial coordinate systems and geometry data compression are integrated in 3D Tiles

如何将地理空间坐标系和几何数据压缩等基本元素集成到三维切片中

1. At A Glance:An Example Tileset

The core element of 3D Tiles is tilesets. A tileset is a set of tiles, organized in a hierarchical structure. The tileset is described in JSON. The following is a simple example of a tileset, introducing the most important concepts and elements. Each concept is explained in more detail in the following sections.

The main tileset JSON contains a basic description of the asset and general properties. The geometric error (Section 5) is used to determine when the root tile should be rendered.

Each tile contains a bounding volume (Section 3) that encloses the content of the tile and all children. It also contains a geometric error that determines when the children should be rendered.

In this example, the first child tile refers to a 3D model with a low level of detail. The tile format of the model in the example is a Batched 3D Model (Section 10.2)

The child tiles contain additional details for the model. They are rendered when a higher level of detail is requested.

In this example, the contents of the child tiles will be added to the low-level representation of the model of the parent node. Alternatively, the child tiles could contain more detailed models that replace the low-level model. These are the two refinement strategies (Section 6) that are supported by 3D Tiles.

Different tile formats can be combined in one tileset: in this example, the first child tile referred to a Batched 3D Model. Another child tile of the root node refers to a Point Cloud (Section 10.4).

Another tile is an Instanced 3D Model (Section 10.3) where a simple geometry is rendered multiple times, at different positions.

When the tileset is rendered, the tiles are combined, at the appropriate level of detail, to generate the final rendered result:

2. Tilesets and Tiles

A tileset is a set of tiles, which are organized as a hierarchical data structure, called a tree. The tileset itself contains the root tile, and each tile may have child tiles.

A tile can also refer to another tileset. This makes it possible to flexibly and hierarchically combine tilesets into larger ones.

Each tile may refer to renderable content. This content can have different formats and may represent, for example, textured terrain surfaces, 3D models, or point clouds. The different possible tile formats are explained in Section 9, "Tile Formats: Introduction.'

Both tilesets and tiles are described in JSON. The tileset JSON file contains basic information about the tileset itself, and the description of the tiles.

Tileset Properties:
Root tile:The root property of a tileset is a tile that represents the root of the tile hierarchy.
Geometric:The geome tricError property is used to quantify the visual error that would occur if the
error:tileset was not rendered. When the visual error exceeds a certain threshold, then the tileset and the tiles that it contains are considered for rendering. Details of how the geometric error is used are given in Section 5, "Geometric Error."
Property:The renderable content of tiles may have associated properties. For example, when
summaries:the tiles contain buildings, then the height of each building can be stored in the tile.The properties object of a tileset contains the minimum and the maximum of select property values for all tiles in the tileset.
Metadata:Information about the 3D Tiles version and application-specific version information can be stored in the asset property of a tileset.

Tile Properties:
Content:The actual renderable content that is associated with a tile is referred to via a URI in the content property.
Children:The hierarchical structure of tiles is modeled as a tree: each tile may have children,which are tiles in an array named children.
Bounding Volume:Each tile has an associated bounding volume, and different types of bounding volumes
may be stored in the boundingVolume property. The possible types of bounding volumes are presented in Section 3, "Bounding Volumes." Each bounding volume encloses the content of the tile and the content of all children, yielding a spatially coherent hierarchy
of bounding volumes.
Geometric error:The renderable content of tiles may have different levels of detail. For tiles, the geometricError property quantifies the degree of simplification of the content in the tile compared to the highest level of detail. The geometric error is used as described
in Section 5, "Geometric Error," to determine when the child tiles should be considered for rendering.
Refinement strategy:When the visual error of a tile with a certain level of detail exceeds a threshold, then the child tiles are considered for rendering. The way the additional detail from the child tiles is incorporated into the rendering process is determined by the refine
property. The different refinement strategies are explained in Section 6, "Refinement."

3. Bounding Volumes

Each tileset is a set of tiles that are organized in a hierarchical manner, and each tile has an associated bounding volume. This yields a hierarchical spatial data structure that can be used for optimized rendering and efficient spatial queries. Additionally, each tile can contain actual renderable content that also has a bounding volume. In contrast to the tile bounding volume, the content bounding volume fits tightly only to the content and can be used for visibility queries and view frustum culling to further increase the rendering performance.

The 3D Tiles format supports different types of bounding volumes, and different strategies for their hierarchical organization.

Types of Bounding Volumes:

Different types of bounding volumes are supported in 3D Tiles, making it possible to choose the type that is best suited for the structure of the underlying data:

A bounding sphere is a simple bounding volume that allows easy and efficient intersection tests. It is defined by its center position and the radius.

An oriented bounding box fits the bounding volume more tightly to the geometry, particularly for regular, technical structures like CAD models. It is defined by the center position of the box, and three 3D vectors. The vectors define the directions and half-lengths of the x, y, and z-axis.

A region is particularly well suited to geographical information systems, because the sides of the region are defined with latitude and longitude coordinates, for the west, south, east, and north of the region, and a minimum and maximum height. Latitudes and longitudes are in the WGS 84 datum as defined in EPSG 4979 and are in radians. The minimum and maximum height are given in meters above or below the WGS 84 ellipsoid.

Details about WGS84 and the EPSG 4979 can be found in Section 13, "Common Definitions. '

4. Spatial Data Structures

The tiles in a tileset are organized in a tree data structure. Each tile has an associated bounding volume. This allows modeling different spatial data structures. The following section will present different types of spatial data structures that can all be modeled with 3D Tiles. The runtime engine can use the spatial information generically in order to optimize the rendering performance, independent of the actual characteristics of the spatial data structure.

Spatial Coherence

All types of bounding volumes and spatial data structures in 3D Tiles have spatial coherence, meaning that the bounding volume of a parent tile always encloses the content of all its child tiles.

Spatial coherence is crucial for conservative visibility tests and intersection tests because it guarantees that when an object does not intersect the bounding volume of a tile, then it also does not intersect the content of any child tile.

In contrast, when the object does intersect a bounding volume, then the bounding volumes of the children are tested for intersections. This can be used to quickly prune large parts of the hierarchy, leaving only a few leaf tiles where the object must be tested for intersections with the actual tile content geometry.

Types of Spatial Data Structures

There are different approaches for constructing hierarchical spatial data structures with bounding volumes. These approaches generally result in different types of spatial data structures, depending on the exact strategy that is used for the construction.

A simple spatial hierarchy can be constructed by recursively splitting the content of a tile along certain axes, until a stopping criterion is met. When the content is only split along a single axis at each level, then the result is a k-d tree. 3D Tiles also supports multi-way k-d trees, where each level has multiple splits along one axis. When the content is split along the x, y, and the z-axis at each level,then the result is an octree. When the content is split at the center of the content bounding volume,then the result is a uniform octree. When the content is split at a different point, then the result is a non-uniform octree.

At each level of the hierarchy, the bounding volumes can be created purely spatially from the bounding volume of the parent node. Alternatively, the bounding volumes for each node can be computed from the actual content of the node. This can be particularly useful for sparse datasets because it ensures tightly-fitting bounding volumes at each level of the hierarchy.

It is sometimes not possible to divide a tile without splitting a single feature (model) of the content. It is therefore possible to construct loose octrees and loose k-d trees, where the bounding volumes of children overlap. These trees still maintain spatial coherence, in that the parent bounding volume still encloses the content of all children.

In the most general case, a tileset can be divided into a non-uniform grid. Since each node in the spatial hierarchy in 3D Tiles may have an arbitrary number of child nodes, and non-leaf tiles are not required to contain renderable content, the grid cells can still be organized in a hierarchical structure in order to support hierarchical culling.

The generic spatial data structures in 3D Tiles allow modeling the results of all these construction methods. Each tile is a node of the hierarchy that may optionally refer to geometry content or store only a bounding volume that encloses the content of all its descendants, and different types of bounding volumes can be stored in a single tileset.

5. Geometric Error

One of the goals of 3D Tiles is to efficiently stream massive datasets to runtime engines, and still allow the runtime to render this content efficiently. The hierarchical structure of tiles in a tileset therefore incorporates the concept of a Hierarchical Level of Detail (HLOD): tiles at the top of the hierarchy contain representations of the renderable content with a low level of detail. The child tiles contain content with a higher level of detail. The rendering runtime can dynamically choose the level of detail that offers the best trade-off between performance and rendering quality.

The key for determining which level of detail should be rendered is the geometric error. Each tileset and each tile has a geometricError property that quantifies the error of the simplified geometry compared to the actual geometry. .

The runtime translates this geometric error into a screen-space error (SSE). The SSE quantifies how much of the geometric error will be visible, in terms of pixels on the screen.

When the SSE exceeds a certain threshold, the runtime will render a higher level of detail. For a tileset, the geometric error is used to determine whether the root tile should be rendered. For a tile, the geometric error is used to determine whether the children of the tile should be rendered.

5.1 Computing the Screen Space Error (SSE)

The runtime can use the information that is provided with the geometric error to find the best trade-off between performance and rendering quality: for any given tileset or tile, the runtime can determine how much the visual quality could improve by rendering the tile, even without actually downloading and rendering the tile content.

To accomplish that, the runtime must compute the screen space error for a given geometric error. The actual screen space error in pixels will depend on the view configuration- -that is, the position and orientation of the viewer- and on the resolution at which the final image will be rendered.

The computation of the SSE therefore must take these factors into account. The exact implementation will also depend on the type of view projection that is used. But for a standard perspective projection, one possible way of computing the SSE is as follows:

where geometricError is the geometric error that was stored in the tileset or tile, screenHeight is the height of the rendering screen in pixels, tileDistance is the distance of the tile from the eye point, and fovy is the opening angle of the view frustum in the y-direction.

6. Refinement Strategies

When a tileset is rendered, the runtime traverses the hierarchy of tiles, examines the geometric error of each tile, and computes the associated screen space error. When this screen space error exceeds a certain threshold, then the runtime will recursively consider the child tiles for rendering. The child tiles that contain renderable content have a higher level of detail and a smaller screen space error.

The content of the child tiles can be used to increase the level of detail through one of two refinement strategies. The refinement strategy is determined by the refine property of a tile, and can either be REPLACE or ADD:

The refine property can be given for each tile individually but is only required in the root tile of a tileset. When it is not given, the strategy will be inherited from the parent tile.

7. Optimized Rendering with 3D Tiles

3D Tiles is designed for efficient rendering and streaming of massive heterogeneous datasets. The following is a summary of how the concepts of 3D Tiles can be used by a runtime to interactively render a huge tileset. It shows how the hierarchical structure of tilesets and tiles, the associated bounding volumes, the concept of the geometric error, and the different refinement strategies play together.

The tileset in this example contains a set of buildings. The bounding volume of each element is shown in red.

The tileset contains the root tile, which in turn contains three child tiles. Each child tile contains renderable content. In the example, the content of each tile consists of two buildings, stored as a Batched 3D Model. At this level, the content is stored with a low level of detail, which means that the tiles have a high geometric error. Each child additionally refers to a child where the same content is stored with a higher level of detail, and thus, with a lower geometric error.

During rendering, the runtime maintains a view frustum, which is defined by the camera position, orientation, and the field-of-view angle. The view frustum can be tested for intersections with the bounding volumes of tilesets and tiles.