three.js: GLTFLoader does not support texCoord fields

Description of the problem

Today, the Three.js engine does not allow the use of arbitrary UV coordinate sets for textures. Instead, they’re hardcoded to channel 0 for all textures, except for lightMap which uses channel 1. As a result, the texCoord property of glTF textureInfo objects are ignored. Thus, the glTF loader is not compliant to the spec.

Once the engine supports UV channels better, this issue is a reminder to update the loader too.

Three.js version

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 19 (7 by maintainers)

Most upvoted comments

I am currently running into this issue with our glTF exports from Clara.io. We should make Three.JS up to specification and it is also just an important feature for Three.JS.

bhouston on May 7, 2018

This is working nicely with NodeMaterial. Still constrained to two UV slots for now, but the textures can be assigned arbitrarily.

MeshStandardMaterial	StandardNodeMaterial

model from sketchfab and modified GLTFLoader code

donmccurdy on Jul 15, 2018

Just to chime in on this, Adobe Dimension’s glTF exporter (which I’m currently writing) requires the second UV channel to display decals correctly. We’ll also be supporting separate transforms per texture in the near future which will also be problematic for three.js. Time for a refactor of how three.js materials use textures 😃 #8278

MiiBond on Apr 12, 2018

It’s conceptually trivial to solve this problem with existing Material functionality.

http://dusanbosnjak.com/test/webGL/three-materials-extended/webgl_materials_extended_multiple_uvs_props.html

With onBeforeCompile each “built-in” material can be selectively modified. For this use case, there are several texture2D( <mapName>, vUv) calls. One can add additional inputs for each map (i added two vec2 but could be the same pattern as the new texture transforms) and override vUv. One can safely ignore the remaining 1000+ lines of the shader.

pailhead on May 30, 2018