Arseny Kapoulkine

> It's just that Unix treats filenames as blobs. Right. But then load_file won't use UTF-8 as an input! (e.g. it will accept malformed UTF-8 sequences) Right now the contract...

> Yes. But after you learnt, what's next? You would have to reinvent the wheel and hope for the best. You use `as_wide`. The fact that it can't open some...

@etc0de This is because all accessors must have the same size, and this is checked before the code you quoted: ``` for (cgltf_size k = 0; k < data->meshes[i].primitives[j].attributes_count; ++k)...

@NPatch I thought this is required by the spec https://github.com/KhronosGroup/glTF/tree/master/specification/2.0 but I currently can not find the relevant reference... glTF validator does have the same check (see `meshPrimitiveUnequalAccessorsCount` in validator...

> Btw I think it's possible to do indexing for UVs or Normals, like the OBJ spec allows( or just per-wedge uvs), to reduce file size glTF only allows a...

All of this is inconsistent with glTF specification, where each index is used to index all attribute accessors simultaneously. So yes that would require an extension.

I'm wondering how exactly we'd make this optional, and whether it's worth it? There's some complications with deallocation - we can probably check if the data is inside the JSON...

Oh, two additional notes: - For extensions, there's already an allocation for the name of an extension anyway - For both extras and extensions, specifying offsets into the JSON blob...

Started working on that and I'm having second thoughts about this. Specifically the destruction code becomes extremely complex with this approach, because almost all objects now contain their own allocations....

> That's why I was asking about making it optional Ah, maybe I misinterpreted the request earlier - if that meant making the `extras` loading optional this could make sense...