gltfpack: Visible quantization artifacts on some scenes
I recently update to the latest version, v.0.18.
And realiced that now is very common after a simple optimization, even without compression the geometry looks "pixelated"
gltfpack -i ... -o ...
How it should look.

How it actually look.

I think this was due to some issue on my meshes, but after the update this happen almost every time.
with v.0.16 this neeeeever happen
Any idea why this is happening?
This looks as if something changed with quantization behavior between 0.16 and 0.18. Please attach the reproduction scene - without it it's impossible to diagnose cases like this. You can also pass -vp 16 to improve this behavior.
P.S. It's actually a little surprising that this scene used to work without quantization artifacts without extra options. You might want to use -kn flag because without it gltfpack will try to transform meshes to world space if they are static.
Thanks for answering!
-
Not necesary only on larger scenes. This is another one, very simple, in this case the character is rigged.
A thing is that I realized, it only happens in certain meshes with the property in common than the vertex are very close one of each other. (This could be a factor?) -
-vp 16makes it looks better but still have trace of those squares. Inv0.16with default value works perfectly. -
Yeah sure, in this scene I need to use
-knspecialy and other flags, I mention that no extra options to make it clear that even in the simplest way happen that "squarization". -
https://we.tl/t-pvsdQ4kGkH Here is this character scene without quantization, as blender exports it. And this is how I quantize it and outputs as the previous image
gltfpack -c -i ./Ar_v4.glb -o ./Ar_v4c.glb
The scene above has the same issue on gltfpack 0.16 as far as I can tell. This came up before (#433) and is due to some odd export behavior that Blender has with skinned meshes and unit conversions, where it exports skinned geometry at a very different resolution vs non-skinned geometry.
I am not sure if this is fixable, would need to think about the consequences of propagating scale from the skinned model into the vertex data. Recently added -vpf fixes it but it's not very widely tested.
Note: for any report in this thread that doesn't come with a link to the scene before the compression, it's going to be impossible to investigate whether it's something that can be improved or not. So far out of 3 examples here only one (from comment https://github.com/zeux/meshoptimizer/issues/466#issuecomment-1219770528) has been reproduced and traced to a skinning export issue, tracked in #433.
Hi, I just have a test on a model on sketchfab https://sketchfab.com/3d-models/fictional-supercar-v12-goblin-0a20e49ad5774d778567cb5c3f345786
I do these steps with the model:
- convert it to GLB with blender 3.2.2
- use
gltfpack -ccto output a meshopt glb - put the result to https://gltf-viewer.donmccurdy.com/ to see the result
The result is OK, and I modify the model, add a really large sphere on the model. This time, I got artifacts on gltfpack -cc, and got better result with -vp 16
Artifacts model_with_sphere_meshopt.glb.zip

Little artifacts model_with_sphere_meshopt_vp16.glb.zip

Since no new examples have been posted, and https://github.com/zeux/meshoptimizer/issues/466#issuecomment-1221746038 is inevitable / expected, I'm going to assume that there's no regression and that the only tangible issue is with the skinned models and a very large scaling factor that Blender adds, which will be tracked / fixed by #433.
