three.js: Setting Material.blending to "CustomBlending" no longer works blends as expected

Describe the bug

As of r137 using “CustomBlending” does not work as expected.

To Reproduce

Create a material that uses “CustomBlending” and a partial opacity. In r136 it is rendered as partially transparent while in r137 it is not.

Code

const material = new THREE.MeshBasicMaterial( {
  blending: CustomBlending,
  opacity: 0.5
} );

Live example

https://jsfiddle.net/c9v0jdrL/

Expected behavior

When using custom blending it renders as partially transparent as it did in r136.

Screenshots

From the js fiddle above. Left is a regular transparent cube. Right is using CustomBlending.

r136	r137

Platform:

Device: Desktop
OS: MacOS
Browser: Chrome
Three.js version: r137.5

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 19 (8 by maintainers)

Most upvoted comments

Basically, apparently many systems do not create a webgl context with alpha: false so the browser has to emulate it.

My main laptop (Intel MacBook Pro 2016) is one of the worst cases apparently, so I’ve been dealing with subpar performance and noisy fans for years… Now it feels like a brand new laptop 😬

mrdoob on Feb 2, 2022

Hmmm… I would have expected the default values for CustomBlending match the values that produce NormalBlending. At least doing so would have been a reasonable default.

It did previously…

Well, if that were the case, then you would have had no reason to use the default CustomBlending because it would have been the same as NormalBlending. Right?

WestLangley on Feb 2, 2022

I don’t think the alpha: true flag change should be reverted – just that a different solution be used to address this artifact pointed out above.

Setting transparent to false essentially means to me “alpha blending is disabled”.

This is an unnecessarily heavy handed approach, I think. At the least blending could still be applicable when blending === CustomBlending so the capability isn’t completely neutered. But I’m going to look at a couple options later today when I get a chance.

gkjohnson on Feb 2, 2022

If you’re able to figure out the right dst/src/dstAlpha/srcAlpha to use here that avoids having to do gl_FragColor.a = 1.0 in the shader that’d be great. @Mugen87 and I tried but we couldn’t figure it out.

mrdoob on Feb 2, 2022

That one is wrong. In this case the cube shouldn’t have that white tinting.

This is the normal case that’s demonstrating the regression that was fixed in #23361. The other table rows are showing workarounds and behavior with different blend modes that work more as expected. With the fix I’m proposing the NormalBlending case will behave like the CustomBlending case with the equation adjustments I posted. I’ll look into a PR this week.

Perhaps there are better ways to handle this that make background / browser blending work more intuitively but I’d have to look into it more.

Hmmm… I would have expected the default values for CustomBlending match the values that produce NormalBlending. At least doing so would have been a reasonable default.

It did previously and it still does when .transparent === true but this seems to be a new blending quirk of defaulting the canvas to alpha = true.

gkjohnson on Feb 2, 2022

Hmm, isn’t there any other way of achieving the same thing? I wouldn’t want to revert #23361.

mrdoob on Feb 2, 2022