Closed EeroMutka closed 4 years ago
Do you have an example .gltf file? This works fine for me. component_type in particular is read from the .gltf componentType so if that uses a UNSIGNED_INT index type, you should get r_32u.
Hmm, that's interesting. I don't see why it wouldn't work for me then. Here you go gltftest.zip
(in these images I actually loaded a .glb file, but the same thing happened with .gltf)
Your glTF file doesn't use 32-bit indices. The mesh has 3 primitives, with 291552 indices & 65535 vertices in the first, 274953 indices & 61834 vertices in the second, and 213 indices & 89 vertices in the third one (you can see this by inspecting the gltf file, particularly the meshes and accessors used).
So cgltf correctly returns three primitives - it's up to your application to either decide to merge them or decide to keep them split and use 16-bit indices.
Oh, I see. I guess the blender exporter splits it? I assumed that since I'm exporting only a single mesh container, it'd put it all in a single primitive. I should dig into the gltf spec more. Thanks for helping
Edit: yeah, the issue is with the blender gltf exporter. But its fixed in the latest version! Glad it was that easy. https://github.com/KhronosGroup/glTF-Blender-IO/issues/777
When I load a mesh with more than 65535 verticies, cgltf discards all the extra verticies. The indices structs component_type stays at cgltf_component_type_r_16u and the position attribute structs count says 65535.
GLTF does support more than 65545 verticies, for example when I export and import back such a mesh in blender, it all works. Are you planning on making this work?