The glb model with skeleton animation, after being compressed with meshopt, has resulted in some parts being rendered smaller.

[rarest]

OriginModel:
origin.glb.zip
MeshoptModel:
meshopt.glb.zip

gltfpack options
./gltfpack -i origin.glb -o meshopt.glb -cc -kn -km -ke -kv -v

output message
input: 77 nodes, 3 meshes (3 primitives), 3 materials, 1 skins, 3 animations, 4 images input: 3 mesh primitives (22002 triangles, 14079 vertices); 3 draw calls (3 instances, 22002 triangles) output: 3 mesh primitives (22002 triangles, 14079 vertices); 3 draw calls (3 instances, 22002 triangles) output: 80 nodes, 3 meshes (3 primitives), 3 materials output: JSON 79643 bytes, buffers 299768 bytes output: buffers: vertex 104888 bytes, index 25183 bytes, skin 3374 bytes, time 507 bytes, keyframe 44089 bytes, instance 0 bytes, image 121710 bytes

use filament to preview the models:

[zeux]

Duplicate of #433
Caused by excessive scale on Root node which is due to how Blender exports combined skinned/non-skinned models iirc
Can be fixed by passing -vpf

[rarest]

Duplicate of #433 Caused by excessive scale on Root node which is due to how Blender exports combined skinned/non-skinned models iirc Can be fixed by passing -vpf

It appears that using the -vpf option did not resolve the issue, the vpf model also looks like smaller. By the way, does the gltf 2.0 specification not support adding the scale attribute to the root node?

./gltfpack -i origin.glb -o meshopt_vpf.glb -cc -kn -km -ke -kv -vpf -v
meshopt_vpf.glb.zip

[zeux]

I recommend using https://gltf-viewer.donmccurdy.com/ or https://sandbox.babylonjs.com/ for testing if the models are rendered the same way (although three.js has had some bounding box issues in the past so it's not always framed correctly). On vpf and original model both viewers result in the same view, so whatever logic Filament is using to frame the model must be misbehaving here. Unless you think that the actual scale here is somehow wrong but that seems implausible based on the results I see in Babylon.JS that, for both models, look like this:

Without -vpf it looks like this; again there's no scale issue here but there's a quantization issue that's the same as the issue I linked above.

[rarest]

Sorry for the late reply. I tested it with Three.js and Babylon.js, and the model scaling is indeed consistent. It’s likely that there is an issue with filament's handling of scale. Thank you very much!