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.26 78.64	337.26 78.64	+0 B +0 B
WebGPU	551.5 152.93	551.63 152.97	+129 B +35 B
WebGPU Nodes	550.85 152.78	550.98 152.81	+129 B +35 B

🌳 Bundle size after tree-shaking

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

	Before	After	Diff
WebGL	468.44 113.28	468.44 113.28	+0 B +0 B
WebGPU	626.53 169.61	626.66 169.65	+129 B +37 B
WebGPU Nodes	581.38 158.94	581.51 158.98	+129 B +37 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.