Suggestion: store indices instead of pointers in the data structures about cgltf HOT 4 CLOSED

A set of helper functions might be the best solution to this. It keeps the parsing core as is and it doesn't bloat the uses of pointers + doesn't create redundancy in the representation, but for every individual pointer it's obvious as to how to recover the index.

from cgltf.

Is computing the indices a problem? gltfpack uses indices extensively in various parts of the pipeline and it wasn't a big problem, even though the code is sometimes a little repetitive. If we only have indices, this breaks compatibility but also makes cgltf more cumbersome to use as you need to convert from indices to pointers. If we have both indices and pointers everywhere, then we'd need to store the equivalent data redundantly, which, in addition to being a bit wasteful, probably breaks cases where a file is loaded, mutated, and saved via cgltf_write (as existing code would need to be changed to update both indices and pointers...).

from cgltf.

Needing to recompute indices (something I suspect most users do) adds a bit of trickiness since the user needs to carefully determine which pointers can get turned into indices and which ones don't since the API doesn't make this a clear contract. Even though implementation is trivial for users to do it themselves, adding some helper functions to the API would at least provide such a contract and make it easier to functionally verify usage. e.g. cgltf_get_material_index(const cgltf_data*, const cgltf_material*).

from cgltf.

That solution works for me as well. Thanks for looking into it!

from cgltf.