Issue with quantization and KHR_materials_volume

[donmccurdy]

Originally reported at mrdoob/three.js#22343, but it appears that the renderers are correct and both gltfpack and gltf-transform have a similar issue in quantizing models using the KHR_materials_volume extension. When compressing or quantizing this example:

Left: Original. Right: gltf-transform. Below: gltfpack.

https://github.com/mrdoob/three.js/files/6996178/Archive.zip

...the boxes should all be the same color, before and after compression. Instead they get lighter (for non-normalized vertex attributes) or darker (for normalized vertex attributes) because the node's scale affects the material.thicknessFactor property. I believe it's necessary to apply the inverse of the node's scale to the thickness, to compensate.

[zeux]

Thanks. This is unfortunate, since this also means the presence of the volume material should block mesh merging.

[zeux]

I think there's probably still some sort of bug in three.js here - after fixing this on gltfpack side all rows now look identical in quantized and non-quantized versions except for the row with thickness texture:

Maybe the thickness texture doesn't have the UV transform applied to it? This works correctly in Babylon.JS afaict.

[zeux]

Here's a file after the fix for testing:

attenuation-q.zip

[zeux]

Yeah seeing the same problem with texture in three.js on DragonAttenuation [which is a much nicer looking test model albeit not as pedantic as the one above :D]. Since this renders correctly in Babylon I'm going to assume it's an issue with UV xform and merge the fix here.

[zeux]

three.js issue has been fixed in mrdoob/three.js#22364

[donmccurdy]

Thank you for the quick fix and the three.js patch here!