glTF-Transform
glTF-Transform copied to clipboard
donmccurdy
Draco compression issue
Describe the bug Hello, it seems like with draco compression the UV coordinates (?) get lost for one particular model
To Reproduce Steps to reproduce the behavior:
- Open zip
- See LiamA without compression
- Inspect LiamA-draco - see that the texture is not correctly displayed on the character
- run
gltf-transform draco LiamA.glb LiamA-draco.glbto repro
Expected behavior Character looks the same with draco compression aplied
Versions:
- Version: 3.10.0
- Environment: CLI
Additional context
original and expected:
after draco:
after meshopt:
Pulling the UV islands up in Blender, note the long tail off to the right:
In short, some UVs are wild outliers, and any quantization implementation (in this case it's Draco's quantization, but my own cannot do better) will end up sacrificing quality with a larger quantization grid on the assumption that these UVs are important.
Same cause:
- https://github.com/donmccurdy/glTF-Transform/issues/936
- https://github.com/donmccurdy/glTF-Transform/issues/976
I'm curious why this happens... is it one particular DCC tool? Perhaps it's common enough that it's worth scanning for, though. The process could be something like:
- iterate over all UVs, record counts in three buckets:
- number of UVs inside [0,1]
- number of UVs inside [-24,+24]
- number of UVs outside [-24,+24]
- if the last bucket contains a trivial number of vertices compared to the first two, bring these UVs back inside a smaller range; this would require checking texture samplers, and finding an 'equivalent' UV coordinate
- log a warning so users know their input data is a bit troubled
Does this sound reasonable to you? The 24 threshold is arbitrary of course, it could be anything — I just don't want to trigger this code path for intentionally repeating UVs.
Thank you very much for looking into this - I've forwarded the question about the tool to our user and also how to fix the issue. I'll let you know when I get more information.