-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ValidFeatureIdAttributeWithLargerFeatureCount.gltf not valid #294
Comments
This may indeed look confusing at the first glance, referring to the specification that says
But such a file is valid, because not all "IDs for 'identified features'" necessarily have to appear in a specific attribute or texture. For example, you might have feature IDs like
(meaning that the (I also got it wrong initially, and did a |
ah so in this case the file is valid (there is no nullFeatureId) - because this rules applies "when there is no nullFeatureId, then the number of values (4) may not be larger than the featureIdCount (123)" |
Yes. We should consider elaborating this a bit in the specification, i.e. emphasizing that
For example:
|
I’m also questioning the relation with primitives: suppose there are two meshPrimitives, one with 1 triangle with FeatureId = 0 , other meshprimitive has 2 triangles with featureid = 1 and featureid = 2 What should the FeatureCount be? 3 in both primitives I suppose now? Before, I thought 1 for the first primitive and 2 for the second (because FeatureCount is property of featureid of the meshprimitive) If it’s 3, we could/should check that the FeatureCount is the same when there are multiple primitives (even with a NullFeatureId specified somewhere??). |
I'll probably have to cross-check my assumptions with the specification and some internal discussion. The number of distinct feature ID values that appear in an attribute or texture is somewhat "independent" of the Referring to your example: There are two mesh primitives. Both of them have feature ID definitions. These definitions each refer to one
These values are just "arbitrary" identifiers. The specification does not really impose any constraints or meaning here. So when you access the feature ID definitions with pseudocode like this
then these are independent objects, and they do not need to have the same The
It would not be valid to assume this. But... not everything that is "theoretically possible" will necessarily make sense in practice. For example, you could have a glTF asset where
and all of these feature ID definitions have a different In practice, one can probably say that...
The idea here would be to have something like (pseudocode):
This could, for example, be IDs for buildings:
There may be a glTF asset where none of the primitives really contains all of the 10 materials. But the one who created this glTF asset did set the |
ok, thanks for the explanation, but must say the definition featureCount = number of distinct features in the asset (without nullFeatureId) is much more simple/clear/exact to me... |
Yeah... I cannot point my finger at "THE" exact reason for why the On one hand, this would be a somewhat weak justification: The quirks of the picking system of one client should not affect a generic specification on this level. On the other hand, it's not totally unreasonable to have that information. Otherwise, you'll load a glTF and obtain the feature ID values, and receive the values From that perspective, the main functionality of the extension is: "These are different things when they have different IDs". Everything beyond that has to be managed on another level. For example, the exact meaning of the IDs - i.e. "What is the 'feature' that is identified with the value This was actually an explicit request from the early user/customer feedback/review pass, and one of the reasons for why EDIT: I just opened CesiumGS/3d-tiles#756 to better keep track of this. (Not sure whether it will be considered to be "important", but maybe it can be tackled together with other, smaller issues in some cleanup pass at some point) |
I hope it's OK to close this in favor of CesiumGS/3d-tiles#756 |
I think the file ValidFeatureIdAttributeWithLargerFeatureCount.gltf (https://github.com/CesiumGS/3d-tiles-validator/blob/main/specs/data/gltfExtensions/meshFeatures/ValidFeatureIdAttributeWithLargerFeatureCount.gltf) is not valid, because the featureCount (123) does not correspond to the number of features in the attribute (4)
The text was updated successfully, but these errors were encountered: