WebGLMultisampleRenderTarget: Enable toScreen rendering.

[Mugen87]

Related issue: see #16895

Description

With this PR, it is possible that WebGLMultisampleRenderTarget resolves the multisampling to the default framebuffer (screen) instead of a custom framebuffer. It's just required to set the new toScreen flag to true.

This makes the usage of WebGLMultisampleRenderTarget more flexibel since you safe an additional render pass if you want to output the result on screen. I've created a new example webgl2_msaa that demonstrates this approach. webgl2_multisampled_renderbuffers has been renamed to webgl2_postprocessing_msaa and a simple sepia effect was added.

[Mugen87]

@arpu @aardgoose @vanruesc Would be great if you have a look at this PR, too. 😇

[Mugen87]

This API usage is actually a bit unusual since applying a render target via setRenderTarget() will still render to screen (and not into the render target).

I though about applying the render target as new a context parameter when creating the renderer. However, this means an enhancement of WebGLRenderer will be required since it has to manage an additional render target.

[vanruesc]

That's a cool feature! The implementation looks solid; I've poked at it here https://codesandbox.io/s/competent-poitras-782vg?runonclick=1&file=/src/App.js

This might seem obvious, but I think it's worth mentioning that the format and type of the multisampled render target must correspond to the screen/default framebuffer:

• type must be UnsignedByteType (for most screens/contexts)
• format must be RGBFormat or RGBAFormat, depending on whether or not alpha was set to true on the context
• minFilter, magFilter, stencilBuffer and depthBuffer settings can be chosen freely

If the settings or dimensions don't match, or if antialias is set to true on the context, the scene won't render:

Firefox: blitFramebuffer: DRAW_FRAMEBUFFER may not have multiple samples.
Chrome: [.WebGL-000007340912CF00] GL_INVALID_OPERATION: Attempt to blit from a multisampled framebuffer and the bounds or format of the color buffer don't match with the draw framebuffer.
Chrome: [.WebGL-0000073400162F80] GL_INVALID_OPERATION: Invalid operation on multisampled framebuffer

As for the API, I think toScreen is fine.

[arpu]

thx @Mugen87 @vanruesc to look at this, this works as Perfect in my Environment.
the only small problem was to find stencilBuffer: true for the WebGLMultisampleRenderTarget params

@cabanier would be nice if we could test MSAA 8x on the Quest 2 (chrome limit it to 4x on all Android devices)

[cabanier]

@cabanier would be nice if we could test MSAA 8x on the Quest 2 (chrome limit it to 4x on all Android devices)

We are aware that people want to have multisample but it requires many changes in the graphics stack to be reliable.
We're planning on getting this fixed in the future.

[arpu]

anything more needed to get out of the Draft state?

[cabanier]

We know what needs to be done. I just need to find the time to get it implemented.

[Mugen87]

@cabanier I believe the comment by @arpu was related on this PR. Meaning to transform the "Draft PR" to a PR ready to for review. 👍

[arpu]

tested this with threejs r128 and works just fine

[arpu]

some problems on Oculus Browser
the right and left Eye is not in sync and the quality looks like Msaa is not used

@cabanier any known Problem for this? ( i use this.renderTarget.samples = Math.min(8, context.getParameter(context.MAX_SAMPLES));, on Android Oculus Browser -> this.renderTarget.samples is 4)

[arpu]

@mrdoob realistic to get this in this release cycle?

[mrdoob]

@Mugen87 Is there any way this logic could sit in the post-processing code instead?

[cabanier]

some problems on Oculus Browser
the right and left Eye is not in sync and the quality looks like Msaa is not used

@cabanier any known Problem for this? ( i use this.renderTarget.samples = Math.min(8, context.getParameter(context.MAX_SAMPLES));, on Android Oculus Browser -> this.renderTarget.samples is 4)

If the eyes are not in sync, something else must be going on. Do you have an example?

[arpu]

@mrdoob my understanding is this is the only way to allow Hardware MSAA > 4 without post-processing using context.MAX_SAMPLES

@cabanier would be good to have a uptodate example, last working example is https://codesandbox.io/s/competent-poitras-782vg?runonclick=1&file=/src/App.js

i hope @Mugen87 can solve the merge conflicts

[Mugen87]

i hope @Mugen87 can solve the merge conflicts

I'll file a new PR based on latest dev.