Per feature bounding volume information

[mramato]

Feel free to close this if it is already an issue being discussed elsewhere, but I spoke with @lilleyse offline and he felt it was needed as well.

Currently, unless a tileset explicitly adds custom batch table entries with extra information, it's impossible to get any sort of bounding volume information on a given feature. For my use case, I want to be able to easily zoom to any arbitrary feature in Cesium. @lilleyse says that he could use such information to greatly improve shadows for Cesium's 3D Tiles implementation.

While this can be solved with custom batch table entries, that is an implementation specific detail and will not always be portable to different 3D Tiles implementations. Ultimately, I just want to be able to take any valid 3D Tiles tileset and be able to get bounding information per-feature, without having to know any special sauce specific to that tileset. I suspect others will as well.

[pjcozzi]

Could be reasonable to make this a well-known semantic in the feature table. Would probably want to support the same BVs that each tile supports. Would also need an explicit feature table in b3dm, which I expect we would want to do anyway, e.g., for storing tile metadata when using explicit tiling schemes.

Will be a bit before we can get to this, but labeled draft 1.0.

[pjcozzi]

Pushing post 1.0. This can go in after without breaking backwards compatibility.

[lilleyse]

@rahwang you can start experimenting with this for physics volumes before this becomes final. You'll need to pre-process any tilesets and then in the Cesium implementation read the bounding volumes and add to Cesium3DTileFeature.

Some ideas from the spec side -

Option 1 - separate

{
    BATCH_LENGTH : 3,
    BOUNDING_VOLUME_SPHERE : [1.0, 0.5, 2.0, 10.0, 2.0, 0.5, 2.0, 10.0, 3.0, 0.5, 2.0, 10.0],
    BOUNDING_VOLUME_REGION : [...],
    BOUNDING_VOLUME_BOX : [...]
}

Where:

• BOUNDING_VOLUME_SPHERE is a packed array of spheres (4 elements each)
• BOUNDING_VOLUME_REGION is a packed array of regions (6 elements each)
• BOUNDING_VOLUME_BOX is a packed array of boxes (12 elements each)

The feature table can include any or none of these.

Option 2 - mix and match

{
    BATCH_LENGTH : 3,
    BOUNDING_VOLUME : [[1.0, 0.5, 2.0, 10.0], [-1.0, 2.34, -1.1, 2.35, 0, 100], [0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]]
}

This relies on identifying the bounding volume type by its array length and does not make it easy to store in the binary section.

Option 3 - mix and match packed

{
    BATCH_LENGTH : 3,
    BOUNDING_VOLUME : [1.0, 0.5, 2.0, 10.0, -1.0, 2.34, -1.1, 2.35, 0, 100, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0],
    BOUNDING_VOLUME_TYPE : [0, 1, 2]
}

Where 0 is sphere, 1 is region, 2 is box.
If all the bounding volumes are the same, it could be simplified to:

{
    BATCH_LENGTH : 3,
    BOUNDING_VOLUME : [1.0, 0.5, 2.0, 10.0, 2.0, 0.5, 2.0, 10.0, 3.0, 0.5, 2.0, 10.0],
    BOUNDING_VOLUME_TYPE : 0
}

Option 1 is the simplest and easiest. Are there enough good use cases for supporting mixed bounding volume types? Option 3 isn't bad either.

[rahwang]

Awesome! I'll start experimenting with this as soon as I finish my current issue.

[pjcozzi]

@lilleyse will the implementation for this be as simple as a well-known semantic that is stored in feature metadata, #430? Would still want to keep this issue open until the semantic is defined and implemented.

[lilleyse]

@pjcozzi yes, that's the intended approach.

[lilleyse]

Per-feature bounding volumes could be stored in feature metadata in EXT_mesh_features with new semantics

[donmccurdy]

Does the addition of a new semantic, e.g. FEATURE_BOUNDING_BOX, require a new extension (either to glTF or 3D Tiles?) or can the semantic be defined in some standalone way?

[mramato]

@lilleyse if I'm understanding this correctly while the low-level capability is now there, there is not a standard way for using it? For example, if someone hands me a 3D Tiles tileset that I know nothing about, is it possible for me to zoom to a specific feature on click and/or know that the tileset has the necessary information for doing it? If there is not some standard schema then that sounds like this has the same problems that using the original batch table had. Or am I misunderstanding the solution and this is in fact, now turnkey?

[lilleyse]

Closed this a bit hastily. The low-level capability is there, but a new feature semantic would need to be defined in the 3D Metadata Semantics Reference or some other semantic dictionary, and this issue can stay open until that happens. The exact details of this need to be refined further. @donmccurdy I included your question in #574.

tileset.json would declare the feature's class building and a property with the FEATURE_BOUNDING_BOX semantic. The actual bounding box data would be stored in the glTF payload with EXT_mesh_features, which would refer back to the same schema.

There are still other details to work out, like how does tileset JSON mandate that all features conform to this class, or at least have a property with this semantic.

{
  "schema": {
    "classes": {
      "building": {
        "name": "Building",
        "description": "Information about a building",
        "properties": {
          "boundingVolume": {
            "type": "ARRAY",
            "componentType": "FLOAT32",
            "componentCount": 12,
            "semantic": "FEATURE_BOUNDING_BOX"
          },
          "owner": { ... },
          "floors": { ... }
        }
      }
    }
  }
}

[donmccurdy]

The other issue here might be, once I know that I want to find a feature with ID X, I don't know which tile it's in, and streaming all of the glTF files to check the contents of EXT_mesh_features isn't ideal. We could solve that with a few arrangements:

• (A) all tile contents share the same Property Table buffer; fetch any tile with content and we can look up the feature by its ID, read the property with the FEATURE_BOUNDING_BOX semantic, then zoom to the tile(s) associated with that bounding volume.
• (B) tileset somehow has direct access to the Property Tables used by tile contents (not in spec)

[lilleyse]

all tile contents share the same Property Table buffer

I've been thinking about this is well for global feature ids #265. Ideally we'd want to have spatial locality of metadata so that each content can point to a contiguous subset of the global property table, but I don't think it will be this clean in practice. I wonder if a database is a better form factor for global metadata.

[donmccurdy]

TileDB Reading docs get into multi-range queries a bit, and it's an interesting read. But yeah, this feels like a complicated thing to standardize where perfectly good solutions like databases work well.