I’m trying to pick features from glTF model with EXT_mesh_features and EXT_structural_metadata extensions.
I was unable to pick features, despite the fact that code works well for sample file
I take this sample model and replaced id of right bottom quad from 1 to 5 in the buffer and I also used shader that colors feature 1 into white and feature 5 into yellow. See sancastle example
Shader sees feature id 5, but the quad is not pickable (pick function returns undefined).Then I noticed, that scene.view.pickFramebuffer._context._pickObjects array actually contains all 4 features, but the feature for right bottom quad is with id 1. My assumption is that picking takes features from EXT_mesh_features` and assigns consequent ids to pickObjects, but is unable to match it with actual id from buffer if it differs.
This may be somehow related to this comment.
So the questions are next:
Is my assumption correct? (If yes - the most obvious workaround is using consequent feature ids in EXT_mesh_features and put the real ones into property table).
Is this intended behaviour or temporary unresolved technical challenge? (This will help me to understand if I need to monitor further changes on this or just use workaround permanently).
(This is an empty property table, i.e. one without properties, and that’s OK, as the current workaround for the issues that you linked to, and the ones that are linked from that).
But… it has a count: 4. When you assign feature ID 5, then this ID is not a valid index for this property table.
(This causes the corresponding ModelFeature to not be created, resulting in the undefined that you see - for details about the picking mechanism, @ptrgags might have to chime in here, but that its what it roughly looks like for me right now)
Changing the count: 4 to count: 6 should solve the issue for now.
You’re right! I didn’t pay attention that without explicitly set ID property the feature ID would be the row index and didn’t consider that empty table may be attepted to access. Now it totally makes sense.
Thanks a lot!
Good to hear that. But even if it makes sense now, the empty property table is a workaround, and when the linked issue is resolved, it should be possible to basically have “arbitrary” integer values as IDs. (One could say that the goal of resolving the issue would be to allow real IDs to be stored, and not have to interpret them as indices).