Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added option to assign metadata to nodes #63

Merged
merged 3 commits into from
Apr 5, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 35 additions & 3 deletions extensions/2.0/Vendor/EXT_structural_metadata/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -38,7 +38,8 @@ Written against the glTF 2.0 specification.
- [Property Tables](#property-tables)
- [Property Attributes](#property-attributes)
- [Property Textures](#property-textures)
- [Binary Data Storage](#binary-data-storage)
- [Binary Data Storage](#binary-data-storage)
- [Assigning Metadata](#assigning-metadata)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels more appropriate for the Assigning Metadata section to go before Binary Data Storage

- [Optional vs. Required](#optional-vs-required)
- [Schema](#schema-1)
- [Revision History](#revision-history)
Expand Down Expand Up @@ -230,7 +231,7 @@ The following sections describe these storage formats in more detail.

Each property table defines a specified number (`count`) of metadata entities conforming to a particular class (`class`), with property values stored as parallel arrays in a column-based binary layout. Property tables support a richer variety of data types than glTF accessors or GPU shading languages allow, and are suitable for datasets that can be expressed in a tabular layout.

Property tables are defined as entries in the `propertyTables` array of the root-level `EXT_structural_metadata` extension, and may be referenced by other extensions.
Property tables are defined as entries in the `propertyTables` array of the root-level `EXT_structural_metadata` extension, and may be referenced by [assigning metadata](#assigning-metadata) to glTF elements, or by other extensions.

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. Each property value array given by the property table must be defined by a class property with the same alphanumeric property ID, with values matching the data type of the class property.

Expand Down Expand Up @@ -516,7 +517,7 @@ Certain property types cannot be encoded in property textures. For example, vari
> value[1] = byte2 | (byte3 << 8);
> ```

## Binary Data Storage
### Binary Data Storage

Property values are stored in a compact binary tabular format described in the [3D Metadata Specification](https://github.com/CesiumGS/3d-tiles/tree/main/specification/Metadata), with each property table array occupying a glTF buffer view. `EXT_structural_metadata` imposes 8-byte binary data alignment requirements on an asset, allowing support for 64-bit data types while remaining compatible with the 4-byte alignments in the core glTF specification:

Expand All @@ -525,6 +526,37 @@ Property values are stored in a compact binary tabular format described in the [

As a result, byte length of the `BIN` chunk may be up to 7 bytes larger than JSON-defined `buffer.byteLength` to satisfy alignment requirements.

## Assigning Metadata

*Defined in [EXT_structural_metadata.schema.json](./schema/EXT_structural_metadata.schema.json).*

When property values are stored in a [Property Table](#property-tables), then the entries of this table may be referenced from within the glTF asset: Each `node` of the glTF asset can contain an `EXT_structural_metadata` object that defines the source of the metadata values for this node. It contains the `propertyTable`, which is the index of the property table in the array of property tables of the root-level `EXT_structural_metadata` extension object, and the `index`, which is the index of the row in this table that contains the metadata values for the respective node.

> **Example:**
>
> An example of metadata that is assigned to a node. It associates the given node with the metadata values that are stored in row 4 of the property table with index 1, referring to the array of property tables that are defined in the top-level `EXT_structural_metadata` extension object.
>
> ```jsonc
> {
> "extensions": {
> "EXT_structural_metadata": {
> "schema": { ... },
> "propertyTables": [ ... ]
> }
> },
> "nodes": [
> ...
> {
> "name": "A node with metadata",
> "EXT_structural_metadata": {
> "propertyTable": 1,
> "index": 4
> }
> }
> ]
> }
> ```

## Optional vs. Required

This extension is optional, meaning it should be placed in the `extensionsUsed` list, but not in the `extensionsRequired` list.
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "EXT_structural_metadata.schema.json",
"title": "EXT_structural_metadata glTF extension",
"type": "object",
"description": "Structural metadata about a glTF element.",
"allOf": [
{
"$ref": "glTFProperty.schema.json"
}
],
"properties": {
"propertyTable": {
"type": "integer",
"minimum": 0,
"description": "The index of the property table containing per-feature property values."
},
"index": {
"type": "integer",
"minimum": 0,
"description": "The feature index (row index) used for looking up property values for this element."
},
"extensions": {},
"extras": {}
}
}