Ambient occlusion uses TEXCOORD_1 instead of TEXCOORD_0

[echadwick-artist]

Describe the bug
When both TEXCOORD_0 and TEXCOORD_1 are present, three.js will use TEXCOORD_1 for ambient occlusion.

However TEXCOORD_0 is expected behavior for content authors, because 0 is the default in the spec when the author has not specified TEXCOORD_1 in the material via the texCoord property, nor via the KHR_texture_transform extension.

Other common glTF renderers seem to use the default TEXCOORD_0 when rendering this example model.

To Reproduce

1. Download attached example ZIP file, and extract the GLB.
2. Load the GLB in https://threejs.org/editor/
3. Result: "Incorrect" text is shown for occlusion.

Expected behavior
"Correct" text should be shown for occlusion, if TEXCOORD_0 is being used as intended.

Screenshots

Screenshots from Visual Studio Code, with glTF Tools extension.

Platform:

• Device: desktop
• OS: Windows 10
• Browser: Chrome
• Three.js version: r142

Example file
occlusiontest_gltf.zip

Thanks for listening!

[donmccurdy]

Related:

• GLTFLoader does not support texCoord fields #12608

tl;dr — three.js will always use TEXCOORD_1 for AO and TEXCOORD_0 for everything else, regardless of any texCoord fields. If TEXCOORD_1 does not exist, three.js can generate it from TEXCOORD_0 when needed by AO.

[WestLangley]

three.js built-in materials always use TEXCOORD_1 for AO and light maps, and TEXCOORD_0 for everything else.

[echadwick-artist]

OK thanks for the replies. I bet we can strip out the unused TEXCOORD_1 from our models; it's an artifact of a vendor's conversion process. Asking over here if this would be possible with glTF-Transform: donmccurdy/glTF-Transform#610

[donmccurdy]

Good point on lightmaps, yes — I've added a longer response at donmccurdy/glTF-Transform#610. We'd like to fix this of course, but I'm not sure whether we'll have a 'dedicated solution' for the problem in the current material system, of if it will require the upcoming node-based material system to solve. Closing here since this is also tracked in #12608.