NormalScale in USDZ Exporter

[Patrick-van-Halm-360Fabriek]

Description

Within the USDZ exporter it seems like the NormalScale seems disregarded. I would like to have this included so normals can be more excessive in certain cases.

Solution

Within the USDZ exporter include the materials NormalScale when generating the texture/material.

Alternatives

None

Additional context

No response

[Mugen87]

The relevant code section in USDZExporter is:

three.js/examples/jsm/exporters/USDZExporter.js

Lines 535 to 549 in b38ef16

	def Shader "Texture_${ texture.id }_${ mapType }"
	{
	uniform token info:id = "UsdUVTexture"
	asset inputs:file = @textures/Texture_${ id }.png@
	float2 inputs:st.connect = </Materials/Material_${ material.id }/Transform2d_${ mapType }.outputs:result>
	${ color !== undefined ? 'float4 inputs:scale = ' + buildColor4( color ) : '' }
	token inputs:sourceColorSpace = "${ texture.colorSpace === NoColorSpace ? 'raw' : 'sRGB' }"
	token inputs:wrapS = "${ WRAPPINGS[ texture.wrapS ] }"
	token inputs:wrapT = "${ WRAPPINGS[ texture.wrapT ] }"
	float outputs:r
	float outputs:g
	float outputs:b
	float3 outputs:rgb
	${ material.transparent || material.alphaTest > 0.0 ? 'float outputs:a' : '' }
	}`;

[Mugen87]

According to https://openusd.org/release/spec_usdpreviewsurface.html, UsdUVTexture has the input scale which is of type float4. The normalScale property in three.js is of type Vector2 and only affects the x and y property.

Since we are already using scale in context of color, I guess it needs an enhanced treatment so normal scale is supported as well.

[Mugen87]

I've added a fix here: Mugen87@8ce5b04

When loading glTF assets, the y component of normal scales are inverted when no tangents are present to accommodate three.js uv/tangent conventions (see #11438 (comment)).

The above documentation says about USDZ:

if we are viewing, on the same monitor, an axis-aligned quadrilateral and a texture image, the lower left-hand corner of the quadrilateral should be the (0, 0) st coordinate, which maps to the lower left-hand corner of the image as the (0, 0) uv coordinate. More specifically, for the four vertices of a quadrilateral, in order, the st coordinates should be [ (0, 0), (1, 0), (1, 1), (0, 1) ].

It seems the uv conventions of USDZ are equal to three.js but does that mean we can export normal scales without further modifications?

@Patrick-van-Halm-360Fabriek I have tested the linked fix on macOS with Preview but I'm not able to see any differences when normal scale is present (tested with misc_exporter_usdz). Are you able to test with a different software and check if the fix works?

[Patrick-van-Halm-360Fabriek]

For me the change doesn't do much. I do have a question tho, are the scales clamped from 0 to 1 in USDZ. Cause the normals scales I have in my file are [2.0, -2.0]. If so how would I be able to achieve this in USDZ?

[Mugen87]

are the scales clamped from 0 to 1 in USDZ

At no place I have read something about a value range for scale. It's also not clear to me if the values are allowed to be negative.

[Patrick-van-Halm-360Fabriek]

As for reference:

In the editor it looks like the following. It's an imported GLB file with applied materials and textures. The textures are in WebP format.

Within the ARcore functionality you can view the normal from quite a distance, this due to the normal scale being applied.

Within quicklook you can see that the normal is only visible when you get real close hence the thought of the normal scale not being applied.

[Mugen87]

If we start honoring normal scale, glTF assets exported to USDZ will look different in viewers supporting normalScale. Can you try exporting the glTF asset from misc_exporter_usdz with and without the fix and make a comparison? It would be great if you could share screenshots again.