forked from jkuhlmann/cgltf
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Copy extras data into cgltf_extras::data during parsing
This change switches cgltf_extras to embed the JSON data the same way we handle unprocessed extensions, by copying it to heap. While this results in a few extras heap allocations, in practice the other data such as object names et al dominates the allocation traffic. The benefit here is that it makes using the library simpler - extras can be read from directly without copying, and this means that the original glTF data can be discarded which can improve memory consumption. The downside, of course, is that there's quite a few places where extras is used. This can be mitigated by jkuhlmann#118 in the future, but for now we diligently free extras for every struct that has them, something that is made easier by the fact that most structs that contain extras also contain extensions. Note that this change leaves start_offset/end_offset in tact for now, which makes it easy to upgrade to the new version, but in the future we can remove these as the internals of cgltf no longer depend on those - cgltf_write can work with manually assembled trees so for now it handles both ::data and ::start/end_offset. To make sure this change works well, I had to deduplicate extra data in material mappings by only recording the extras token and then redundantly reparsing extras when filling the mappings - something that in practice is likely benign as almost no assets that use material mappins contain extras. Fixes jkuhlmann#116.
- Loading branch information
Showing
2 changed files
with
97 additions
and
25 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters