EXT_mesh_features extension ignoring my class/table definitions, always looking up in propertyTable at index 0

[arneschilling]

Hi, I have produced a 3D Tiles 1.1 dataset, which is shown in the following example

Sandcastle example: https://sandcastle.cesium.com/#c=jZJvb9owEMa/ipUXVZA2pwQVUY1Wy6BlYQVGG9oG5Y1JTHHi2JntQJOp333OH7Z22qa9suz73XN3z9mywEQgpsAIS5Kn0zuAwhBLCRQHBc8FIJwBJCVWMmANA13OYIS3KKfKqWGPJ5iBCxAYuJjuNpOQLMjUXZVud05c6bLbs3Dk9t0ke7wfTc+hhr5Fk0RD7qmfXifrdE1n5PTMt693N94tmcdL5T+sqV+clgsvsf14Zs8m82TmOeRmNM3WWmwWP9mzeKnF5/Gm94mGhdt/0MXDnlsxzC+mUcX6j0uyiK+6C++qmJerch7vzuEY+9x5z9wBHvt2vikO5eh8tVncdseR8/XzWRENvCVbO1+2+6vA+BCwkDOpwJ7gAxZ6TIYPrV3wvn4zAyOs7yPOFCIMi8Do6LyAKVGA7wEDoJFQhGJtpdZAB0SOpsPm6I29Jgy3gqfaZKey3Y1Muzfo9+1BpQjaLqAMMcMwEyQliuyxhCiKzFa+AZsKLV5ynnr8NVAhlgWcLKMFUDsM2o0CqQqKAdkCnY2fiawWf+wfPyuBpG6/FYL1z4DNc11V55nVCY6zaVltSGQ2TAecnPwjDPVv+w/k+PvuqlY7FdxpXAY/G2umeLOr1y7XmX9VrCd5CdgLCJEKd8DEQnDR+bVJTjGk/Kl917iGjXfGsK56WVEfSZpxoUAuqAmhpXCaUaSwtDZ5mOj+QimrvKF1TBlGZA9IdPGHrwRCqn3WkW1O6R0pcWBcDi3Nv0mjHEWEPS32WFBUaKRqY7jrXt40AQjh0NLXqujvuYpzukHile4P

I was trying to use the EXT_structural_metadata and EXT_mesh_features extensions for attaching attributes to individual objects. In this case buildings, bridges, terrain etc. For each of these feature type i defined a different metadata class. You will find 8 different classes in the glb file. Each class is referenced by a property table, so its a 1 to 1 relationship in this example. The property tables are referenced by the EXT_mesh_features extension in the mesh primitives via the propertyTable index. In this example there is also only one _FEATURE_ID_0 to make is easier to understand.
Currently the wrong metadata is picked and shown in the table and I am wondering why that is. For example when picking the terrain, Cesium should look up in propertyTable at index 4, which contains only one feature. Instead, something else is picked.
In the code I could see that the index for retrieving the propertyTable is somehow attached to the model, not to the primitive as it should be.
see https://github.com/CesiumGS/cesium/blob/1.112/packages/engine/Source/Scene/Model/Model3DTileContent.js#L125
I am not sure, but this is the only place I found from where the propetytable index is retrieved. featureTableId is only set once upon loading the model. In my case its always 0, meaning the other tables are ignored.

Browser: Edge

Operating System: Windows10

br & thanks,
Arne

[ggetz]

@javagl Would you mind chiming in here and let us know if this is expected behavior, or a bug in the CesiumJS implementation?

[javagl]

I had seen this issue, and already had a short look at the data, and I'm reasonably sure that this is indeed an issue in CesiumJS. In fact, I had created a

TODO Create sample for #11683

in my to-do-list. Your comment moved that one to the top. The following is the attempt of creating a "minimal example" to reproduce the issue:

cesiumjs-issue-11683.zip

(It contains the GLB, the JSON of the GLB, a tileset.json and a sandcastle, and the code that was used for generating the example)

It contains four mesh primitives.

• The left ones refer to propertyTable: 0, which refers to exampleClassA, with an example_STRING property
• The right ones refer to propertyTable: 1, which refers to exampleClassB, with an example_FLOAT32 property

But still, when accessing the data, they are all using the first property table:

I haven't zoomed toooo deeply into the code yet, but think that Arne is on the right track: The property table handling (including the ~"legacy" aspects of a getter called batchTable returning a featureTableId which is actually a property table index) seem to revolve around the model (i.e. the whole glTF file). The fact that the EXT_mesh_features exist for each glTF mesh primitive is not anticipated there.

[ggetz]

Thanks for the explanation @javagl!

[ptrgags]

Some more context: CesiumJS only supports one property table at a time in the current implementation. You can select a different table using Model.featureIdLabel (and for instances, Model.instanceFeatureIdLabel), but you cannot use more than one simultaneously.

This is noted in the Metadata compatibility matrix issue, though I'm fuzzy on the reason for only supporting one at a time. Certainly our picking system has scalability limitations, but I'm not sure if it was related or something else.

[javagl]

This has also been reported in https://community.cesium.com/t/upgrade-3d-tileset-with-composite-cmpt-tile-to-1-1-attribute-data-missing/33177/2 , with additional test data sets.