Three.js: GLTFLoader: Incorrect .format assigned when .map === .emissiveMap

[hybridherbst]

Description of the problem

BLEND mode when loading a gltf is broken in three.js if a material has both texture + emission texture. Interestingly, a broken material will also break all other transparent materials (e.g. adding a 3rd object with a broken material will break totally separate materials on objects 1 + 2).

A workaround, for whatever reason, is to use KHR_Texture_Transform - if TexTransform is present on a material, it will not break but instead display texture + emission texture correctly.

Live reproduction:
https://glitch.com/edit/#!/spice-water-dormouse

Three.js version

• [X] r114

Note that this breaks in all of the following:

• Visual Studio Code glTF extension, only in three.js mode, Cesium and Babylon work fine
• model-viewer (e.g. your https://model-viewer-tester.glitch.me/)
• https://gltf-viewer.donmccurdy.com/

Browser

• [x] All of them
• [ ] Chrome
• [ ] Firefox
• [ ] Internet Explorer

OS

• [x] All of them
• [ ] Windows
• [ ] macOS
• [ ] Linux
• [ ] Android
• [ ] iOS

[donmccurdy]

For the "Single material with texture + emission texture - BROKEN" example, here's the file:

7b12eac1-bb99-49d9-ac6c-f43419a2fbbe_Root-Transparency-BROKEN.glb.zip

The issue here seems to be that .map and .emissiveMap both use the same texture. Our assignment of texture.format happens in two places:

https://github.com/mrdoob/three.js/blob/624485b85c39d41857b630bc9374cca637d6a0ab/examples/js/loaders/GLTFLoader.js#L1832-L1837

https://github.com/mrdoob/three.js/blob/624485b85c39d41857b630bc9374cca637d6a0ab/examples/js/loaders/GLTFLoader.js#L1865-L1879

The latter, at least, is a problem – it doesn't check to see if the texture is reused. We probably need to pre-mark the texture as RGBA so that use as an emissive map won't change its format. Probably the same issue with the additional 3rd material, but I haven't checked that model specifically yet.

[hybridherbst]

I see. So that basically means, if a texture is used anywhere as ao, emissive, metalness, normalmap or roughness map the alpha channel for all other usecases everywhere will currently be discarded. Good to know, thanks for the analysis of what's actually going on - allows for another workaround ("just" duplicating the texture).

Any idea why using TexTransform would break the spell? seems when TexTransform is used the texture is cloned before being marked as RGB and thus alpha channel survives on the albedo texture - see https://github.com/google/model-viewer/issues/1068#issuecomment-593622169.

Also, here's all the models in the glitch zipped, sorry for not uploading that with the report:
Issue-18796-models.zip