WebGPURenderer: Support MSAA with Postprocessing

[RenaudRohlinger]

Description

The WebGPU did not support MSAA with a post-processing pipeline. This PR fixes the issue and adds a way to specify options, such as samples, to PassNode.

This contribution is funded by Utsubo

[github-actions]

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev	Filesize PR	Diff
682.2 kB (169 kB)	682.2 kB (169 kB)	+0 B

🌳 Bundle size after tree-shaking

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

Filesize dev	Filesize PR	Diff
459.4 kB (110.9 kB)	459.4 kB (110.9 kB)	+0 B

[Mugen87]

What is the purpose of type !== HalfFloatType && type !== FloatType?

Does that mean multisampled (half) float textures are not allowed?

[RenaudRohlinger]

I cleaned up and refactored the samples and antialiasing logic. Previously, it was under backend.parameters.antialias and was only handled by the WebGPUBackend.
I moved the antialiasing settings to the Renderer and introduced a renderer.samples property. If this new property is set to a value greater than 0, it will override the antialias logic. The antialias property now simply acts as a shortcut for setting renderer.samples to 4, allowing developers to initialize the sample count directly from the Renderer, for example, by using new WebGPURenderer({ samples: 2 }).

Since WebGPU only supports sample counts of 1 and 4, I refactored the WebGPUUtils.getSampleCount method and used it everywhere it's relevant to ensure the sample count is always translated appropriately in that backend. For the WebGLBackend, it will use the sample count defined in the Renderer, which supports any sample amount, usually with a maximum of 8.

Here is most of the refactor:
811fd9a

Following this refactor, I discovered that in the case of multisampled textures in WebGPU, we were always actually using two textures: one extra that resolves the multisampled one. Based on the specs, it seems that WebGPU supports direct rendering of multisampled 2D and depth 2D textures, as it seems that the GPURenderPassDepthStencilAttachment interface doesn't provide a resolveTarget view and so cannot work. ( 👉 https://www.w3.org/TR/webgpu/#dom-gputexturebindinglayout-multisampled).

Therefore, I added multisample texture support to the WebGPUBackend and updated the WGSLNodeBuilder to support both types: texture_multisampled_2d and texture_depth_multisampled_2d.

Small notes:

• The multisampling process for textures will continue to work as before if the type is Float or HalfFloat. This is because WebGPU does not support directly rendering to multisampled textures with these types. "unfilterable-float" seems to silent the issue but the antialiasing doesn't seems to get performed in that case. (To answer your comment, also I removed that block /cc @Mugen87)
• I have not implemented this feature in the WebGLBackend. Given that this is already a substantial PR, I prefer to address this support in a separate, future PR.

Aside from this, while testing most of the examples, I noticed that webgpu_postprocessing_anamorphic.html, webgpu_compute_particles_snow.html all look different from the examples in production of r166, and this issue is also present in dev.

/cc @sunag @mrdoob @Mugen87

New review required.

[Mugen87]

(To answer your comment, also I removed that block

It seems the check is still present though.

The logic that configures isMultisampleRenderTargetTexture is something that should not belong to PassNode, imo. How about moving this into the renderer?

isMultisampleRenderTargetTexture is currently only configured by PassNode but it seems that should be done no matter of how a render target was configured.

[Mugen87]

I have not implemented this feature in the WebGLBackend. Given that this is already a substantial PR, I prefer to address this support in a separate, future PR.

I don't think it makes sense to do that in the near future since you need the WEBGL_multisampled_render_to_texture extension which is only supported by the Oculus Browser so far. And since we can't use XR with WebGPURenderer right now there is no possibility to test this.

[Mugen87]

Sidenote: Post processing in HDR requires half float so THREE.HalfFloatType is the default right now. Rendering multisampled to a color renderable texture is only relevant when the dev configures PassNode as RGBAFormat+ UnsignedByteType + SRGBColorSpace (bgra8unorm-srgb in WebGPU or SRGB8_ALPHA8 in WebGL). And then not all available effects will be compatible with this setup.

I recommend to split the change and add support for texture_multisampled_2d and texture_depth_multisampled_2d with a different PR (independently of PassNode).

[RenaudRohlinger]

The texture_depth_multisampled_2d is necessary to support MSAA with PassNode because GPURenderPassDepthStencilAttachment doesn't support using a resolveTarget:

Which means that the depth texture associated with that RenderPass will be multisampled if the ColorBuffer is multisampled.
Unlike the color that is resolved to a normal texture target, the depth will be sent to the GPU as a multisampled texture, which means WGSL should read it as texture_depth_multisampled_2d in order to work and render something. That's why I had to implement this support in WGSL.

Also, I cleaned up PassNode and removed the multisampling for the color passes, which is now reduced to a single line for the isMultisampleRenderTargetTexture flag. Unfortunately, I have to set the depthTexture.isMultisampleRenderTargetTexture flag in the PassNode.setup function if we want to fallback to the renderer.samples, as the texture creation seems to occur after the WGSLNodeBuilder code runs. This would otherwise generate incorrect WGSL for the not-yet-updated texture.

[Mugen87]

Thanks for the additional information!

Unfortunately, I have to set the depthTexture.isMultisampleRenderTargetTexture flag in the PassNode.setup function if we want to fallback to the renderer.samples, as the texture creation seems to occur after the WGSLNodeBuilder code runs. This would otherwise generate incorrect WGSL for the not-yet-updated texture.

Maybe @sunag has an idea how to hide this bit. Ideally, we evaluate whether a depth texture is multisampled or not inside the renderer and not in components using the renderer.

Apart from that, the PR looks already good!

[Mugen87]

Is this exception still required? My understand is you have added this bit since rendering multisampled to a color renderable texture does not yet work in the WebGL backend. But can at least the "normal" MSAA be used?

[RenaudRohlinger]

Unfortunately yes it's still needed. I noticed that using PassNode with samples > 0 doesn't seem to render anything in WebGL. I believe this might be due to the need for an additional frameBuffer somewhere in the render pipeline, which I couldn't easily resolve. That's why I added this comment.

[sunag]

Could we add this path in WebGLBackend.beginRender() for now?

[RenaudRohlinger]

I wouldn't recommend so because basic THREE.RenderTarget setups works just fine with samples > 0. For example webgpu_multisampled_renderbuffers.html.

[sunag]

Let's merge this PR then! It's possible do it in another PR, currently already a step forward in that sense. So the future goal is for us to move this and isMultisampleRenderTargetTexture into the renderer as @Mugen87 said, when this is ready examples like webgpu_backdrop_water should work too.