WebGPURenderer: MeshNormalMaterial should not be tone mapped

[WestLangley]

Description

WebGLRenderer:

MeshNormalMaterial inherits the .toneMapped property as true, but the material omits the tone mapping shader chunks, so the material is never tone mapped.

This is the correct behavior. We never want the material to be tone mapped.

WebGPURenderer:

MeshNormalMaterial responds to tone mapping. It should not. This needs to be fixed.

Note: There are other problems with MeshNormalMaterial that cause the material to be washed out when rendered with WebGPURenderer. That will be addressed in a separate PR after this issue is resolved.

Reproduction steps

Code

// code goes here

Live example

• jsfiddle-latest-release
• jsfiddle-dev

Screenshots

No response

Version

r167dev

Device

No response

Browser

No response

OS

No response

[sunag]

This is not a bug, .material.toneMapped=false and material.colorSpaced=false are not supported by WebGPURenderer. #27880 #28779 (comment) #27238 (comment)

It is still possible to use MeshNormalMaterial in RenderTarget without toneMapping, where it would have more useful.

[Mugen87]

Maybe it's important to highlight once more that WebGPURenderer does not support inline tone mapping and color space conversion. Hence, it is not possible to control which materials should be tone mapped or not. I think this is a good change since it solves #23019 and makes the tone mapping and color space step more consistent.

So WebGPURenderer always handles tone mapping and color space conversion as a separate render pass and thus processing the entire image.

[Mugen87]

The main purpose for MeshNormalMaterial is to save normals in a render target for further processing. The fact that it can be used as a "normal" material for rendering to screen is a nice side effect but not its main purpose. So retaining the visual look of MeshNormalMaterial is negligible, imo.

[WestLangley]

WebGLRenderer on the left; WebGPURenderer on the right. No tone mapping applied.

IMHO, I do not think this is acceptable. By convention, the packed normal, when interpreted as a color, is assumed to be in sRGB color space. WebGPURenderer should not be applying the sRGB transfer function to an sRGB color.

[WestLangley]

Maybe it's important to highlight once more that WebGPURenderer does not support inline tone mapping and color space conversion. Hence, it is not possible to control which materials should be tone mapped or not.

Hmm... I am inclined to think that is too restrictive. If all materials are tone mapped, I think we have to have a way to disable it.

Think of overlay text or a heads-up display. That would not normally be tone mapped.

Nor should something like AxesHelper -- and MeshLineMaterial. Also MeshBasicMaterial in certain cases.

Tone mapping can cause significant hue shifts. So can exposure control.

[sunag]

Think of overlay text or a heads-up display. That would not normally be tone mapped.

HUD is normally used in another render-pass, so it won't be affected.

[WestLangley]

What about the other issues I mentioned?

[Mugen87]

The toneMapped property was coupled to inline tone mapping. There is no way to support this property when tone mapping is applied as a pass.

@WestLangley I don't think we can achieve what you are asking for without changing some fundamentals in the renderer. I do not vote for doing this since tone mapping and color space conversion is now more correctly implemented than in WebGLRenderer.

[Mugen87]

There was always a difference when tone mapping was applied inline and when used in FX workflows via OutputPass. This difference is now finally resolved in WebGPURenderer.

[sunag]

Since AxesHelper overlaps all other objects, this could be solved with a render-pass as well.

I believe that other cases could be solved with MRT properties applied to the material and PostProcessing, such as:

material.mrtNode = mrt( { overlay: directionToColor( normalWorld ) } );

This is being developed initially here #28833

if we look at the projects from the three.js home page, I think 99% will make better use of the new system, normals for visual purposes is more related to our example.

[WestLangley]

WebGPURenderer removes the ability for users to set material.toneMapped to false, a feature which has been used by WebGLRenderer internally -- particularly for objects that do not respond to lights.

Another example use case would be text labels.

Historical context: a related post from @bhouston.

[Mugen87]

Sorry, but I think this goes in the wrong direction. The toneMapped property is controversial right from the beginning since you can solve the mentioned issues with other approaches as well. Separate, non-tone mapped render passes or optimized MRT passes should address stuff like helper objects, text labels or HUD.

If tone mapping is configured for a render output, it should affect the entire image and not specific objects. That is also true for color space conversion. Issues like #24362, #23019 or clear color related tone mapping and sRGB issues stem from the fact the engine did not implement this step correctly.

I think it's best if Material.toneMapped is deprecated as soon as WebGLRenderer is deprecated in the future.

[bhouston]

Normal, depth and velocity materials (and similar utility materials) are intended to be rendered into linear space only - never sRGB and also never tone mapped. This is because they need to be encoded consistently so that they can be decoded consistently. Thus toneMapping should never be supported on them.

[mrdoob]

Should we add more logic in the renderers to automatically render objects that shouldn't be tone mapped in a different pass?

That way we won't need to deprecate material.toneMapped... 🤔