diff --git a/Q-and-A.md b/Q-and-A.md index cdccea122..e2febd325 100644 --- a/Q-and-A.md +++ b/Q-and-A.md @@ -29,7 +29,7 @@ No, 3D Tiles is a general spec for streaming massive heterogeneous 3D geospatial [glTF](https://www.khronos.org/gltf) is an open standard for 3D models from Khronos (the same group that does WebGL and COLLADA). CesiumJS uses glTF as its 3D model format, and the Cesium team contributes heavily to the glTF spec and open-source COLLADA2GLTF converter. We recommend using glTF in CesiumJS for individual assets, e.g., an aircraft, a character, or a 3D building. -We created 3D Tiles for streaming massive geospatial datasets where a single glTF model would be prohibitive. Given that glTF is optimized for rendering, that CesiumJS has a well-tested glTF loader, and that there are existing conversion tools for glTF, 3D Tiles often use glTF for tile content. Tiles may reference glTF models directly — with [`3DTILES_content_gltf`](./extensions/3DTILES_content_gltf) — or glTF models may be embedded in other tile formats such as [Batched 3D Model](./specification/TileFormats/Batched3DModel/README.md). +We created 3D Tiles for streaming massive geospatial datasets where a single glTF model would be prohibitive. Given that glTF is optimized for rendering, that CesiumJS has a well-tested glTF loader, and that there are existing conversion tools for glTF, 3D Tiles often use glTF for tile content. Tiles may reference glTF models directly, using the [glTF Tile Format](./specification/TileFormats/glTF/README.md). Taking this approach allows us to improve CesiumJS, glTF, and 3D Tiles at the same time. As new features and compression methods arrive in glTF, they benefit 3D models in CesiumJS, the glTF ecosystem, and 3D Tiles. @@ -91,7 +91,7 @@ See [#15](https://github.com/CesiumGS/3d-tiles/issues/15). #### How are cracks between tiles with vector data handled? -Unlike 2D, in 3D, we expect adjacent tiles to be from different LODs so, for example, in the distance, lower resolution tiles are used. Adjacent tiles from different LODs can lead to an artifact called _cracking_ where there are gaps between tiles. For terrain, this is generally handled by dropping _skirts_ slightly angled outward around each tile to fill the gap. For 3D buildings, this is handled by extending the tile boundary to fully include buildings on the edge; [see Quadtrees](./specification/README.md#Quadtrees). For vector data, this is an open research problem that we need to solve. This could involve boundary-aware simplification or runtime stitching. +Unlike 2D, in 3D, we expect adjacent tiles to be from different LODs so, for example, in the distance, lower resolution tiles are used. Adjacent tiles from different LODs can lead to an artifact called _cracking_ where there are gaps between tiles. For terrain, this is generally handled by dropping _skirts_ slightly angled outward around each tile to fill the gap. For 3D buildings, this is handled by extending the tile boundary to fully include buildings on the edge; [see Quadtrees](./specification/README.md#quadtrees). For vector data, this is an open research problem that we need to solve. This could involve boundary-aware simplification or runtime stitching. #### When using replacement refinement, can multiple children be combined into one request? @@ -111,4 +111,4 @@ See [#11](https://github.com/CesiumGS/3d-tiles/issues/11). #### What compressed texture formats does 3D Tiles use? -3D Tiles reference glTF tile content ([`3DTILES_content_gltf`](./extensions/3DTILES_content_gltf)), and the glTF format officially supports PNG, JPEG, and KTX2 / Basis Universal compressed textures ([`KHR_texture_basisu`](https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_texture_basisu)). Additional texture compression methods may be added to glTF in the future, as [glTF extensions](https://github.com/KhronosGroup/glTF/tree/main/extensions). Texture compression is generally applied offline, as it is often prohibitively expensive to do in JavaScript and Web Workers. +3D Tiles reference glTF content via the [glTF Tile Format](./specification/TileFormats/glTF/README.md), and the glTF format officially supports PNG, JPEG, and KTX2 / Basis Universal compressed textures ([`KHR_texture_basisu`](https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_texture_basisu)). Additional texture compression methods may be added to glTF in the future, as [glTF extensions](https://github.com/KhronosGroup/glTF/tree/main/extensions). Texture compression is generally applied offline, as it is often prohibitively expensive to do in JavaScript and Web Workers. diff --git a/README.md b/README.md index 8cdb99f41..e36ad55fa 100644 --- a/README.md +++ b/README.md @@ -34,16 +34,6 @@ Bringing techniques from the field of 3D graphics and built on [glTF](https://gi Please provide spec feedback by [submitting issues](https://github.com/CesiumGS/3d-tiles/issues). For questions on implementation, generating 3D Tiles, or to showcase your work, join the [Cesium community forum](https://community.cesium.com/). A list of resources for developers, including blog posts and presentations that explain the concepts and applications of 3D Tiles, can be found on the [3D Tiles Resources](./RESOURCES.md) page. -### Upcoming - -[3D Tiles Next](./next) is a set of new capabilities for the future of 3D Tiles. Provided as draft extensions to the [3D Tiles 1.0](../specification) specification, these features may be incorporated into 3D Tiles 2.0 in the future. - -- [Tile Content](./next#tile-content): glTF 2.0 assets may be used directly as tile content, without intermediate formats, improving interoperability with 3D content and tooling ecosystems. Tiles may reference multiple contents — for organization, styling, and filtering — and contents may be collected into groups similar to map layers in mapping applications. -- [Implicit Tiling](./next#implicit-tiling): Common subdivision schemes and spatial index patterns may be declared without listing bounding volumes exhaustively. Reduces tileset size, and enables new optimizations including faster traversal, raycasting, random access, and spatial queries. -- [Metadata](./next#metadata): Metadata in 3D Tiles gains more expressiveness and flexibility, with a well-defined type system, new encoding options (e.g. JSON or binary), and a range of granularity options. Metadata may be associated with high-level objects like tilesets, tiles, or tile content groups, or with individual vertices and texels on glTF 2.0 geometry. - -A curated list of resources for developers can be found on the [3D Tiles Next Resources](./next/RESOURCES.md) page. - ## 3D Tiles Ecosystem | Tool | Description | diff --git a/extensions/3DTILES_bounding_volume_S2/README.md b/extensions/3DTILES_bounding_volume_S2/README.md index b3ab4897f..bdf8f970a 100644 --- a/extensions/3DTILES_bounding_volume_S2/README.md +++ b/extensions/3DTILES_bounding_volume_S2/README.md @@ -104,7 +104,7 @@ For the cell IDs in the example above, the tokens are: ## Bounding Volume -An S2 cell describes 4 positions on the surface of the WGS84 ellipsoid forming the corners of a geodesic quadrilateral. To form a bounding volume, the quadrilateral is extruded along normals to the ellipsoid. `minimumHeight` determines the height of the bottom surface of the bounding volume, while `maximumHeight` determines the height of the top surface. Both `minimumHeight` and `maximumHeight` are expressed in meters above (or below) the ellipsoid. A tile's [`transform`](../../specification#tile-transforms) property will be ignored when this extension is used for describing a tile's `boundingVolume`. Tiles using this extension must maintain [spatial coherence](../../specification/README.md#bounding-volume-spatial-coherence). This extension may be applied to the [`tile.boundingVolume`](../../specification/schema/tile.schema.json) or the [`content.boundingVolume`](../../specification/schema/content.schema.json) objects. +An S2 cell describes 4 positions on the surface of the WGS84 ellipsoid forming the corners of a geodesic quadrilateral. To form a bounding volume, the quadrilateral is extruded along normals to the ellipsoid. `minimumHeight` determines the height of the bottom surface of the bounding volume, while `maximumHeight` determines the height of the top surface. Both `minimumHeight` and `maximumHeight` are expressed in meters above (or below) the ellipsoid. A tile's [`transform`](../../specification/README.md#tile-transforms) property will be ignored when this extension is used for describing a tile's `boundingVolume`. Tiles using this extension must maintain [spatial coherence](../../specification/README.md#bounding-volume-spatial-coherence). This extension may be applied to the [`tile.boundingVolume`](../../specification/schema/tile.schema.json) or the [`content.boundingVolume`](../../specification/schema/content.schema.json) objects. > **Implementation Note**: When mapping the sphere to the cube, S2 provides three projection methods: linear, quadratic and tangential. This extension assumes an implementation uses the quadratic projection, since it is reasonably accurate and efficient. diff --git a/extensions/3DTILES_implicit_tiling/README.md b/extensions/3DTILES_implicit_tiling/README.md index e43d7566a..b77cca26d 100644 --- a/extensions/3DTILES_implicit_tiling/README.md +++ b/extensions/3DTILES_implicit_tiling/README.md @@ -111,7 +111,7 @@ The following constraints apply to implicit root tiles: * The tile must omit the `children` property * The tile must not have the `3DTILES_metadata` extension - * The `content.uri` must not point to an [external tileset](../../specification#external-tilesets) + * The `content.uri` must not point to an [external tileset](../../specification/README.md#external-tilesets) * The `content` must not have an associated `boundingVolume` property ## Subdivision Scheme @@ -160,7 +160,7 @@ Implicit tiling only requires defining the subdivision scheme, refinement strate > > Let the extent of the root bounding volume along one dimension *d* be *(mind, maxd)*. The number of bounding volumes along that dimension for a given level is *2level*. The size of each bounding volume at this level, along dimension *d*, is *sized = (maxd - mind) / 2level*. The extent of the bounding volume of a child can then be computed directly as *(mind + sized * i, mind + sized * (i + 1))*, where *i* is the index of the child in dimension *d*. -The computed tile `boundingVolume` and `geometricError` can be overridden with [tile metadata](#tile-metadata), if desired. Content bounding volumes are not computed automatically but they may be provided by [content metadata](#content-metadata). Tile and content bounding volumes must maintain [spatial coherence](../../specification/#bounding-volume-spatial-coherence). +The computed tile `boundingVolume` and `geometricError` can be overridden with [tile metadata](#tile-metadata), if desired. Content bounding volumes are not computed automatically but they may be provided by [content metadata](#content-metadata). Tile and content bounding volumes must maintain [spatial coherence](../../specification/README.md#bounding-volume-spatial-coherence). ## Tile Coordinates @@ -301,7 +301,7 @@ Subtrees may also store metadata for tile content. Content metadata exists only Content bounding volumes are not computed automatically by `3DTILES_implicit_tiling` but may be provided by properties with semantics `CONTENT_BOUNDING_BOX`, `CONTENT_BOUNDING_REGION`, `CONTENT_BOUNDING_SPHERE`, `CONTENT_MINIMUM_HEIGHT`, and `CONTENT_MAXIMUM_HEIGHT`. -If the tile content is assigned a [`group`](../3DTILES_metadata#content-group-properties) — such as with the `3DTILES_metadata` extension — all contents in the implicit tree are assigned to that group. +If the tile content is assigned a [`group`](../3DTILES_metadata/README.md#content-group-properties) — such as with the `3DTILES_metadata` extension — all contents in the implicit tree are assigned to that group. #### Subtree Metadata @@ -333,7 +333,7 @@ Content availability (`contentAvailability`) is an array of content availability Availability may be represented either as a bitstream or a constant value. `bitstream` is an integer index that identifies the buffer view containing the availability bistream. `constant` is an integer indicating whether all of the elements are available (`1`) or all are unavailable (`0`). `availableCount` is an integer indicating how many `1` bits exist in the availability bitstream. -Availability bitstreams are packed in binary using the format described in the [Booleans](../../specification/Metadata#booleans) section of the 3D Metadata Specification. +Availability bitstreams are packed in binary using the format described in the [Booleans](../../specification/Metadata/README.md#booleans) section of the 3D Metadata Specification. > **Example:** The JSON description of a subtree where each tile is available, but not all tiles have content, and not all child subtrees are available: > @@ -393,7 +393,7 @@ Subtree metadata (`subtreeMetadata`) is encoded in JSON according to the [JSON F Binary property values are stored in a **property table**. A property table must specify its class (`class`), which refers to a class ID in the `3DTILES_metadata` extension of root tileset JSON, a dictionary of properties (`properties`), where each key is a property ID correspond to a class property and each value is the index of the buffer view containing property values, and a count (`count`) for the number of elements in the property table. The property table may provide value arrays for only a subset of the properties of its class, but class properties marked `required: true` must not be omitted. -A property may override the [`minimum` and `maximum` values](../../specification/Metadata#minimum-and-maximum-values) and the [`offset` and `scale`](../../specification/Metadata#offset-and-scale) from the property definition in the class, to account for the actual range of values that is stored in the property table. +A property may override the [`minimum` and `maximum` values](../../specification/Metadata/README.md#minimum-and-maximum-values) and the [`offset` and `scale`](../../specification/Metadata/README.md#offset-and-scale) from the property definition in the class, to account for the actual range of values that is stored in the property table. Array offsets (`arrayOffsets`) is required for variable-length arrays and string offsets (`stringOffsets`) is required for strings. For variable-length arrays of strings, both are required. `arrayOffsetType` describes the storage type for array offsets and `stringOffsetType` describes the storage type for string offsets. Allowed types are `UINT8`, `UINT16`, `UINT32`, and `UINT64`. The default is `UINT32`. diff --git a/extensions/3DTILES_metadata/README.md b/extensions/3DTILES_metadata/README.md index 5b8d42315..eb035a6e2 100644 --- a/extensions/3DTILES_metadata/README.md +++ b/extensions/3DTILES_metadata/README.md @@ -92,7 +92,7 @@ Metadata in 3D Tiles enables additional use cases and functionality for the form ### Overview -[*Properties*](#class-property) describe attributes or characteristics of an *Entity* (tileset, tile, group, or content). [*Classes*](#class), provided by [*Schemas*](#schema), are templates defining the data types and meanings of properties. Each entity is a single instance of that class with specific values. Additionally, [*Statistics*](#statistics) may provide aggregate information about the distribution of property values within a particular class, and [*Semantics*](#semantics) may define usage and meaning of particular properties. +[*Properties*](#class-property) describe attributes or characteristics of an *Entity* (tileset, tile, group, or content). [*Classes*](#class), provided by [*Schemas*](#schema), are templates defining the data types and meanings of properties. Each entity is a single instance of that class with specific values. Additionally, [*Statistics*](#statistics) may provide aggregate information about the distribution of property values within a particular class, and [*Semantics*](../../specification/Metadata/Semantics/README.md) may define usage and meaning of particular properties. ### Schema @@ -241,7 +241,7 @@ Set of categorical types, defined as `(name, value)` pairs. Enum properties use Enums are defined as entries in the `schema.enums` dictionary, indexed by enum ID. Enum IDs must be [identifiers](../../specification/Metadata/README.md#identifiers) as defined in the 3D Metadata Specification. -> **Example:** A "quality" enum defining quality level of data within a tile. An "Unspecified" enum value is optional, but when provided as the `noData` value for a property (see: [3D Metadata → No Data Values](../../specification/Metadata#required-properties-and-no-data-values)) may be helpful to identify missing data. +> **Example:** A "quality" enum defining quality level of data within a tile. An "Unspecified" enum value is optional, but when provided as the `noData` value for a property (see: [3D Metadata → No Data Values](../../specification/Metadata/README.md#required-properties-no-data-values-and-default-values)) may be helpful to identify missing data. > > ```jsonc > { @@ -371,7 +371,7 @@ While [classes](#class) within a schema define the data types and meanings of pr Each property value assigned must be defined by a class property with the same property ID, with values matching the data type of the class property. An entity may provide values for only a subset of the properties of its class, but class properties marked `required: true` must not be omitted. -Most property values are encoded as JSON within the entity. One notable exception is metadata assigned to implicit tiles and contents, stored in a more compact binary form. See [Implicit Tiling - Metadata](../3DTILES_implicit_tiling/#metadata). +Most property values are encoded as JSON within the entity. One notable exception is metadata assigned to implicit tiles and contents, stored in a more compact binary form. See [Implicit Tiling - Metadata](../3DTILES_implicit_tiling/README.md#metadata). ### Tileset Properties @@ -433,7 +433,7 @@ Property values may be assigned to individual tiles, including (for example) spa A `3DTILES_metadata` extension on a tile object must specify its class (`class`). Within a `properties` dictionary, values for properties are given, encoded as JSON types according to the [JSON Format](../../specification/Metadata/README.md#json-format) specification. -Metadata assigned to implicit tiles is stored in a more compact binary form. See [Implicit Tiling - Metadata](../3DTILES_implicit_tiling/#metadata). +Metadata assigned to implicit tiles is stored in a more compact binary form. See [Implicit Tiling - Metadata](../3DTILES_implicit_tiling/README.md#metadata). > **Example:** > @@ -564,7 +564,7 @@ Property values may be assigned to individual tile contents, including (for exam A `3DTILES_metadata` extension on a content object must specify its class (`class`). Within a `properties` dictionary, values for properties are given, encoded as JSON types according to the [JSON Format](../../specification/Metadata/README.md#json-format) specification. -Metadata assigned to implicit tile content is stored in a more compact binary form. See [Implicit Tiling - Metadata](../3DTILES_implicit_tiling/#metadata). +Metadata assigned to implicit tile content is stored in a more compact binary form. See [Implicit Tiling - Metadata](../3DTILES_implicit_tiling/README.md#metadata). > **Example:** > diff --git a/next/README.md b/next/README.md index 72abc1cab..078a4c879 100644 --- a/next/README.md +++ b/next/README.md @@ -2,9 +2,7 @@ # 3D Tiles Next -## Overview - -**3D Tiles Next** is a set of new capabilities for the future of 3D Tiles. Provided as draft extensions to the [3D Tiles 1.0](../specification) specification, these features may be incorporated into 3D Tiles 2.0 in the future. +> **Note:** ⚠️ **3D Tiles Next** is a set of draft extensions to the [3D Tiles 1.0](../specification) specification. These extensions have become part of the core specification in 3D Tiles 1.1. Please refer to the [main 3D Tiles 1.1 specification](../specification/README.md) for the latest information about 3D Tiles 1.1 ⚠️ ## Tile Content @@ -15,7 +13,7 @@ _**Overview:** glTF 2.0 assets may be used directly as tile content, without int | Tileset with glTF content | [`3DTILES_content_gltf`](../extensions/3DTILES_content_gltf) (3D Tiles 1.0 extension)
Allows references to glTF models (`.gltf`, `.glb`) directly in `tile.content`, without intermediate formats. Provides easier integration with a wider ecosystem of software producing glTF assets. | | Tileset with multiple contents | [`3DTILES_multiple_contents`](../extensions/3DTILES_multiple_contents) (3D Tiles 1.0 extension)
Allows storing more than one content model per tile, and in effect, per single volume of space. Contents can be organized in various ways — e.g. as map layers or arbitrary groupings — which becomes particularly useful when combined with content group metadata defined by `3DTILES_metadata`. | -glTF content is the future of 3D Tiles, and may be used in place of 3D Tiles 1.0 internal formats (`.b3dm`, `.i3dm`, `.pnts`) in the future. Those internal formats remain available, but glTF offers forward-compatibility with a wider ecosystem of 3D content tools, and with any current and future extensions developed for the glTF format. For technical details on switching to glTF tile content, see the developer [migration guide](../extensions/3DTILES_content_gltf/MIGRATION_GUIDE.md) provided with `3DTILES_content_gltf`. +glTF content is the future of 3D Tiles, and may be used in place of 3D Tiles 1.0 internal formats (`.b3dm`, `.i3dm`, `.pnts`) in the future. Those internal formats remain available, but glTF offers forward-compatibility with a wider ecosystem of 3D content tools, and with any current and future extensions developed for the glTF format. For technical details on switching to glTF tile content, see the developer [migration guide](../specification/TileFormats/glTF/README.md#appendix-a-migration-from-legacy-tile-formats). ## Implicit Tiling diff --git a/next/RESOURCES.md b/next/RESOURCES.md index b7cd4ba95..d8457ef23 100644 --- a/next/RESOURCES.md +++ b/next/RESOURCES.md @@ -1,5 +1,7 @@ ## 3D Tiles Next Resources +> **Note:** ⚠️ **3D Tiles Next** is a set of draft extensions to the 3D Tiles 1.0 specification. These extensions have become part of the core specification in 3D Tiles 1.1. Please refer to the [main 3D Tiles 1.1 specification](../specification/README.md) for the latest information about 3D Tiles 1.1 ⚠️ + **Introduction** * [**Introducing 3D Tiles Next, Streaming Geospatial to the Metaverse**](https://cesium.com/blog/2021/11/10/introducing-3d-tiles-next/) - the announcement of the publication of the 3D Tiles Next specification, summarizing the technical goals and application areas diff --git a/next/reference-card/README.md b/next/reference-card/README.md index cd74039ef..4422c2230 100644 --- a/next/reference-card/README.md +++ b/next/reference-card/README.md @@ -1,6 +1,8 @@ # 3D Tiles Next Reference Card +> **Note:** ⚠️ **3D Tiles Next** is a set of draft extensions to the 3D Tiles 1.0 specification. These extensions have become part of the core specification in 3D Tiles 1.1. Please refer to the [main 3D Tiles 1.1 specification](../specification/README.md) for the latest information about 3D Tiles 1.1 ⚠️ + [![Reference Card pages](../figures/3d-tiles-next-reference-card-pages-combined-3x2.jpg)](../3d-tiles-next-reference-card.pdf) The [**3D Tiles Next Reference Card**](../3d-tiles-next-reference-card.pdf) is an overview of the new extensions that are introduced with 3D Tiles Next. diff --git a/specification/ImplicitTiling/README.md b/specification/ImplicitTiling/README.md index 11c02ea76..4a1efc846 100644 --- a/specification/ImplicitTiling/README.md +++ b/specification/ImplicitTiling/README.md @@ -78,7 +78,7 @@ The following constraints apply to implicit root tiles: * The tile must omit the `children` property * The tile must omit the `metadata` property - * The `content.uri` must not point to an [external tileset](../#external-tilesets) + * The `content.uri` must not point to an [external tileset](../README.md#external-tilesets) * The `content` must omit the `boundingVolume` property ## Subdivision Scheme @@ -127,7 +127,7 @@ Implicit tiling only requires defining the subdivision scheme, refinement strate > > Let the extent of the root bounding volume along one dimension *d* be *(mind, maxd)*. The number of bounding volumes along that dimension for a given level is *2level*. The size of each bounding volume at this level, along dimension *d*, is *sized = (maxd - mind) / 2level*. The extent of the bounding volume of a child can then be computed directly as *(mind + sized * i, mind + sized * (i + 1))*, where *i* is the index of the child in dimension *d*. -The computed tile `boundingVolume` and `geometricError` can be overridden with [tile metadata](#tile-metadata), if desired. Content bounding volumes are not computed automatically but they may be provided by [content metadata](#content-metadata). Tile and content bounding volumes must maintain [spatial coherence](../#bounding-volume-spatial-coherence). +The computed tile `boundingVolume` and `geometricError` can be overridden with [tile metadata](#tile-metadata), if desired. Content bounding volumes are not computed automatically but they may be provided by [content metadata](#content-metadata). Tile and content bounding volumes must maintain [spatial coherence](../README.md#bounding-volume-spatial-coherence). ## Tile Coordinates @@ -268,7 +268,7 @@ Subtrees may also store metadata for tile content. Content metadata exists only Content bounding volumes are not computed automatically by implicit tiling but may be provided by properties with semantics `CONTENT_BOUNDING_BOX`, `CONTENT_BOUNDING_REGION`, `CONTENT_BOUNDING_SPHERE`, `CONTENT_MINIMUM_HEIGHT`, and `CONTENT_MAXIMUM_HEIGHT`. -If the tile content is assigned to a [`group`](TODO) then all contents in the implicit tree are assigned to that group. +If the tile content is assigned to a [`group`](../../specification/README.md#tile-content) then all contents in the implicit tree are assigned to that group. #### Subtree Metadata @@ -302,7 +302,7 @@ Content availability (`contentAvailability`) is an array of content availability Availability may be represented either as a bitstream or a constant value. `bitstream` is an integer index that identifies the buffer view containing the availability bistream. `constant` is an integer indicating whether all of the elements are available (`1`) or all are unavailable (`0`). `availableCount` is an integer indicating how many `1` bits exist in the availability bitstream. -Availability bitstreams are packed in binary using the format described in the [Booleans](../Metadata#booleans) section of the 3D Metadata Specification. +Availability bitstreams are packed in binary using the format described in the [Booleans](../Metadata/README.md#booleans) section of the 3D Metadata Specification. > **Example:** The JSON description of a subtree where each tile is available, but not all tiles have content, and not all child subtrees are available: > diff --git a/specification/Metadata/README.md b/specification/Metadata/README.md index 302df05a7..5b25fe7f2 100644 --- a/specification/Metadata/README.md +++ b/specification/Metadata/README.md @@ -69,7 +69,8 @@ Many domains benefit from structured metadata — typical examples include histo The specification defines core concepts to be used by multiple 3D formats, and is language and format agnostic. This document defines concepts with purpose and terminology, but does not impose a particular schema or serialization format for implementation. For use of the format outside of abstract conceptual definitions, see: -* [3D Tiles Metadata](TODO) - Assigns metadata to tilesets, tiles, and contents +* [3D Tiles Metadata](../../specification/README.md#metadata) - Assigns metadata to tilesets, tiles, and contents in 3D Tiles 1.1 +* [`3DTILES_metadata`](../../../extensions/3DTILES_metadata/) - An extension for 3D Tiles 1.0 that assigns metadata to tilesets, tiles, and contents * [`EXT_structural_metadata`](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_structural_metadata) (glTF 2.0) — Assigns metadata to vertices, texels, and features in a glTF asset The specification does not enumerate or define the semantic meanings of metadata, and assumes that separate specifications will define semantics for their particular application or domain. One example is the [3D Metadata Semantic Reference](./Semantics/) which defines built-in semantics for 3D Tiles and glTF. Identifiers for externally-defined semantics can be stored within the 3D Metadata Specification. diff --git a/specification/Metadata/ReferenceImplementation/PropertyTable/README.md b/specification/Metadata/ReferenceImplementation/PropertyTable/README.md index b14f9402b..b3011ac06 100644 --- a/specification/Metadata/ReferenceImplementation/PropertyTable/README.md +++ b/specification/Metadata/ReferenceImplementation/PropertyTable/README.md @@ -2,7 +2,7 @@ The [3D Metadata Specification](../../README.md) defines schemas as a description of the structure of metadata, and different storage formats for the metadata. One form of storing metadata is that of a [Binary Table Format](../../README.md#binary-table-format), where the data is stored in a binary representation of a table. Each column of such a table represents one of the properties of a class. Each row represents a single entity conforming to the class. The following is the description of such a binary table format, referred to as **property table**. It is used as the basis for defining the metadata storage in the following implementations: -* [3D Tiles Metadata Implicit Tilesets](TODO) - Assigns metadata to tilesets, tiles, groups, and contents in a 3D Tiles tileset. A property table is defined for subtrees of an implicit tile hierarchy, and stores metadata that is associated with the nodes of such a subtree. +* [3D Tiles Metadata Implicit Tilesets](../../../ImplicitTiling) - Assigns metadata to tilesets, tiles, groups, and contents in a 3D Tiles tileset. A property table is defined for subtrees of an implicit tile hierarchy, and stores metadata that is associated with the nodes of such a subtree. * [`EXT_structural_metadata`](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_structural_metadata) — Assigns metadata to vertices, texels, and features in a glTF asset. A property table is defined in the top-level extension object. The property values are stored in standard glTF buffer views. The full JSON schema definition for this implementation can be found in [the PropertyTable directory of the specification](../../../schema/PropertyTable/). @@ -42,7 +42,8 @@ The property table may provide value arrays for only a subset of the properties Each property definition in a property table represents one column of the table. This column data is stored in binary form, using the encoding defined in the [Binary Table Format](../../README.md#binary-table-format) section of the 3D Metadata Specification. The actual data is stored in a binary buffer, and the property refers to a section of this buffer that is called a _buffer view_. -* In the [3D Tiles Metadata](TODO) implementation, a buffer view is defined as part of [subtrees in implicit tilesets](../../../ImplicitTiling/README.md#buffers-and-buffer-views). +- In the [3D Tiles Metadata](../../../README.md#metadata) implementation, a buffer view is defined as part of [subtrees in implicit tilesets](../../../ImplicitTiling/README.md#buffers-and-buffer-views). +- In the [`3DTILES_metadata`](../../../../extensions/3DTILES_metadata/) extension, a buffer view is defined as part of [subtrees the `3DTILES_implicit_tiling` extension](../../../../extensions/3DTILES_implicit_tiling/README.md#buffers-and-buffer-views). - In the [`EXT_structural_metadata`](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_structural_metadata), a buffer view is a standard glTF buffer view. The exact structure of each property entry depends on the [property type](../../README.md#property): @@ -85,4 +86,4 @@ Each buffer view `byteOffset` must be aligned to a multiple of the size of the [ For the `arrayOffsets` and `stringOffsets` buffer views, the property can also define the `arrayOffsetType` and `stringOffsetType`, which describe the storage type for array- and string offsets, respectively. Allowed types are `UINT8`, `UINT16`, `UINT32`, and `UINT64`. The default is `UINT32`. -A property may override the [`minimum` and `maximum` values](../Metadata#minimum-and-maximum-values) and the [`offset` and `scale`](../Metadata#offset-and-scale) from the property definition in the class, to account for the actual range of values that is stored in the property table. +A property may override the [`minimum` and `maximum` values](../../README.md#minimum-and-maximum-values) and the [`offset` and `scale`](../../README.md#offset-and-scale) from the property definition in the class, to account for the actual range of values that is stored in the property table. diff --git a/specification/Metadata/ReferenceImplementation/README.md b/specification/Metadata/ReferenceImplementation/README.md index 6ce115629..8356273f6 100644 --- a/specification/Metadata/ReferenceImplementation/README.md +++ b/specification/Metadata/ReferenceImplementation/README.md @@ -8,6 +8,7 @@ This document defines a reference implementation of the concepts defined in the These serialization formats are used as a common basis for different implementations of the 3D Metadata Specification: -* [3D Tiles Metadata](TODO) - Assigns metadata to tilesets, tiles, and contents +* [3D Tiles Metadata](../../README.md#metadata) - Assigns metadata to tilesets, tiles, and contents in 3D Tiles 1.1 +* [`3DTILES_metadata`](../../../extensions/3DTILES_metadata/) - An extension for 3D Tiles 1.0 that assigns metadata to tilesets, tiles, and contents * [`EXT_structural_metadata`](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_structural_metadata) (glTF 2.0) — Assigns metadata to vertices, texels, and features in a glTF asset diff --git a/specification/Metadata/ReferenceImplementation/Schema/README.md b/specification/Metadata/ReferenceImplementation/Schema/README.md index 6419f9f09..4c9ea5d92 100644 --- a/specification/Metadata/ReferenceImplementation/Schema/README.md +++ b/specification/Metadata/ReferenceImplementation/Schema/README.md @@ -2,7 +2,10 @@ The [3D Metadata Specification](../../README.md) defines [schemas](../../README.md#schemas) as a description of the structure of metadata, consisting of classes with different properties, and enum types. The following is the description of a JSON-based representation of such a schema and its elements. It is used as the basis for defining the metadata structure in the following implementations: -* [3D Tiles Metadata](TODO) - Assigns metadata to tilesets, tiles, groups, and contents in a 3D Tiles tileset. The schema is associated with the tileset. Instances of these classes - referred to as metadata entities - can be associated with elements of the tileset on each granularity level. +* [3D Tiles Metadata](../../../README.md#metadata) - Assigns metadata to tilesets, tiles, groups, and contents in a 3D Tiles 1.1 tileset. The schema is associated with the tileset. Instances of these classes - referred to as metadata entities - can be associated with elements of the tileset on each granularity level. +* [`3DTILES_metadata`](../../../../extensions/3DTILES_metadata/) - An extension for 3D Tiles 1.0 that assigns metadata to tilesets, tiles, and contents + + * [`EXT_structural_metadata`](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_structural_metadata) — Assigns metadata to vertices, texels, and features in a glTF asset. The schema is stored in the top-level extension object. Mesh primitives can be associated with instances of the metadata classes. The full JSON schema definition for this implementation can be found in [the Schema directory of the specification](../../../schema/Schema/). diff --git a/specification/Metadata/Semantics/README.md b/specification/Metadata/Semantics/README.md index d071a4beb..7acd483ee 100644 --- a/specification/Metadata/Semantics/README.md +++ b/specification/Metadata/Semantics/README.md @@ -10,7 +10,8 @@ Each semantic is defined in terms of its meaning, and the datatypes it may assum For use of semantics, see: -* [3D Tiles Metadata](TODO) - Assigns metadata to tilesets, tiles, and contents +* [3D Tiles Metadata](../../README.md#metadata) - Assigns metadata to tilesets, tiles, and contents in 3D Tiles 1.1 +* [`3DTILES_metadata`](../../../extensions/3DTILES_metadata/) - An extension for 3D Tiles 1.0 that assigns metadata to tilesets, tiles, and contents * [`EXT_structural_metadata`](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_structural_metadata) (glTF 2.0) — Assigns metadata to vertices, texels, and features in a glTF asset ## General @@ -48,7 +49,7 @@ Units for all linear distances are meters, and all angles are radians. Semantic|                                 Type                                 |Description --|--|-- `TILESET_FEATURE_ID_LABELS`||The union of all the feature ID labels in glTF content using the [`EXT_mesh_features`](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_mesh_features) and [`EXT_instance_features`](https://github.com/CesiumGS/glTF/tree/3d-tiles-next/extensions/2.0/Vendor/EXT_instance_features) extensions. -`TILESET_CRS_GEOCENTRIC`||The geocentric coordinate reference system (CRS) of the tileset. Known values include, but are not limited to:`region` bounding volumes are assumed to use the same reference ellipsoid as the geocentric coordinate reference system specified here.

For more details on coordinate reference systems in 3D Tiles, see [Coordinate Reference System (CRS)](../../#coordinate-reference-system-crs). +`TILESET_CRS_GEOCENTRIC`||The geocentric coordinate reference system (CRS) of the tileset. Known values include, but are not limited to:`region` bounding volumes are assumed to use the same reference ellipsoid as the geocentric coordinate reference system specified here.

For more details on coordinate reference systems in 3D Tiles, see [Coordinate Reference System (CRS)](../../README.md#coordinate-reference-system-crs). `TILESET_CRS_COORDINATE_EPOCH`|