WebGPURenderer: MSAA, Postprocessing and Wireframe support in the WebGL Backend

[RenaudRohlinger]

Happy New Year!!

Multiple points are addressed in this PR:

• MSAA Support
• Wireframe Support
• Postprocessing Support in the WebGLBackend
• Removed WebGPU condition on webgpu_postprocessing_afterimage, webgpu_skinning_instancing, webgpu_portal.
• Fix RenderTarget broken after resize in WebGLBackend WebGPURenderer: Resize breaks post FX setup in webgpu_rtt example #27466

Live example MSAA:
webgpu_multisampled_renderbuffers

Live example Postprocessing:

• webgpu_postprocessing_afterimage
• webgpu_skinning_instancing
• webgpu_portal

This contribution is funded by Utsubo

[RenaudRohlinger]

Added to this PR some fixes notably #27466, and MSAA support and a new webgpu example that combine all this (webgpu_multisampled_renderbuffers).

I have other points I would like to improve but I will wait on #27463 to be merged to cleanup and move textures related methods to WebGLTextureUtils.

[RenaudRohlinger]

Cleaned up a bit more the code and made some space and improvement for another issue I wanted to fix (postprocessing support in the WebGL backend).

I'm still struggling with a feedback loop issue from the WebGL Backend when multiple framebuffers are involved (which is currently an issue in the dev branch):
WebGL warning: drawArraysInstanced: Texture level 0 would be read by TEXTURE_2D unit 0, but written by framebuffer attachment COLOR_ATTACHMENT0, which would be illegal feedback.

Not sure how I should update the pipeline there and where to unbind the previous RTT which is then attached as a texture to next one. But maybe we could merge this PR before it grows even larger.

/cc @sunag

[RenaudRohlinger]

Nevermind, I just found how to support for postprocessing. I will re-request review when it's ready I need to test all the examples. /cc @sunag 😄

[RenaudRohlinger]

Added support for multipass in the postprocessing pipeline and removed the WebGPU condition in 2 new demos:

Live example here:

• webgpu_skinning_instancing
• webgpu_portal

I'm currently re-binding the framebuffer per render object in the draw method of the WebGLBackend.
This solution is not final as it requires each quad in the RTT pipeline to be in the same configuration (size and so on), the issue is that currently all the renderTarget setup is configured at the very beginning of Renderer.render(), but then if there is multiple pass in the pipeline each FBO will have its own renderContext. Without re-binding the framebuffer they will all inherit only of the configuration of the first renderContext called at the very beginning of render() which is not good. /cc @sunag

I think there could be a better solution which might require a refactor in the Renderer class which will impact the WebGPU side so I'd rather not touch it in this PR.

I'm satisfied of the current state of this. I will stop there and create new PRs once this one is merged.

[sunag]

I think beginRender() and finishRender could dealing with the re-binding of framebuffer, perhaps related to renderContextData.previousContext, the previous context information may be lost if it is called in a more than once in the same flow of Node.updateBefore maybe it can be related with re-bind in the draw. But I'm also in favor of checking this more calmly in other PR. Amazing progress you did these days!