Skip to content

Fix GUI colors in webgpu_compute_cloth example #31232

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 6, 2025

Conversation

WestLangley
Copy link
Collaborator

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
Copy link
Collaborator Author

WestLangley commented Jun 6, 2025

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

@WestLangley WestLangley marked this pull request as ready for review June 6, 2025 02:46
@WestLangley WestLangley added this to the r178 milestone Jun 6, 2025
@Mugen87 Mugen87 merged commit 5ed64a4 into mrdoob:dev Jun 6, 2025
11 checks passed
@WestLangley WestLangley deleted the dev-cloth_gui branch June 6, 2025 10:12
@donmccurdy
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants