Issue with EXT_structural_metadata and EXT_mesh_features in 3D Tiles Models

Hi everyone,

I’m currently encountering an issue with the EXT_structural_metadata and EXT_mesh_features extensions in my 3D Tiles models. It seems like only the index 0 of propertyTable is being used.

I came across a similar post on the forum:

However, I’m not entirely sure if it’s the same issue in my case. Could someone confirm or provide more insights?

I’ve attached an example file here for reference:

N43E005_D101_S001_T001_L2_U1_R0.gltf (260.7 KB)

Thank you in advance for your help!

The issue that the other thread links to (EXT_mesh_features extension ignoring my class/table definitions, always looking up in propertyTable at index 0 · Issue #11683 · CesiumGS/cesium · GitHub) might be related, but I’m not entirely sure. You said

It seems like only the index 0 of propertyTable is being used.

The glTF file that you attached seems to have only one class and one propertyTable, so it might not be exactly the same issue.

Can you describe in more detail what you expect and what the actual (unexpected) behavior is?

I have a glTF file with three distinct sets of metadata, (witch come from 3 PointFeatures of a shapefile) and I want to assign each set to different primitive. However, no matter how I try assign the metadata with EXT_mesh_features, when I load the model in CesiumJS, all the primitives seem to use only the metadata from propertyTable index 0.
I’m wondering if i misunderstood how to correctly assign the metadata or if it’s something else.

I think that there currently is no specific plan for how to fix the linked issue, and when you combine multiple property tables in one glTF, then this may be difficult to avoid.

When you are only talking about three primitives, then one workaround might be to store each primitive on its own glTF file (with that one then only containing a single property table). I know that this may not be ideal (and may not scale well when there are dozens or hundreds of primitives), but do you think that this might be a feasible solution for your case?