Comments (8)
Yes. We should consider elaborating this a bit in the specification, i.e. emphasizing that
- the
featureCount
is the number of identifiable features, regardless of whether all IDs are 'used' in one specific attribute/texture - the
featureCount
does not include thenullFeatureId
For example:
- There could be IDs like
[0, 1, 2]
in an attribute, but thefeatureCount
could still be10
(meaning that not all IDs are used) - There could be IDs like
[0, 1, 2, 99]
in an attribute, even when thefeatureCount
is only3
- namely when99
is thenullFeatureId
from 3d-tiles-validator.
Yeah... I cannot point my finger at "THE" exact reason for why the featureCount
was introduced in this exact form (beyond the message in the change log). I'm about 80% sure that it is related to ~"the picking functionality in CesiumJS". Roughly: The Picking system of CesiumJS might need information about ~"how many different 'things' it has to expect there".
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 [12, 34, 56789]
, but don't know the "domain" of the feature ID values. Having the information: "These are 3 values, and in total there may be featureCount=10
values" does not harm (even though it does not really tell you explicitly which other IDs might be there, and most clients might not need that information...)
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 56789
?"
This was actually an explicit request from the early user/customer feedback/review pass, and one of the reasons for why EXT_mesh_features
was promoted into its own extension: People wanted to assign "some (arbitrary) value" to these elements, and leave the interpretation of this value to the application layer. This is mentioned in the last section of the specification, with this image:
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)
from 3d-tiles-validator.
This may indeed look confusing at the first glance, referring to the specification that says
The definition also includes a
featureCount
value, which is the number of unique features that are identified.
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
- 12 = Water
- 23 = Grass
- 34 = Sand
- 45 = Concrete
(meaning that the featureCount
would be 4). But you then might have an accessor that models the geometry of a beach, and there, only 'Water' and 'Sand' will appear.
(I also got it wrong initially, and did a ===
check. But this was explicitly fixed in bbe0130#diff-077b29d7c199f4aa7053f1f1ceba31584d101cb6a0c78cc8c21ad9ec1fbbd4aaL532 , following the comment from #280 (comment) )
from 3d-tiles-validator.
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)"
from 3d-tiles-validator.
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??).
from 3d-tiles-validator.
I'll probably have to cross-check my assumptions with the specification and some internal discussion.
Until then, with the disclaimer that the following is only my current understanding:
The number of distinct feature ID values that appear in an attribute or texture is somewhat "independent" of the featureCount
. The only constraint that that number may not be larger than the featureCount
.
Referring to your example:
There are two mesh primitives. Both of them have feature ID definitions. These definitions each refer to one attribute
of the respective mesh primitive. This attribute contains the actual numeric feature ID values.
- For one mesh primitive, there are feature ID values
[ 0 ]
- For the other mesh primitive, there are feature ID values
[ 1, 2 ]
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
const fromPrimitive0 = gltf.meshes[0].primitives[0].extensions["EXT_mesh_features"].featureIds[0];
const fromPrimitive1 = gltf.meshes[0].primitives[1].extensions["EXT_mesh_features"].featureIds[0];
then these are independent objects, and they do not need to have the same featureCount
. The featureCount
could be 10 for the first one, and 999 for the second one.
The featureCount
only tells the consumer: "There may be up to featureCount
different feature ID values in there".
If it’s 3, we could/should check that the FeatureCount is the same when there are multiple primitives
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
- primitive 0 of mesh 0 has 4 feature ID definitions
- primitive 1 of mesh 0 has 2 feature ID definitions
- primitive 0 of mesh 1 has 5 feature ID definitions
- primitive 1 of mesh 1 has 7 feature ID definitions
and all of these feature ID definitions have a different featureCount
. At this point, it would only be a bunch of numbers, and it could be hard to convey a "meaning".
In practice, one can probably say that...
- Usually, each mesh primitive will have the same number of feature ID definitions
- (and in many cases, it will only be one feature ID for each primitive)
- Usually, the feature ID definitions of mesh primitives at the same index will have the same
featureCount
The idea here would be to have something like (pseudocode):
meshes: [
primitives: [ {
// First primitive with two feature ID definitions:
featureIds: [ {
featureCount: 5,
}, {
featureCount: 10,
}
}, {
// Second primitive with two feature ID definitions:
featureIds: [ {
featureCount: 5,
}, {
featureCount: 10,
}
}
}
This could, for example, be IDs for buildings:
- The ID definitions with
featureCount: 5
refer to a component of the building ("door", "window", "roof", ...). - The ID definitions with
featureCount: 10
refer to materials ("stone", "glass", "plastic", ...).
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 featureCount: 10
because there might be a primitive that involves 10 materials.
from 3d-tiles-validator.
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...
from 3d-tiles-validator.
I hope it's OK to close this in favor of CesiumGS/3d-tiles#756
from 3d-tiles-validator.
Related Issues (20)
- Refining the report format and report file handling
- Cycles in external tilesets are not detected HOT 1
- TypeScript compilation fails HOT 5
- Tool can't be packaged HOT 1
- Validator fails to resolve GLB from I3DM with URI with spaces
- Build broken? HOT 1
- Streamline the validation of arrays of objects
- 3DTILES_content_gltf ? HOT 3
- Allow validation of tile content files
- Geometric error inconsistencies should be a WARNING and not an ERROR
- Out of memory crash HOT 1
- glTF extension support? HOT 4
- ValidFeatureIdAttributeWithByteStride.glb not a 3D Tile HOT 1
- Tests with texture and nullFeatureid missing HOT 1
- PropertyAttributesPropertyAttributePropertyMaxMismatch.gltf is valid HOT 7
- Handle invalid alignments more graciously
- Missing 'refine' in root tile is not detected
- Simplify filtering of validation report files
- False positive regarding EXTENSION_FOUND_BUT_NOT_USED in child tileset HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from 3d-tiles-validator.