zeux / meshoptimizer

Mesh optimization library that makes meshes smaller and faster to render
MIT License
5.67k stars 481 forks source link

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

Closed CITIZENDOT closed 10 months ago

CITIZENDOT commented 10 months ago

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: https://github.com/zeux/meshoptimizer/blob/e47e1be6d3d9513153188216455bdbed40a206ef/gltf/parsegltf.cpp#L32-L33

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

zeux commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

cgltf change that will adjust the error code: https://github.com/jkuhlmann/cgltf/pull/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 commented 10 months ago

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