Identical vertices don't result in the same position after draco compression, leading to gaps between meshes

[hybridherbst]

We have some meshes that are split in chunks (one glb file, multiple meshes inside). The chunk borders align perfectly (the vertices have identical positions). However, after draco compression, there are noticeable gaps between these chunks.
My assumption is that somehow the quantization for the same input data results in different output data; is this expected, or is there a way to optimize a file "globally" instead of per-mesh?

Before/After

Before/After (closeup)

[PurpleSwords]

I also encountered this problem. In the source code, I found that Draco uses mesh as the unit for processing, so there will be some differences in quantification between different meshes.

My current solution is to use SetAttributeExplicitQuantization instead of SetAttributeQuantization, and manually set all mesh quantization ranges to the same value. In this way, for the same value, the result of quantization will remain the same.

Obviously, in order to unify the quantization range, I have to use larger parameters for setting, which will reduce the accuracy and increase the file size——But it has no cracks.:rofl::rofl::rofl:

[hybridherbst]

Thanks for investigating this!
@donmccurdy I believe this is not supported in gltf-transform CLI or regular right now, is that correct?

[donmccurdy]

Right, currently glTF-Transform is letting Draco determine the quantization parameters, so that's inherently per-primitive. I think glTF-Pipeline has implemented what you're describing, under the --draco.unifiedQuantization option, and I'd be curious to know if you get better results from that?

This doesn't sound too complicated to add to glTF-Transform, so I've filed that as donmccurdy/glTF-Transform#257.

[hybridherbst]

Sorry for the delay, just verified that indeed the --draco.unifiedQuantization true option in gltf-pipeline fixes the issue:

unifiedQuantization false

unifiedQuantization true

What can also be seen (when flipping back and forth between these images) is that, as expected, overall shape changes quite a bit since now the same quantization bits are used for a larger bound.

So I think this issue here can be closed (since it seems to be "by design" that draco does this by default, and there's a flag that fixes the issue at hand).

[donmccurdy]

Also note that you can use higher precision (e.g. 24 bits) for the position attribute, which may help here.

Would you be able to share the asset above? I'd be interested in testing an implementation with a global quantization volume in glTF-Transform later.

[hybridherbst]

Yep, should have mentioned, I bumped the precision from 14 bit to 16 bit in this case to get rid of some noticeable imperfections.
Generally it wasn't easy to match the behaviour of gltf-pipeline to that of gltf-transform - they seem to have very different defaults, and I didn't find all the matching numbers.

I sent you the file url via Khronos Slack - I can also send it via mail if that's better :)

[donmccurdy]

Adding this option to gltf-transform soon, feel free to track this in donmccurdy/glTF-Transform#272.