GLTFExporter: Normal Texture handedness

[jeyashankher]

GLTF Loader: Fix for handedness in Normal Texture:
#11825

KhronosGroup/glTF#952

https://github.com/mrdoob/three.js/blob/master/examples/js/loaders/GLTFLoader.js#L2204
material.normalScale.y = - material.normalScale.y;

Given that the loader needs to adjust this, should the exporter be adjusting this as well?

Please do correct me if I'm wrong, but the current code does not seem to account for this.

		if ( material.normalMap ) {

			gltfMaterial.normalTexture = {

				index: processTexture( material.normalMap )

			};

			if ( material.normalScale.x !== - 1 ) {

				if ( material.normalScale.x !== material.normalScale.y ) {

					console.warn( 'THREE.GLTFExporter: Normal scale components are different, ignoring Y and exporting X.' );

				}

				gltfMaterial.normalTexture.scale = material.normalScale.x;

			}

		}

Three.js version

• [x ] Dev
• r95
• ...

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

Hardware Requirements (graphics card, VR Device, ...)

[WestLangley]

Related: #13784 (comment) and the ensuing thread.

[jeyashankher]

@WestLangley Thanks for the reference. Missed that.

Some investigation from my side if it helps:

I tried flipping UVs in processMesh() of the exporter and turning off the flipY condition in processImage(), and it looks like the output is fine in GLTFLoader.

There is still an issue with the UVs though. The UV Map seems to be translated now. I imported the gltf into blender using https://github.com/ksons/gltf-blender-importer

Original UV map of a cube.

UV Map with the current exporter (without UV flipping).

UV Map with UV flipping.

[mrdoob]

/cc @fernandojsg @takahirox

[jeyashankher]

Looks like the translation was due to a bug in the importer. It now looks ok.

Does look like flipping UVs in processMesh works ok.

[WestLangley]

/ping @donmccurdy

[donmccurdy]

Can you share an example where the current behavior is not setting up the normal map correctly, and your proposed fix? We cannot flip the UVs blindly, because we don't know the UV coordinate system. A few thoughts:

1. We could take texture.flipY as an indication of UV coordinate system, but this will be more complex e.g. if there are multiple textures involved.
2. The texture transform extension (KHR_texture_transform) is another option, but brings its own complexities.
3. glTF accepts only a scalar normal scale, so the approach used by GLTFLoader cannot be extended to GLTFExporter.

[jeyashankher]

@donmccurdy

Apologise for the delay in responding. The example I had where this wasn't working is a proprietary asset and I cannot share it. Trying to construct an example but am not being very successful (not a 3D modelling person).

In our project, we are interested in export only and the mesh is transient and not used further. So, it seemed ok to just modify the geometry.

For threejs exporter, I don't have an elegant suggestion.

If we have to flip UVs, the right place to do it is where we create the BufferView. One option is to special case the processBufferView code for UVs and write out a flipped UV. Similarly, processImage should not flip the texture.

If we choose to not flip UVs, the normals needs to be transformed to match gltf coordinate system, I guess. Not sure how to do that.