search

spnda / fastgltf

A modern C++17 glTF 2.0 library focused on speed, correctness, and usability
https://fastgltf.readthedocs.io/v0.8.x/
MIT License
312 stars 48 forks source link

Add user callback for unsupported extensions #78

Open maoliver-amd opened 2 weeks ago

maoliver-amd commented 2 weeks ago

Just like what was recently added for the "extras" field it would be useful to have the option of using a user callback for any "extensions" that are not natively supported by fastgltf. This would allow a user to add in their own support for vendor extensions and the like beyond the offical ones supported by fastgltf

spnda commented 2 weeks ago

I agree that this is an important feature that is missing. However, I don't really like the way the extras API is structured currently and I would only reluctantly replicate it for use with extensions. I have a local patch that replaces the extras API with a std::any extras; field on every struct, making the callback a little simpler to use. Not sure if that is the best way to go about things yet, and this is a topic I am still investigating. The problem mainly consists of:

  1. I don't really want to add an extra 8 or more bytes (for a std::any, std::shared_ptr<void>, ...) to every glTF object if it is unused, which is why currently the API requires you to store custom data separately. This can get quite complicated, as seen in the example in the documentation.
  2. The simdjson DOM API does not offer a way to get a std::string_view for an object, meaning I am forced to "leak" the simdjson data through the extras callback, and force the user to use simdjson. This would be fixed by #5 but due to performance implications it has not been changed yet.

Any input on improving this API would be greatly appreciated. For vendor/custom extensions it will probably be best to create a fork for now.

Edit: Removed the Spotify song link and put the actual documentation link. (Good song tho)