Clarify details about featureCount and nullFeatureId

[javagl]

This refers to the EXT_mesh_features extension:

The specification currently says

The definition of the feature ID set may include a nullFeatureId, which is a value that indicates that a certain part is not considered to be an identifiable object. The definition also includes a featureCount value, which is the number of unique features that are identified.

This actually caused some confusion for me (while implementing the validation of the extensions), and came up again recently in CesiumGS/3d-tiles-validator#294 (comment)

We could clarify this, maybe only as an "Implementation Note" with examples, to emphasize...

• The featureCount does not say how many features are present in the specific instance of the extension (on a specific mesh primitive). It says how many features there are as a whole. So there may be an instance of the extension on a specific mesh primitive, and this may have the feature ID values [12, 34, 56], and the featureCount may still be 10 or so.
• The nullFeatureId does not contribute to the featureCount. So there may be feature ID values like [12, 34, 56, 9999], and the featureCount may still be 3, namely when one of these values (like the 9999) is the nullFeatureId

[bertt]

Is the FeatureCount used in CesiumJS (or another client)? Didn't have the impression it is. If not used, maybe it's an option to deprecate it?

[javagl]

From a quick full-text search, it does not seem to be used (it is read and stored in some property, but I don't see where it is actually used). Some questions about the featureCount had already been raised in #624 , and that (and the linked issues) contain some justifications, but I couldn't immediately "map" this to the CesiumJS code right now.

So this issue may indeed be a clarification that goes beyond what it means - it may raise the question of whether it is required (or still required in CesiumJS), or whether it should or could be deprecated.

[lilleyse]

featureCount would be relevant to CesiumJS as part of fixing CesiumGS/cesium#9884 to know how many Cesium3DTileFeature objects to allocate.

[javagl]

I had a short look at the relevant parts of the codes - yes, a bit naive, by just doing a GitHub search for featureCount in the whole CesiumGS organization and browsing through some parts of the respective (code) search results.

It looks like the featureCount is rarely used. It is read, maintained, forwarded, updated, but cannot point my finger at a place where it is actually, technically, and strictly required. It's hard to be sure here, because ... it's a pretty generic term, there are some parts of the code where a "translation" from legacy versions of the extensions is going on, and it might be that the featureCount is assigned from some count value of a legacy extension, or vice versa.

A few places caught my attention:

• The type of a feature ID set is determined based on the feature count in https://github.com/CesiumGS/cesium-unreal/blob/fa463aef49e97c3e4df68645d354839358582145/Source/CesiumRuntime/Private/CesiumFeatureIdSet.cpp#L61
• The value seems to be exposed in a blueprint at https://github.com/CesiumGS/cesium-unreal/blob/fa463aef49e97c3e4df68645d354839358582145/Source/CesiumRuntime/Private/CesiumFeatureIdSet.cpp#L97 (meaning that it cannot be trivially be removed)
• Apparently, a missing featureCount in spec data caused trouble in Support KHR_texture_transform for feature ID textures cesium-unreal#1360 (but I couldn't quickly identify the spot where it was required)
• (The term appears at places like https://github.com/CesiumGS/cesium-unreal/blob/fa463aef49e97c3e4df68645d354839358582145/Source/CesiumRuntime/Private/CesiumEncodedMetadataUtility.cpp#L223 , but that may be a "false flag": This value is actually the property table count)

If the goal was to remove the featureCount from the specification, then these parts may have to be investigated in more detail. But it looks like for the case of feature ID textures, the featureCount actually is required for some implementations.