Skip to content
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

THREE.MultiplyBlending behavior #24584

Closed
emkajeej opened this issue Sep 2, 2022 · 4 comments
Closed

THREE.MultiplyBlending behavior #24584

emkajeej opened this issue Sep 2, 2022 · 4 comments

Comments

@emkajeej
Copy link

emkajeej commented Sep 2, 2022

Description
Adding a black and white material with MultiplyBlending on results in a darker image than it should be.

It's my understanding that in multiply blend mode, each pixel value should be multiplied by the pixel value below it. When adding a colored layer to a black and white layer, this should is useful for perserving details or coloring shadows without distorting the original colors.
Using software as photoshop gives the correct result. Doing this in THREE results in a darker shade of the original color.

Consider the pen below.
The plane has one StandardMaterial, full white. Adding another white material on top of this should not have any visual effect on the render. However it appears slightly darker than the original material was. It's noticeable in default tonemapping; Using ACESFilmicToneMapping amplifies this problem.

Click the button to toggle the top layer.
https://codepen.io/emkajeej/pen/XWqWMVa

Same with actual images:
https://codepen.io/emkajeej/pen/abGoByg
The mutiplied image is mostly white, with some light gray streaks. Notice how the entire image is darkened, however.

r144

@Mugen87
Copy link
Collaborator

Mugen87 commented Sep 2, 2022

With basic renderer settings, the result is as expected: https://jsfiddle.net/35nfmkxb/

The problem is that blending is not performed correctly when tone mapping and color space conversion is done inline via GLSL (so prior to blending). This issue is already discussed here: #23019

@mrdoob
Copy link
Owner

mrdoob commented Sep 2, 2022

The problem is that blending is not performed correctly when tone mapping and color space conversion is done inline via GLSL (so prior to blending). This issue is already discussed here: #23019

Oh, I missed that issue. That's annoying... we can't use OpenGL blend modes anymore...

@emkajeej
Copy link
Author

emkajeej commented Sep 4, 2022

Does that mean that the only way to get proper blending and tonemapping, each frame has to be color corrected in post? That seems like a massive overhead, and quite unfortunate if that's the case.
That would also only account for part of the issue, as physicallycorrectlights has an impact on this as well.. and I assume that's not something that can be changed in post.

My workaround for now, I think, is to blend the images in a separate canvas first and push that as a texture to the material.

@Mugen87
Copy link
Collaborator

Mugen87 commented Sep 5, 2022

Does that mean that the only way to get proper blending and tonemapping, each frame has to be color corrected in post?

Yes. As mentioned above, a post processing step is required for the most color accurate rendering.

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

No branches or pull requests

3 participants