Flexible extension support about cgltf HOT 2 OPEN

Looks solid to me! Here are a few thoughts;

How will the extension setup callback know what it is setting up?

• One callback per object type? VENDOR_ext_setup_asset(..), VENDOR_ext_setup_node(..), etc
• An object type enum? VENDOR_ext_setup_asset(cgltf_object_type object_type, ..)
• A string? VENDOR_ext_setup_asset(char* object, ..)

Is it enough to know the object type during setup or is the hierarchy / "path" also required in some situations?

Write! When setting up the callback functions in cgltf_options, I would much like to have a fourth one for writing - something like VENDOR_ext_write(cgltf_write_context* context, cgltf_extension* extension).

Extension "user data". Is there a case for extension setup or write implementations to need user data? Would probably suggest leaving it for later until a need pops up.

from cgltf.

Maybe instead of map just an extension list per object-type, similar to how Vulkan has pNext and sType. We also have a bunch of unofficial extensions here, and I agree a separate file to manage those could be nice. However several json utilities for loader/saver would need to be exposed I think. There is also pointer fixup and validation etc.
Allocation would go through the exisitng options api

That said so far just hacking cgltf itself was simple enough ;) and one gets the easye to use structs in return...

from cgltf.