EEVEE-Next Planar Capture #112966

New Issue

Clément Foucault · 2023-09-27T18:43:55+02:00

Clément Foucault commented

2023-09-27 18:43:55 +02:00

Motivations

For feature parity reason, we need to implement back support for planar capture objects.
The main use of them is to fix screen space tracing artifacts on highly reflective planar surfaces.

Clipping plane

In order to not reflect object above the planar lightprobe, surfaces above the capture plane need to be clipped.

The previous implementation created a non-negligeable overhead for the vertex shader and was slowing down the whole scene rendering even when planar capture lightprobes are not used.

Creating a new shader variation will considerably increase the shader compilation time of materials.
A better solution would be to use an oblique projection matrix that clip the geometry using the near plane.

References for constructing the oblique projection:

While this construction looks good, we do need assess if the depth distribution is still good for screen tracing. Otherwise, we should revert to construct the matrix from scratch.

EDIT: Experiment showed that the resulting frustum is really not ideal. Maybe I did it wrong, but this is the result I got.

Instead of using oblique frustum, we can use software clip-plane using discard in the prepass fragment shader. Contrary to the hardware clip distance, this won't have any discrepancy with the shading pass which can stay untouched. Also, since most materials have the same opaque prepass shader, so the compilation time for another prepass variation is not that much.

Capture Pipeline

We want to have different visibility pool for cubemap lightprobes and planar lightprobes. So there need to be another DeferredProbePipeline inside PipelineModule which is dedicated to this type of capture. To avoid the CPU overhead of having to always populate it, it should only be populated when there is a visible planar capture. This can only be done with a one frame delay in the viewport like for the cubemap lightprobes. Render mode might want to always populate it for now.

Note that for now, we should only capture opaque deferred with diffuse lighting only. This is to limit the complexity of this feature and the performance impact. This can be revisited later.

Integration with tracing pipeline

The tracing shader need to be specialized to trace these. We actually do not want to recreate a HiZ for each of these so we have to trace the depth buffers directly. We can leverage the tiled tracing to have an indirect dispatch to trace only where there is pixels that use the planar lightprobe. One indirect dispatch per lightprobe should allow for spliting resources access between dispatches. This will make different resolution per planar capture possible.

Tasks

1b1b1a19bf Add support for software clip plane.
#113203 Create draw::View from planar lightprobe and render draw::View.
#113203 Add a dedicated pipeline and add drawcalls to it.
#113203 Add a PlanarProbeView
#113203 Add an object visibility option.
#113453 Integration to tracing pipeline
Port viewport display

Extended targets

Capture resolution scaling

## Motivations For feature parity reason, we need to implement back support for planar capture objects. The main use of them is to fix screen space tracing artifacts on highly reflective planar surfaces. ## Clipping plane In order to not reflect object above the planar lightprobe, surfaces above the capture plane need to be clipped. The previous implementation created a non-negligeable overhead for the vertex shader and was slowing down the whole scene rendering even when planar capture lightprobes are not used. Creating a new shader variation will considerably increase the shader compilation time of materials. A better solution would be to use an oblique projection matrix that clip the geometry using the near plane. References for constructing the oblique projection: - https://forum.gamemaker.io/index.php?threads/projection-matrix-with-oblique-near-clip-plane.60537/ - http://www.terathon.com/code/oblique.html - https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=255FB6BD9252A50A1A7166319C8A5CE0?doi=10.1.1.367.1894&rep=rep1&type=pdf While this construction looks good, we do need assess if the depth distribution is still good for screen tracing. Otherwise, we should revert to construct the matrix from scratch. EDIT: Experiment showed that the resulting frustum is really not ideal. Maybe I did it wrong, but this is the result I got. ![image](/attachments/83626567-0716-4220-a744-c3faeb74ed51) Instead of using oblique frustum, we can use software clip-plane using discard in the prepass fragment shader. Contrary to the hardware clip distance, this won't have any discrepancy with the shading pass which can stay untouched. Also, since most materials have the same opaque prepass shader, so the compilation time for another prepass variation is not that much. ## Capture Pipeline We want to have different visibility pool for cubemap lightprobes and planar lightprobes. So there need to be another `DeferredProbePipeline` inside `PipelineModule` which is dedicated to this type of capture. To avoid the CPU overhead of having to always populate it, it should only be populated when there is a visible planar capture. This can only be done with a one frame delay in the viewport like for the cubemap lightprobes. Render mode might want to always populate it for now. Note that for now, we should only capture opaque deferred with diffuse lighting only. This is to limit the complexity of this feature and the performance impact. This can be revisited later. ## Integration with tracing pipeline The tracing shader need to be specialized to trace these. We actually do not want to recreate a HiZ for each of these so we have to trace the depth buffers directly. We can leverage the tiled tracing to have an indirect dispatch to trace only where there is pixels that use the planar lightprobe. One indirect dispatch per lightprobe should allow for spliting resources access between dispatches. This will make different resolution per planar capture possible. ## Tasks - [x] 1b1b1a19bffcade8cd367bac8a3b242dee2bc3d6 Add support for software clip plane. - [x] #113203 Create `draw::View` from planar lightprobe and render `draw::View`. - [x] #113203 Add a dedicated pipeline and add drawcalls to it. - [x] #113203 Add a `PlanarProbeView` - [x] #113203 Add an object visibility option. - [x] #113453 Integration to tracing pipeline - [x] Port viewport display # Extended targets - Capture resolution scaling

image.png

396 KiB

Clément Foucault added the

Type

To Do

label 2023-09-27 18:43:55 +02:00

Clément Foucault added this to the EEVEE & Viewport project 2023-09-27 18:43:57 +02:00

Clément Foucault referenced this issue

2023-09-27 19:10:34 +02:00

EEVEE-Next #93220

Clément Foucault added the