Error: Cannot load ...glb, buffer too short

[CITIZENDOT]

The size of GLB is 1.7GB, and I'm using this command to compress:

gltfpack -c -si 0.7 -vpf -vnf -i input.glb -o out.glb

Looking at the source, the error is coming from here:

meshoptimizer/gltf/parsegltf.cpp

Lines 32 to 33 in e47e1be

	case cgltf_result_data_too_short:
	return data ? "buffer too short" : "not a GLTF file";

I'm not sure how to overcome this. Any suggestions/fixes are appreciated.

[zeux]

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.

[CITIZENDOT]

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

Thank you

[zeux]

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.

[zeux]

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.

[CITIZENDOT]

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