Gltf feature extensions support in Cesium Ion

Cesium ion
1

Hi,

In CesiumJS I’m trying to achieve per-primitive interaction with assets tiled and loaded from Cesium Ion.

I planned to use Cesium’s GLTF extensions (EXT_mesh_features and EXT_structural_metadata).
It works fine when I load models directly with Cesium.Model.fromGltf method.

However I face next issues when using model uploaded to Cesium Ion (gltf model to 3D Tiles):

  1. When upload model with only EXT_mesh_features extension used, EXT_mesh_features information is removed from primitive extensions object after tiling. It’s still present in extensionsUsed list. I used this sample model - asset id 1583753
  2. When upload model with both EXT_mesh_features and EXT_structural_metadata extensions - it fails to process with ERROR status and Internal Error description. I used this sample model - asset id 1584734
  3. (Probably related to CesiumJS, not Cesium Ion, but maybe someone has thoughts on this). Model with only EXT_mesh_features extension is not recognized as instance of Cesium.ModelFeature or Cesium.Cesium3DTileFeature, so I can’t retrieve feature id from picked element (similar topic). However, it does work well if both EXT_mesh_features and EXT_structural_metadata extensions are present. See sandcastle example

Issue #1 looks like something described in this topic. If it’s so and this going to be resolved in 3D Tiles Next - is there any information about planned release dates or ability to access the beta version?

As for #2 or #3 - I would be grateful for any tips on these.

Thanks,

Pavlo

2

Hi @pavlo

To answer your first two questions, the 3D Model → 3D Tiles pipeline doesn’t currently preserve per-feature information, whether it’s coming from EXT_mesh_features / EXT_structural_metadata or from glTF nodes. It’s a common feature request and one of the things we hope to look at after we launch the new photogrammetry pipeline.

Those are still valid bug reports though: the extension should not be included in extensionUsed and the second model should not crash.

For your third question, see these related issues:

The crux of the issue is that since feature ids can be arbitrary values (including very large values) we aren’t able to pre-allocate ModelFeature objects like normally do when a property table and count are known. The workaround is to add the EXT_structural_metadata extension with an empty property table (a count, but no properties).

I’ll mention this post in the second issue just see we can keep track of this.

Thanks!

2 Likes