Feature Hierarchy extension

[lilleyse]

Note: this extension is not up-to-date with the latest draft of EXT_feature_metadata

Direct link to extension: EXT_3dtiles_feature_hierarchy

This extension is built on top of EXT_3dtiles_feature_metadata to allow for feature classes and metadata hierarchies.

The current 3D Tiles batch table hierarchy spec is here. It didn't take too much work to move it to glTF, the only difference is that binary properties can now use glTF accessors. Other changes include:

• The length property of a class is renamed to instanceCount
• The instances property of a class is renamed to properties to match the regular feature table
• The instancesLength top-level property is renamed to instanceCount

Notes:

• I removed the declarative styling section. I think this belongs at a different level of the spec.
• Should this be its own extension or should it be combined into EXT_3dtiles_feature_metadata?
• Needs more well defined behavior when using the same property names across different classes. This is what the spec says now:

In some cases multiple ancestors may share the same property name. This can occur if two ancestors are the same class or are different classes with the same property names. For example, if every class defined the property "id", then it would be an overloaded property. In such cases it is up to the implementation to decide which value to return.

Instead should properties could be preceded by their class name (e.g. Building#name or Building.name) to avoid collisions?

@mramato @kring is there anything else that would be nice to have for declarative styling purposes, specifically for the feature hierarchy?

[Samulus]

• Maybe change length to instanceCount ? I think it's clearer (completely subjective).
• I don't think stacking the buildings on top of each other shows a hierarchy clearly, the relationship wasn't obvious to me. I think if the picture showed buildings in different neighborhoods in an overarching city the hierarchical nature would be more immediately apparent. Illustration doesn't have to be crazy, just circles on the floor around buildings with labels saying Vectorville / XYZTown, and a bigger circle encompassing everything.
• I would define and use the terms implicit id and explicit id when referring to using classIds.values[i] (the explicit id) and i (the implicit id / instance id) just to make the relationship between the two more obvious.
• You have an implementation notice explaining the implicit id cannot be used to directly look up the values in the classes[x].instances.whatever.values[x] table. You also mention that it can be inferred by counting. I would go a step further and provide an implementation for doing so at runtime. Unless I'm misunderstanding the spec that would look something like:

// for the car example
var implicitId = 5;
var ext = gltf.extensions.CESIUM_3dtiles_batch_table;
var classInstance = ext.classIds.values[implicitId];
var offset = 0;
for (var i = 0; i < classInstance; ++i) {
  offset += ext.classes[i].batchLength;
}

var sedan = ext.classIds[classInstance].instances.carType.values[implicitId - offset];
var color = ext.classIds[classInstance].instances.carColor.values[implicitId - offset];

• Nitpicky, but the red arrow that curves and points to 0 in the batchTable with a hierarchy example should be almost touching the 0, like in the example with the cars. It's ambiguous which circle you should start at for traversal otherwise.
• I think the arrows are kind of misleading in the parent lookup section image. The arrows imply you go from 7 directly to 9, to 9 again in the parentIds array. You actually have to zig zag between both arrays, so the arrows should reflect that. The text is clearer about this.

[sanjeetsuhag]

We should be consistent with the glTF naming scheme i.e. use ...length for size and ...count for item counts.

[pjcozzi]

@lilleyse great to see this. Please bump to me when ready.

[lilleyse]

Renamed the extension to CESIUM_3dtiles_feature_hierarchy and updated the PR description.

[lilleyse]

• instanceCount is used in the class object and in the top level object. Is this ok or should we use a different name?

[lilleyse]

Renamed to EXT_3dtiles_feature_hierarchy and updated the spec to match the latest changes in #1 (comment).

[pjcozzi]

@lilleyse is this now built into the latest feature metadata extension? Or will this be a separate extension?

[lilleyse]

@pjcozzi this is separate from the metadata extension. I'm going to close this PR since it's out of sync with the latest EXT_feature_metadata and the design might change a lot.