Cesium-3dTiles Format Details&convert other format to 3Dtiles with Opt Converter

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

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

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

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

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

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

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:

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."

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 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."

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.

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:

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:

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.