Deferred Renderer

[DGriffin91]

Objective

• Add a Deferred Renderer to Bevy.
• This allows subsequent passes to access per pixel material information before/during shading.
• Accessing this per pixel material information is needed for some features, like GI. It also makes other features (ex. Decals) simpler to implement and/or improves their capability. There are multiple approaches to accomplishing this. The deferred shading approach works well given the limitations of WebGPU and WebGL2.

Motivation: I'm working on a GI solution for Bevy

Solution

• The deferred renderer is implemented with a prepass and a deferred lighting pass.

  • The prepass renders opaque objects into the Gbuffer attachment (Rgba32Uint). The PBR shader generates a PbrInput in mostly the same way as the forward implementation and then packs it into the Gbuffer.
  • The deferred lighting pass unpacks the PbrInput and feeds it into the apply_pbr_lighting() function, then outputs the shaded color data.

• There is now a resource DefaultOpaqueRendererMethod that can be used to set the default render method for opaque materials. If materials return OpaqueRendererMethod::Auto from opaque_render_method() the DefaultOpaqueRendererMethod will be used. Otherwise, custom materials can also explicitly choose to only support Deferred or Forward by returning the respective OpaqueRendererMethod

• Deferred materials can be used seamlessly along with both opaque and transparent forward rendered materials in the same scene. The deferred rendering example does this.

• The deferred renderer does not support MSAA. If any deferred materials are used, MSAA must be disabled. Both TAA and FXAA are supported.

• Deferred rendering supports WebGL2/WebGPU.

Custom deferred materials

• Custom materials can support both deferred and forward at the same time. The StandardMaterial does this. So does this example.
• Custom deferred materials that require PBR lighting can create a PbrInput, write it to the deferred GBuffer and let it be rendered by the DeferredPbrLightingPlugin.
• Custom deferred materials that require custom lighting have two options:
  1. Use the base_color channel of the PbrInput combined with the STANDARD_MATERIAL_FLAGS_UNLIT_BIT flag. Example. (If the unlit bit is set, the base_color is stored as RGB9E5 for extra precision)
  2. A Custom Deferred Lighting pass can be created, either overriding the default, or running in addition. The a depth buffer is used to limit rendering to only the required fragments for each deferred lighting pass. Materials can set their respective pass id via the deferred_lighting_pass_id attachment. The custom deferred lighting pass plugin can then set its corresponding depth. Then with the lighting pass using CompareFunction::Equal, only the fragments with a depth that equal the corresponding depth written in the material will be rendered.

Custom deferred lighting plugins can also be created to render the StandardMaterial. The default deferred lighting plugin can be bypassed with DefaultPlugins.set(PBRDeferredLightingPlugin { bypass: true })

[superdump]

Approving with the assumption that comments where we decided something should be done in a separate PR will be done in time. I'll wait for @robtfm's final verdict before merging.

[DGriffin91]

In order to minimize the size of the deferred attachment it would be better to not redundantly write the normals to the prepass normals attachment. Instead, we should have a pass after deferred that copies the normals from the gbuffer (using depth >= 1 with the deferred lighting pass id) as that should be a lot more efficient.

It's important that we don't read from the whole deferred gbuffer for things like SSAO where there's lots of samples because GPU memory is slow.