WebGPU environment map shading differs from WebGL in WebGPURenderer

[TobiasNoell]

Description

There are significant differences in WebGPU vs. WebGL environment map shading in WebGPURenderer when using a MeshPhysicalNodeMaterial with a normalNode that is served by a THREE.DataTexture and a roughnessNode of 1.

WebGL shading is the correct one that considers the normals, WebGPU shading seems to ignore those completely.

WebGL: (forceWebGL: true)

WebGPU: (forceWebGL: false)

Reproduction steps

1. Open attached fiddle on a device that supports WebGPU
2. Normals are ignored during shading
3. Toggle forceWebGL to true
4. Normals are considered during shading

Code

See attached fiddle

Live example

• jsfiddle-latest-release WebGPURenderer

Screenshots

No response

Version

r182

Device

Desktop

Browser

Chrome

OS

Windows

[TobiasNoell]

Can it be that for the environment map lookup only the geometry normal is considered in WebGPU mode and not the fragment normal?

[Mugen87]

My observation from a macMini:

On macOS with Chrome:

• Both WebGL and WebGPU shows the noise pattern like in your first screenshot.

On macOS with Safari:

• WebGL shows the noise pattern but WebGPU does not. You see just the orange color like in your second screenshot.

On macOS with Firefox:

• Both WebGL and WebGPU shows the noise pattern but the WebGPU version looks magnified.

[TobiasNoell]

The issues seem to be mostly related to higher roughness values
Lower roughness values are pretty consistent between WebGL and WebGPU

[TobiasNoell]

Actually, there seems just something wrong as roughness approaches 1

[TobiasNoell]

Actually, it can be fixed by this:

I am just not sure if this is the correct way to do this, or if the fact that it needs to be clamped in the first place is hinting towards a deeper issue somewhere else... 🤔

[Mugen87]

I'm trying a few things out to get a better understanding of the root cause. Can you please try to comment out the following line:

three.js/src/nodes/accessors/TextureNode.js

Line 389 in 399951c

levelNode = builder.context.getTextureLevel( this );

Does this solve the issue?

[TobiasNoell]

Yes, this fixes it! It also fixes issues at larger zoom levels I was experiencing that were not fixed by the clamped version above.

Interestingly, a Claude Code session I was running in the background just came to the same fix, with the following explanation:

Not 100% sure if this makes sense as an explanation, though 😄

[Mugen87]

If you give your normal map a name and set a break point in below line, you can easily detect it uses the roughness level snippet. When I saw that in the debugger, it was clear what's happening.

three.js/src/nodes/accessors/TextureNode.js

Lines 491 to 495 in 399951c

	} else if ( levelSnippet ) {
	snippet = builder.generateTextureLevel( texture, textureProperty, uvSnippet, levelSnippet, depthSnippet, offsetSnippet );
	} else {

I would suggest to remove the entire block in TextureNode since getTextureLevel() only makes sense in context of PMREMs/EnvironmentNode. Hence, it should only be used to query the roughness node for the roughness-to-mip conversion.

It maybe makes sense to rename getTextureLevel() to getRouhgness() to avoid confusing about its purpose.

Do you mind setting up a PR?

[TobiasNoell]

Sure, I can create a PR today 👍
Regarding the potential renaming of getTextureLevel() there would still be some usage in Background.js that might be affected where the getRouhgness() name might not make sense, or what do you think?

three.js/src/renderers/common/Background.js

Line 94 in 399951c

getTextureLevel: () => backgroundBlurriness

[Mugen87]

Yeah, let's avoid the renaming and just fix the bug. I've realized a new name also affects example code so we would have to deprecate getTextureLevel(). To avoid migration tasks, it's better to keep getTextureLevel() for now.

[Mugen87]

I would suggest to remove the entire block in TextureNode since getTextureLevel() only makes sense in context of PMREMs/EnvironmentNode. Hence, it should only be used to query the roughness node for the roughness-to-mip conversion.

That said, maybe @sunag finds a way to limit the scope of the context so other texture nodes are not affected.