Texture sharing multiple channel using different color-space encoding / srgb

[Samsy]

I've hit a little texture preview difference between those two models on the threejs viewer.

The one on the left is the original one, the one on the right is just a simple copy of the glb using gltf-transform :

gltf-transform copy original.glb transformed.glb

I know this model is a bit weirdly done, it is using the same texture for diffuse and aoMap.

On the left render, the same image is loaded twice as two different texture, applying sRGB into the diffuse map, and no color-spacing for the aoMap

On the right render, both diffuse and aoMap and using the same texture, same uuid, therefore sharing the same color-spacing : sRGB which results in color difference

Left one, two textures loaded

Right one :

I investigated a lot since 2 days, but cannot find where things are wrong !

There might be something I'm missing here

Original file :

https://github.com/Samsy/glbs/blob/main/originalmask.glb

Transformed file using gltf-transform :

https://github.com/Samsy/glbs/blob/main/transformedmask.glb

[donmccurdy]

Thanks @Samsy! I'm not sure whether to consider this a bug in glTF Transform or in three.js. Following up here:

• Images used by textures with different color spaces?  KhronosGroup/glTF#2308

[Samsy]

Regarding the issue raised into KhronosGroup I'm not sure to understand then,
Is this an issue with the threejs gltf loader or is it inherent with the transformation ?

[donmccurdy]

I think that question remains unanswered, but Gary's comment suggests we'll probably fix it in glTF Transform, not in three.js.

[donmccurdy]

Hm, one other thing I should flag here. This model is using not only the same texture for base color and occlusion, but the same UVs and UV transform as well. This would mean the material is using the the red channel of the base color texture, and sampling exactly the same pixels in both.

This would make more sense if AO and base color data were in different areas of the image, but as-is there's no way that can be correct... so I think there might be some misunderstanding in the source model or C4D's exporter here perhaps?

[donmccurdy]

I've filed #1076 to track this as a feature request, but it's looking more complex than I'd hoped to change, so I'm not sure what is going to happen yet.