I am currently working on a system to inject feature IDs through EXT_Mesh_Feature extension by cesium into .glb models to be used with 3DTile. These .glb models are converted from a .IFC file through another system.
The plan is to only inject IDs into a .glb files per primitive through building an accessor named _FEATURE_ID_0 and adding the EXT_Mesh_Feature extension. While extracting the metadata from the .IFC file (each data tagged with the respective IDs injected into the .glb model) into a metadata.json file to be stored or imported into an external database (or something similar).
I understand the existence of EXT_Structural_Metadata, but would like to avoid using that for now due to external reasons, and the potential of significantly increasing the size of the glb model.
I have checked that the .glb model has the extension EXT_mesh_features, and each primitive have their own _FEATURE_ID_0 accessor with the meshfeature extension pointing to it with “attribute = 0”.
However, when i tried to test model picking on a cesiumJS application, I cannot seem to be able get the ID from the model, the picked variable is always of a type of “object” instead of any form of 3DTileFeature or ModelFeature. (or i might be using the wrong type)
I found these links to issues and discussions that was open quite awhile ago, stating that I might have to create a blank property table using EXT_Structural_Metadata for cesiumJS to build those TileFeatures object and expose the underlying feature ID.
May I check if that work around is still the way to go about this at this current time, and I cannot just use EXT_Mesh_features alone and retrieving IDs to query an external database?
Additional info:
I have used the same code to test getting the feature ID through picking on another model, which I had previously generated with both EXT_Mesh_Features and EXT_Structural_Metadata, and it was able to give me the featureID from my picked part of the model mesh.
With that I would like to further clarify my question above^
I found these links to issues and discussions that was open quite awhile ago, stating that I might have to create a blank property table using EXT_Structural_Metadata for cesiumJS to build those TileFeatures object and expose the underlying feature ID.
May I check if that work around is still the way to go about this at this current time, and I cannot just use EXT_Mesh_features alone and retrieving IDs to query an external database?
The library i am using to export the glb models seems to have guards against empty property tables, having to need to insert a single property column which would increase the file size.
May I just double check that cesiumJs will not have any issues with an empty property table? If so, I might change to use a custom script instead of the library to add the EXT_Structural_Metadata in.
An empty property table shouldn’t cause any issues. The property table schema allows you to omit the properties field if your class does not have any properties.