Error: Cannot load ...glb, buffer too short about meshoptimizer HOT 5 CLOSED

There's a few different cases in cgltf library that is used for parsing that emit this error code. I think I'd need the file to debug this.

from meshoptimizer.

I have shared the GLB on your email's ([email protected]) drive: https://drive.google.com/file/d/1xXvBiHaGHztdKxcp7HWQ7TzLxVNAZPkq/view?usp=sharing

Thank you

from meshoptimizer.

Thanks! I've debugged this and this is coming from this line that validates animation input/output count:

https://github.com/jkuhlmann/cgltf/blob/master/cgltf.h#L1741

The file has one animation with 6382 key frames that is targeting a mesh with 6218 morph weights. As a result, the expected number of output values in the animation track is 39683276, but the actual value in the file is 40723542. The mismatch causes a validation error that is making the file not load (the error should probably have been invalid glTF here).

You can use Khronos glTF Validator on the file in question (https://github.com/KhronosGroup/glTF-Validator/releases) and it will also produce the validation error:

            {
                "code": "ANIMATION_SAMPLER_OUTPUT_ACCESSOR_INVALID_COUNT",
                "message": "Animation sampler output accessor of count 39683276 expected. Found 40723542.",
                "severity": 0,
                "pointer": "/animations/0/channels/0/sampler"
            }

So I think gltfpack is correct here. Moreover, 40723542 when divided by 6382 is 6381 which makes more sense in this style of animation where every keyframe is a single pose. It looks like some morph targets got dropped during export - I don't know if it's a Houdini bug (which is listed as an export tool on the metadata) or if the file was tweaked in some way after that. Notably I tried just commenting out the assert/validation and the animation ends up being incorrect after all - as in, I think the animation track data does expect 6381 key frames, and so using something like Babylon JS viewer I get some frames where two weights that add up to one are not consecutive, causing weird interpolation artifacts between two blend shapes that are too far away.

I'll submit a small change to cgltf to change the error code here to invalid glTF to make things like this easier to debug in the future, I should have suggested glTF Validator from the beginning but the error code misled me into thinking it's an overflow error or something like this.

from meshoptimizer.

cgltf change that will adjust the error code: jkuhlmann/cgltf#242 - after this gets merged and gltfpack copy gets updated, this file will get "invalid glTF" error on load instead. Nothing more can be done here without fixing the file / export process I think.

from meshoptimizer.

Thank you for detailed analysis ❤️ ! Yes, a better error message will definitely help for future users.

from meshoptimizer.