Problem with incomplete loading of glb (minimal example)

[Jelegk]

Hello good people, this library (and the maintainers) looks phenomenal, but debugging it, less so.
We really didn't want to straight up bother you with our failure, but posts online about fastgltf errors are scarce and we are ready to bet that it hasn't surfaced elsewhere yet.

So here's the situation: we made a basic gltf model with 3 meshes and a squash animation, and exported it in binary.
Pretty much all other visualizers load the glb flawlessly, meshes, animation and all.

Following the docs, we create a parser and load the model.
At this stage, VSCode's debugger shows the asset fully populated, great.

Except that that's not the case, only for the first mesh?
Both mesh 1 and 2 contain their only primitive, but for mesh 0, which is correctly identified with the same name as in Blender (at least), no primitive is found.

Naturally, an error gets thrown, std::bad_array_new_length, and the game is over.

We would be eternally grateful for some advice! Do ask for some more/missing information, we'll be glad to elaborate.

[spnda]

Not having any code or the asset makes a little harder to debug this over GitHub discussions imo.

I would suggest you open the file in VSCode (.gltf are just JSON) or ImHex (.glb embed the JSON string), and look what the data is there. Then try and reference that back to the asset that loadGltf returns. That essentially should give you a diff, and building on that I or others could be of more help. Simply knowing "the primitives array isn't behaving correctly" does not give close to enough information about the exact issue.

Also, what issues are you having exactly with debugging the library? I know the complexity of the parser might be a little overwhelming, but you can add breakpoints to loadMeshPrimitives or specific fields. However I would suggest you first do what I said above, since this might not help much or would benefit from knowing the difference.

[Jelegk]

We ended up creating a small git repo with just the relevant code, just to find that it was our structure that was at fault:
While it is weird that we could access all that other content, it was simply an error of creating the asset in a function pre-constructor,
then returning the object, which only existed within that function. We switched to using a pointer and move()ing the asset in it.

Still, we thank you a lot for your swift response, which instigated our search in this different direction!

(btw debugging the library is quite alright, I'd say skill issue on our part)