EXT_mesh_features Clarification: How many feature ids does an indexed geometry have when ids are implicitly derived?
gkjohnson opened this issue · 7 comments
Hello! I had a question about the EXT_mesh_features specification - specifically this section describing what happens when vertex indices are implicitly used as feature ids:
When both featureId.attribute and featureId.texture are undefined, then the feature ID value for each vertex is given implicitly, via the index of the vertex. In this case, the featureCount must match the number of vertices of the mesh primitive.
The question is: When a geometry contains an "index" buffer that references and reuses vertex attributes - is the position in the "index" buffer used to derive the id? Or the index in the vertex attribute buffer? In other words, does a quad with 4 vertices and an index buffer defining two triangles have 4 unique feature ids? Or 6?
Thank you!
The IDs are given by the indices of the vertices (and not by the 'indices' that are used for defining the topology).
In your image, this is the case on the left hand side. There are 4 unique IDs in this case.
(When two triangles share one vertex (position), then this vertex will have to be duplicated when it has different normals or texture coordinates in both triangles, and consequently, may then also have different feature IDs. But generally, the ID is the 'index in the vertex attribute array', so to speak. This does raise some further questions about how to handle these IDs within a triangle - related to #764 ).
Great thanks - this lines up with what gl_VertexId provides in the vertex shader, as well. It might be worth adding a clarifying comment on this is supposed to interpreted.
Also, as an aside, is there a notional use case for why this kind of implicit id generation exists? How would it be used in practice? It doesn't seem super useful to me.
The two main use cases are POINTS primitives and instanced models (see EXT_instance_features, which also has implicit ids).
Probably less likely to see it for triangles and lines.
Got it - instanced models makes sense. What's the more concrete use case for having a unique id for every point, though? I'm imagining point clouds with potentially millions of points - it makes a lot more sense for points to be grouped by common features in this case (ie all the points that make up a scanned tree). Are points being used as location identifiers, for example? Named restaurant or building locations like in Google Maps, for example?
Just trying to make sure I understand the cases where these features are used.
Yes, annotations are one of the main use cases for implicit feature ids for points.
I think that the main question is answered here, and assume that this can be closed.
(There are related questions like #764 that have to be addressed independently)
Yup! Sorry I neglected to close it. The one thing I was going to mention is that it may be worth explicitly stating in the specification that the intended use case for these implicit feature ids is for use with point primitives.