This issue was raised in #28831 (comment).

I am disappointed it was considered not worthy of being fixed.

This issue was raised in #28831 (comment).

I am disappointed it was considered not worthy of being fixed.

I was able to do a dirty fix by simply moving the color space into workingColorSpace. I'll modify the example to demonstrate. WTS.

Live WebGPU Example

Relevant code:

if ( this.emulateWebGLOutput ) {

      diffuseColor.assign( toWorkingColorSpace( vec4( directionToColor( transformedNormalView ), opacityNode ), SRGBColorSpace ) );

} else {

     diffuseColor.assign( vec4( directionToColor( transformedNormalView ), opacityNode ) );

}

EDIT: Reading the original issue, I can understand and agree with most of the justifications for removing per material tone mapping. However, it would be nice to have more explicit documentation within the renderer itself explaining some of the philosophical differences between the WebGLRenderer and the WebGPURenderer. From my initial naive perspective, which is likely to be shared by a lot of people making the switch to the WebGPURenderer for the first time, this reads as a bug, even if it's an intentional and or negligible side effect of a shift in philosophy.

Maybe for some materials there could be a property like 'emulateMaterialToneMapping' that reverts the color of the material to its expected WebGLRenderer output in cases where the intent is to have strict parity with the WebGLRenderer.

However, it would be nice to have more explicit documentation within the renderer itself explaining some of the philosophical differences between the WebGLRenderer and the WebGPURenderer. From my initial naive perspective, which is likely to be shared by a lot of people making the switch to the WebGPURenderer for the first time, this reads as a bug, even if it's an intentional and or negligible side effect of a shift in philosophy.

We are in the process of improving documentation so this issue is on our list.

If somebody is interested in adding a new manual page in https://threejs.org/manual/, I would definitely invest time in supporting any efforts (in the weeks I will focusing on JSDoc though). It could be a page that explains the differences between WebGLRenderer and WebGPURenderer.

Tone mapping and color spaces are one topic, post processing, clipping, custom materials others.

Maybe for some materials there could be a property like 'emulateMaterialToneMapping' that reverts the color of the material to its expected WebGLRenderer output in cases where the intent is to have strict parity with the WebGLRenderer.

TBH, I do not support this. If you really need more flexibility, use PostProcessing and set postProcessing.outputColorTransform to false. Now tone mapping and color space conversion is really up to you. Like controlling which objects receive bloom, you could do the same for what objects should receive a color transform. Or simply render certain objects with a second non-tone mapped pass.

TBH, I do not support this. If you really need more flexibility, use PostProcessing and set postProcessing.outputColorTransform to false. Now tone mapping and color space conversion is really up to you. Like controlling which objects receive bloom, you could do the same for what objects should receive a color transform. Or simply render certain objects with a second non-tone mapped pass.

Fair enough, I'll close the issue since this topic has been discussed quite extensively across other issues.