This change removes support for extras and extensions from cgltf_accessor_sparse and cgltf_texture_view to simplify memory management.
The motivation for this change is that both accessor_sparse and texture_view are deeply nested in glTF structures and simultaneously rarely extended; there are no known extensions for internals of sparse accessors, and only one (KHR_texture_transform) extension for texture views which is supported by cgltf natively.
The presence of these inflates the cgltf data structures; while it would be reasonable to do given specific use cases, we do not have specific use cases here.
Additionally, for cgltf_texture_view, this type is heavily used by the materials which is a very active area of development in glTF ecosystem. Many newer extensions are added gradually that introduce more texture view objects, and with each extension there is a risk that cgltf_free_texture_view et al will be forgotten - indeed, this happened several times for newly introduced extensions.
Finally, for cgltf_texture_view, due to the current code structure, the presence of KHR_texture_transform extension causes us to allocate arrays of unprocessed extensions, only to never use them later. While this is a general problem that could manifest in other places, this specific place is something where this can happen often when the assets are using quantized texture coordinates, and can be easily avoided because we don't actually need to support extensions.
Note that cgltf_write didn't even support extensions in either of these cases in the first place.
Fixes #118.
Tested with 4B of fuzzing iterations in addition to gltfpack.
This change removes support for extras and extensions from cgltf_accessor_sparse and cgltf_texture_view to simplify memory management.
The motivation for this change is that both accessor_sparse and texture_view are deeply nested in glTF structures and simultaneously rarely extended; there are no known extensions for internals of sparse accessors, and only one (KHR_texture_transform) extension for texture views which is supported by cgltf natively.
The presence of these inflates the cgltf data structures; while it would be reasonable to do given specific use cases, we do not have specific use cases here.
Additionally, for cgltf_texture_view, this type is heavily used by the materials which is a very active area of development in glTF ecosystem. Many newer extensions are added gradually that introduce more texture view objects, and with each extension there is a risk that cgltf_free_texture_view et al will be forgotten - indeed, this happened several times for newly introduced extensions.
Finally, for cgltf_texture_view, due to the current code structure, the presence of KHR_texture_transform extension causes us to allocate arrays of unprocessed extensions, only to never use them later. While this is a general problem that could manifest in other places, this specific place is something where this can happen often when the assets are using quantized texture coordinates, and can be easily avoided because we don't actually need to support extensions.
Note that cgltf_write didn't even support extensions in either of these cases in the first place.
Fixes #118. Tested with 4B of fuzzing iterations in addition to gltfpack.