Fix GUI colors in webgpu_compute_cloth example

[WestLangley]

Fixes: #31130 (comment) by decoupling the GUI colors from color management.

The material color set in the GUI does not match the rendered material color.
The problem is due to ColorManagement, which modifies the color behind the back of the user.

[WestLangley]

This PR is a fix for now, but IMHO this is a manifestation of a design problem.

I do not like the engine changing the user's data.

I think it would be better if THREE.Color had a .colorSpace property.

The renderer would then copy the color and call _color.toWorkingColorSpace().

I think this could be implemented in an efficient manner (by a clever dev) so the color is not converted every frame.

/ping @donmccurdy

[donmccurdy]

I'm OK with the idea of THREE.Color having a .colorSpace property in principle. To me that means moving some conversions 'deeper' into the renderer, perhaps at the time that uniforms are uploaded to the GPU. Assuming the default Color#colorSpace is the linear working color space, I'm not sure that these functions...

color.setHex( 0x808080 );
color.setStyle( 'goldenrod' );

... should work any differently than they do now; setters should probably not modify the object's color space, and the conversion should still be applied at time of input if we know the input is sRGB and the Color instance is not. On the other hand this...

color.colorSpace = SRGBColorSpace
color.setHex( 0x808080 );

... could be made to keep RGB components in sRGB, and defer the conversion until the color needs to be used in the working color space later. Is that compatible with what you had in mind, @WestLangley?

So it is mainly a question of when (not if) to convert colors from the input color space (usually sRGB) to the working colorspace (necessarily linear, usually Linear-sRGB), and to make that as intuitive as possible for library users?

It would also be possible (and not mutually exclusive with adding a Color#colorspace property) to have color pickers themselves be color managed. I've proposed something like that for lil-gui, and native HTML color pickers might be headed the same direction, although it's a long way from general support, and not clear that linear color spaces will be included later.

• https://webkit.org/blog/16900/p3-and-alpha-color-pickers/
• https://caniuse.com/mdn-html_elements_input_colorspace

[WestLangley]

Yes, I generally agree. However, I do not have strong feelings as to how this should be implemented so it is efficient.