Simplifying targets for extras/extensions? about cgltf HOT 3 CLOSED

Looks like like that wouldn't cause too much pain to remove extensions for those three targets. We could just do it and re-add in case anyone needs it in the future.

As for your idea of storing the extensions and extras separately: If we added some functions to add/remove/read that data it wouldn't make the usage for the end user that much harder, would it?

from cgltf.

Not sure why I didn't add extensions to cgltf_pbr_metallic_roughness (I planned to add to everything that has extra data, exclusing what is already and extension). However, since those three doesn't have any public extensions I don't see any problem removing extensions from those.

And I think storing extensions (&extras) separately might not be good idea, as everything else is accessed similarly as one would access it from glTF json (indices are just replaced with pointers).

from cgltf.

I've put together my current thoughts on extensions in #125. Feedback would be appreciated.

from cgltf.