EEVEE currently has render passes (Combined, Z, Mist, Depth, Normal, Subsurface Light, Subsurface Color, Ambient Occlusion). These render passes were added as they could be extracted easily from the buffers and shaders EEVEE already used.
The current set of passes makes it very hard to do proper compositing as they're not a complete set. You're not able to construct the Combined render pass by mixing the other passes. The goal of this project is to create a good foundation for supporting render passes in EEVEE and have a useful set to do common compositing operations.
In the target situation we must at least support Diffuse Color, Diffuse Light, Glossy Color, Glossy Light, Emission, World Environment, Volume and Bloom.
AOVs, Denoising Data and Cryptomatte passes have specific implementation and workflow needs and therefore will need a specific design. In the future we will add other render passes based on needs and technical consequences/feasibility.
D6331: EEVEE: Render Passes demonstrates a proof of concept where we were able to extract useful data during rendering and construct a similar image in the compositor. It is a proof of concept to test the basic implementation and find the limitations and difficulties when using EEVEE inside the compositor. The proof of concept has some flaws and is limited.
- The solution adds booleans to the material fragment shader that tells the shader what part of the data needs to be extracted.
- Per render pass a texture is created. This texture will store the accumulated result of all samples for a specific render pass.
- When the material shader is created. For all the selected render passes a shading group is created. When an object is added to the normal material shader it is also added to the shading groups for the passes.
- Bloom is an additive effect. This patch stores the addition to a accumulate texture.
This section will explain the alternative options for implementation.
Multi target rendering
This option would have added multi target rendering to the GPU material by in stead of the current energy and transmittance we would have stored all the different material passes. and at the end of the shader we would store the data into the different passes.
- PRO: single draw call could fill several buffers.
- CON: compilation time increases a lot due to higher registry/local data requirements and unrolling.
- CON: viewport rendering will slow down.
Multi pass rendering
This option (current PoC implementation) will create a DRWPass per render pass and have a generic GPU material that can render any pass.
- PRO: No noticeable performance impact when rendering viewport.
- CON: per renderpass a draw call is needed. Performance noticable during image rendering
Decisions, Consequences and Limitations
- To construct these render passes we need to allocate memory on the GPU during the whole render time. This is a float RGB texture when rendering with many samples or a half RGB texture when rendering with fewer samples. The exact needed resources depends on the the implementation of the OpenGL Driver. It could be that scenes would not be able to render on low-end cards due to memory limitations and how advanced the resource management inside the driver is. When enabling 20 passes for a HD render with many samples 500MB additional GPU Memory is allocated to store the results. In the future we could optimize this by re-rendering the full frame with different passes enabled.
- Ambient Occlusion is mixed in the light passes. Inside these passes different and not constant mix factors are used. It will not be possible to composite the final result from the individual passes when we only have a separate AO pass.
- Screen space Depth of Field will not be available as a pass. The concern is that the pass isn't useful. At this time you could use the defocus node in the compositor.
- The accumulate buffers have more precision and extract the data in the right moment. This can lead to small (but visible) differences between the Combined pass and the composited individual passes.
Note that during implementation our ideas have shifted a bit. The first implementation will use multi pass rendering. But eventually we will move to multi target rendering. The reason is that extracting the glossy/diffuse light passes needs upto 3 different passes. During the actual implementation we found a way how to overcome the complexity that we expected for the multi target rendering. The implementation of the multi target rendering will be done in a separate ticket, as it isn't clear when we will realizing that project.
- Get feedback on this design from users and developers.
- Get approval of this design from at least GPU, Compositor and Rendering module.
- Plan when we want start implementing.
- Finalize multi pass implementation D6331: EEVEE: Render Passes