add cesium ext_mesh_features

[bertt]

Adds Cesium EXT_Mesh_Features extension

Spec: https://github.com/CesiumGS/glTF/tree/proposal-EXT_mesh_features/extensions/2.0/Vendor/EXT_mesh_features

Sample using FeatureId's by custom vertex attribute see https://github.com/CesiumGS/3d-tiles-samples/blob/main/glTF/EXT_mesh_features/FeatureIdAttribute:

Sample using FeatureId's by texture see https://github.com/CesiumGS/3d-tiles-samples/blob/main/glTF/EXT_mesh_features/FeatureIdTexture

[vpenades]

I can't find the code that generates the ext.MeshFeaturesMesh.g.cs file.

Ideally, the PR should include the Build\ SharpGLTF.CodeGen code, so the generator and the generated code can be tracked to the same PR

It is fine to modify the codegen project to either:

• call the method that clones the repository to get the extension from there.
• simply include the schemas as content files (maybe in a LocalSchemas\ directory

[bertt]

Added the schemas (see https://github.com/bertt/SharpGLTF/tree/add_cesium_ext_mesh_features/src/SharpGLTF.Cesium/EXT_mesh_features/schema), next is generating the code.

[vpenades]

I've fixed the code generator, the field access was in the wrong method, and there's no good way of defining a default value, so I completely removed it (which I think it's the best choice)

I also changed the generated class names to something less generic as "FeatureID"

It's odd to me that these cesium extensions are "EXT" extensions, but I think that if they originated from Cesium they should be called something else, I don't know.

Anyway, I also dislike these alternate names, they're provisional until we settle on a better naming convention.

[bertt]

Must be public otherwise generated code MeshExtMeshFeatureIDTexture : TextureInfo does not compile (error: 'TextureInfo is inaccessible due to it's protection level')

[vpenades]

Must be public

I agree, as more extensions are created outside the core repository, there'll be a demand for exposing some internals.

On the current extension:

Eventually, these classes will also need constructors, specialised collections and probably some validation.

For example, I think "attribute" is actually an index to an Accessor, so it will probably require the same wiring used in cesium_outline.

[bertt]

its little different, if attribute=0 then there must be a custom vertex attribute with name _FEATURE_ID_0, we can check on that

[vpenades]

To tell you the truth, I don't fully understand some of the details of this extension, specially the bit-based thing of the feature Id... and I understand the general concepts of the extension, but I haven't fully grasped all the details, so I am relying on you to flesh out this extension

[bertt]

I've added a check for the attribute (https://github.com/vpenades/SharpGLTF/pull/199/files#diff-6ea6b6829d26c72a50a197edad04c83f6a8ada627b9bf96affb2aea89f725801R81) , some more checks to go