Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add user callback for unsupported extensions #78

Open
maoliver-amd opened this issue Nov 5, 2024 · 1 comment
Open

Add user callback for unsupported extensions #78

maoliver-amd opened this issue Nov 5, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@maoliver-amd
Copy link

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 spnda added the enhancement New feature or request label Nov 5, 2024
@spnda
Copy link
Owner

spnda commented Nov 5, 2024

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 Change: Use simdjson's ondemand API #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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants