Add 3DTILES_content_gltf_vector

[donmccurdy]

For #825. Defines "vector data" as applied to 3D Tiles, and methods of encoding and decoding vector data to/from glTF content.

The extension provides some fundamental structures (buffer regions, clipping) without which common visual styles would not be possible, but the extension otherwise leaves styling undefined, to be provided by current and future iterations of the 3D Tiles styling specification, and/or explored further by client implementations.

[donmccurdy]

Question — which of the following do we want to allow?

1. Multiple vector "layers" in a tileset, represented e.g. as distinct glTF Nodes
2. The same 3D Tiles tileset containing multiple contents, some vector layers, others non-vector glTF content, e.g. gaussian splats
3. The same 3D Tiles content (i.e. glTF asset) containing both vector layers and non-vector glTF content, e.g. gaussian splats

I suspect yes on (1), but I'm not sure about 2 and/or 3.

[weegeekps]

3 seems messy. From a spec standpoint either 1 or 2 should be okay.

[donmccurdy]

Agreed — if we needed (3) I suppose we'd need to either navigate the messiness of specifying which part of the content is which, or push some or all of this specification down into a glTF extension instead of a 3D Tiles extension. But defining "what is a vector, and how does it interact with tile boundaries" feels messy to define at the glTF level, without reference to geospatial concepts and 3D Tiles styling.

So I think I'd lean toward 1+2 but not 3, perhaps.

[danielzhong]

I understand these cases, but wouldn't it be simpler to remove the vector：true flag and only detect whether the extension is present? For example:

// Vector content — extension present
"contents": [
  {
    "uri": "splats.glb"
    // No extension → not vector
  },
  {
    "uri": "roads.glb",
    "extensions": {
      "3DTILES_content_gltf_vector": {}   // Extension present → vector
    }
  }
]

[weegeekps]

That's a great point. Does a valid case exist where vector may be set to false, @donmccurdy?

[donmccurdy]

I don't know if there's a similar precedent in 3D Tiles, but in glTF the convention is that an extension attached to a core property should:

1. Have no effect on the core, parent property unless non-default extension properties are assigned
2. Use behaviors and property naming conventions so that the extension could (hypothetically) be promoted into core without changes

I can't find a link to the discussion off-hand, but I believe Ed Mackey originally articulated this goal. The extension KHR_materials_unlit was designed before that, and is the main exception I'm aware of.

Do we want 3D Tiles to follow a similar convention? In that case we'd want to design as if the extension could be collapsed onto the content object in the future:

  {
    "uri": "roads.glb",
    "vector": true
  }

[lilleyse]

Just a few minor comments. Everything looks good at a high level.

[bjornblissing]

What constitutes a “feature” for points?

• Is each vertex a feature?
• Can one feature be represented by multiple points?
• If a feature can be multi-vertex, how is feature membership encoded?

[donmccurdy]

All good questions, thanks! After re-reading this, I believe perhaps the word "feature" should be avoided here and elsewhere in this extension, except under the "Feature IDs and Properties" non-normative section below. Instead we should use the terms like "point geometries" or "point topological primitives", as distinct from glTF mesh primitives.

To your questions, though, the intention is that feature membership is defined separately by KHR_mesh_features. Vertex/feature mappings may be 1:1, 1:N, N:1, or N:N. But certainly the most common would be 1:1, or N:1 (e.g. many vertices share the same _FEATURE_ID_n attribute).