Panics on reading a large GLTF due to the .bin being more than ~4GB and `byteLength` using a u32 about gltf

[alteous]

That's interesting. It's good to know there are assets large enough to encounter these kind of issues.

This is a known problem for binary glTF because there is a hard limit on the binary chunk size. For standard glTF with a separate binary payload, you're right to say there is no such limitation. I'll mark this is a bug.

[alteous]

Would a fix to this involve anything beyond changing the types of Buffer::byte_length and View::byte_length from u32 to usizeu64? The binary buffer size limitation and type should still be enforced through Header::length etc, so it shouldn't weaken any guarantees, I don't think. If that's it, I might make a PR for it tomorrow.

I don't think so. I agree it should be u64 rather than usize.

[ShaddyDC]

Would a fix to this involve anything beyond changing the types of Buffer::byte_length and View::byte_length from u32 to usizeu64? The binary buffer size limitation and type should still be enforced through Header::length etc, so it shouldn't weaken any guarantees, I don't think. If that's it, I might make a PR for it tomorrow.

Edit: I realised that using usize would not work on 32 bit targets, or rather be inconsistent. On the other hand, using u64 on 32 bit targets that never need to handle large glTF files might lead to unnecessary slow downs. I'd still just stick with u64 since I happen to work on 64 bit systems and it's much simpler, but you could argue for putting it behind a (default) feature or making it generic with implementations for either type.