GLTFLoader does not support texCoord fields

[stevenvergenz]

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

• Dev
• r87
• ...

[donmccurdy]

Hi @stevenvergenz — this requirement that most textures use uv1, except aoMap and lightMap which use uv2, is shared across all of three.js. It isn't possible to fix it just for a single loader without using a bunch of ShaderMaterials, which we don't want to do.

I'm not sure if there is interest/support for allowing per-texture UV sets in three.js. See: #8278

[donmccurdy]

^Which is not to say I'm opposed at all to supporting per-texture UV sets in three.js... I just don't know what the concerns/obstacles were with that previous PR.

[mrdoob]

GLTF supports per-map uvs?

[donmccurdy]

Yes, each map can specify a UV set. But also:

Client implementations must support at least two UV texture coordinate sets, one vertex color, and one joints/weights set.

So, there is an expectation that for best compatibility models should not use more than 2 UV sets.

[MiiBond]

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

[mrdoob]

@MiiBond Good to know. Thanks!

[donmccurdy]

@MiiBond could you say more about how you might use separate transforms per texture? A diffuse and occlusion map with different transforms, for example?

[donmccurdy]

If someone were to rebase and resolve conflicts on #8278, are there any changes that would make us more comfortable with it?

I like the fact that #8278 is so flexible and has a clear API, but if it seems like too much of a change, some ideas...

A. Give each material two (2) slots, rather than per-map slots.

// .map, .normalMap, .emissiveMap, ...
material.mapSlot = new THREE.MapSlot( channel1, transform1 );

// .aoMap, .lightMap, ...
material.mapSlot2 = new THREE.MapSlot( channel2, transform2 );

B. Put .channel on the Texture object, similar to .rotation:

material.map.channel = 1;

I don't like (b) as much, unless we can fix the issue that texture.clone() causes additional texture uploads.

[MiiBond]

@donmccurdy The most common use case would be for something like a detail map, typically a highly-tiled normal map to add detail at a far smaller scale than the rest of the map.

I would prefer a way to explicitly assign a UV channel and transform per map. Having slots locked to specific maps seems unnecessarily restrictive. In the case of Adobe Dimension, we will have separate transforms for each map. And, upon export to glTF, I'll be using UV1 to apply decals while still using UV0 for the underlying material (e.g. normal map).

When choosing a "channel" (i.e. UV0 or UV1), we might want to add options for common generated UV's. e.g. equirectangular projection, etc.

[goetzmoritz]

I started a disussion about this topic including some test-files here:
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/194

Actually, right now it seems that the ao-map just gets ignored when parsed by three-js gltf-plugin.

[donmccurdy]

Actually, right now it seems that the ao-map just gets ignored when parsed by three-js gltf-plugin.

Cross-posting from the other thread: "three.js is very particular about how multiple UV sets may be used. Most textures MUST use the first UV set, and ambient occlusion MUST use the second UV set. If ambient occlusion is present and only 1 set of UVs are available, a second set is automatically created at load time."

I would prefer a way to explicitly assign a UV channel and transform per map. Having slots locked to specific maps seems unnecessarily restrictive. In the case of Adobe Dimension, we will have separate transforms for each map. And, upon export to glTF, I'll be using UV1 to apply decals while still using UV0 for the underlying material (e.g. normal map).

If you're creating a new UV set for decals, why also use a per-map transform, as opposed to baking the transform into those UVs?

[MiiBond]

If you're creating a new UV set for decals, why also use a per-map transform, as opposed to baking the transform into those UVs?

We don't want separate UV channels for each map. All maps share UV0 and use transforms to tile (or rotate/translate) differently. The decals are a special case where Dimension is doing an intelligent application (i.e. a non-affine projection) of the decal on top of the material and generating its own UV's to avoid stretching, repetition, etc.