Incorrect combined metal+rough textures when 1 input is not connected to a texture

[maoliver-amd]

Describe the bug
With recent versions of the exporter the behaviour of exported combined rough+metal texture has been changed when 1 of the roughness/metallicity material parameters is a texture while the other is a fixed constant. This change was introduced in PR #1968. Previously when generating the combined texture only values for parameters with a connected texture were written to the output texture with all other channels being set to 1.0. After the change the fixed constant is being written to all pixels in place of the previous written 1.0. This is incorrect as the same value is being written to the materials base factor ASWELL as now to the texture component (e.g. if we had a base roughness of 0.1 then the output gltf has 0.1 written into the texture and 0.1 written to roughnessFactor which results in incorrectly calculated final roughness = 0.1*0.1).

To Reproduce
Steps to reproduce the behavior:

1. Create a material with a texture connected to the metallicity parameter
2. Set the roughness to a constant value (e.g. 0.1)
3. Export GLTF
4. Compare exported combined metal+rough texture which has 0.1 written into the texture corresponding roughness channel ASWELL as having 0.1 written to the materials roughnessFactor in the gltf
5. The same issue occurs if switching metal/roughness in the steps above

Expected behavior
Previous versions of the exporter handled this correctly. The rough/metal value in the presence of a texture is equal to the base factor multiplied by the texture value. In the above example the roughness is calculated with base factor (roughnessFactor) multiplied by the roughness channel of the texture. This should result in a final value matching the one set in blender (here 0.1) but due to the change in exported textures now does not (here 0.1*0.1 = 0.01). For rough/metal texture channels with an unconnected texture the texture should contain 1.0 as with previous versions of the exporter.
From the GLTF spec:
The value for each property MAY be defined using factors and/or textures (e.g., baseColorTexture and baseColorFactor). If a texture is not given, all respective texture components within this material model MUST be assumed to have a value of 1.0. If both factors and textures are present, the factor value acts as a linear multiplier for the corresponding texture values.

Screenshots
Example material:

using following texture for metallicity:

Exported combined metal+roughness texture for different blender versions

3.6.5 (correct)	4.0.1 (incorrect)

Corresponding material in exported GLTF from 4.0.1 (note this is identical to 3.6.5):

{
			"name":"Material",
			"pbrMetallicRoughness":{
				"baseColorFactor":[
					0.800000011920929,
					0.800000011920929,
					0.800000011920929,
					1
				],
				"metallicRoughnessTexture":{
					"index":0
				},
				"roughnessFactor":0.10000000149011612
			}
		}

Comparison of exported GLTF as viewed in babylonjs:

3.6.5 (correct)	4.0.1 (incorrect)

.blend file/ .gltf
blenderTest.zip

Version

• OS: Any
• Blender Version 4.0+

[julienduroure]

Confirmed

[julienduroure]

This is now fixed in 4.1 alpha
As this is a regression, I will try to make it included in 4.0.x maintenance release.