NodeMaterial: Honor material.premultipliedAlpha in the shader

[WestLangley]

As the title says.

The alternative is to only add this code block in the built-in (node) materials -- as we do with WebGLRenderer's built-in materials.

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

	Before	After	Diff
WebGL	337.4 78.67	337.4 78.67	+0 B +0 B
WebGPU	554.99 153.64	554.99 153.64	+0 B +0 B
WebGPU Nodes	554.34 153.49	554.34 153.49	+0 B +0 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

	Before	After	Diff
WebGL	468.59 113.33	468.59 113.33	+0 B +0 B
WebGPU	629.96 170.36	629.96 170.36	+0 B +0 B
WebGPU Nodes	584.81 159.69	584.81 159.69	+0 B +0 B

[Mugen87]

The E2E screenshot of webgpu_postprocessing_ssaa requires an update since SSAAPassNode already sets material.premultipliedAlpha to true (this has been adopted from the old SSAARenderPass).

[Mugen87]

The alternative is to only add this code block in the built-in (node) materials -- as we do with WebGLRenderer's built-in materials.

Since premultipliedAlpha is a Material property, I would expect it works with all materials. I prefer this new approach compared to support just for built-in materials.

[WestLangley]

Since premultipliedAlpha is a Material property, I would expect it works with all materials. I prefer this new approach compared to support just for built-in materials.

Well, yes, but maybe you misunderstand what its purpose is...

Material.premultipliedAlpha is a hint to the renderer that the output of the shader returns premultiplied color values. That way, the renderer will set the proper blending function. It works for all materials.

In the case of built-in materials, the shader itself must also be modified to return premultiplied values instead of non-premultiplied values.

So built-in materials and custom materials are different in this regard.

Unfortunately, Material.premultipliedAlpha is serving double-duty and affects both the blending function (for all materials), and the shader itself (for built-in materials only).

[Mugen87]

Yeah, the double purpose of premultipliedAlpha came along in the past multiple times. But why do you think is it unfortunate? If the blending assumes premultiplied colors, the materials should honor that setting and produce the correct output in their shaders. Regardless of built-in or custom materials (this distinction isn't that relevant for node materials anyway).

The node material seems a good opportunity to establish a policy that produce more consistent outputs no matter if you customize a material or not.

AFAICS, if the developer needs full control, it's always possible to use custom blending, don't change premultipliedAlpha and then apply a custom color transformation in the shader.

[WestLangley]

Material.premultipliedAlpha is serving double-duty

But why do you think it is unfortunate?

Consider this use case:

renderer.setRenderTarget( renderTarget ); 
renderer.render( scene, camera );

In such a case, renderTarget.texture will have RGB premultiplied by alpha.

Now, use the render target texture as a map:

const material = new THREE.MeshBasicMaterial( {

	map: rederTarget.texture

} );

The material shader will outut premultiplied colors, but the renderer will use the wrong blending function.

So, try this instead:

const material = new THREE.MeshBasicMaterial( {

	map: rederTarget.texture,

	premultipliedAlpha: true

} );

Now this is wrong because the shader will pre-multiply the colors a second time.

[WestLangley]

@Mugen87 @sunag Do you understand what the issue is?

Currently, you can't pass in a texture with premultiplied data to any built-in material and expect to see correct output.

It is also pointless to set texture.premultiplyAlpha.

This PR, as currently written, is of no help.

[sunag]

I think one way out could be apply an unpremultiplyAlpha() function to all texture samples with premultiplyAlpha if it is defined in the material as material.premultipliedAlpha=true.

[WestLangley]

@sunag There are other problematic cases. A texture can contain premultiplied color values, in which case setting texture. premultiplyAlpha = true would not be appropriate.

[sunag]

A texture can contain premultiplied color values, in which case setting texture. premultiplyAlpha = true would not be appropriate.

I'm considering we can do this check a bit deeper in the backend like

const premultiplyAlpha = texture.premultiplyAlpha === true || texture.isRenderTargetTexture === true ...

I'm not sure now how many properties we should check, but it might be the way to go.

[WestLangley]

@sunag Any texture can contain premultiplied color values.

[WestLangley]

There does not appear to be valid solutions to the issue I raised, so I suggest merging this and dealing with the issue later.

The E2E screenshot of webgpu_postprocessing_ssaa requires an update

I would say the screenshot is not the problem. The code is the problem.

[sunag]

@sunag Any texture can contain premultiplied color values.

Certainly, but I thought we were trying to automate a common routine here and not trying to hit every possible case. In this case we wouldn't even need anything special, the user just needs to call a function for this using node-based material.

const material = new THREE.MeshBasicMaterial();
material.premultipliedAlpha = true;
material.colorNode = unpremultiplyAlpha( texture( renderTarget.texture ) );