ForwardRenderer ignores Clear.Depth when light probes are enabled (Z-prepass hardcodes a 1.0 depth clear)

Release Type: Official Release (NuGet) — reproduced against Stride 4.4.0-beta1. Code references are to current master (dc763f93), where the relevant lines are identical.

Version: 4.4.0-beta1 / master (dc763f93)

Platform(s): Reproduced on Windows (Direct3D 11). The defect is backend-independent — the CommandList.Clear(Texture, DepthStencilClearOptions, float depth = 1, byte stencil = 0) overload defaults depth = 1 on every backend (Direct3D11, Direct3D12, Vulkan, Null).

Describe the bug

ForwardRenderer.Clear.Depth is a public, serialized, Game Studio–editable property, but its configured value is silently discarded whenever light probes are enabled. It is honored with light probes off and overwritten to 1.0 with them on.

ForwardRenderer.DrawCore clears depth to the configured Clear.Depth via Clear?.Draw(drawContext) (ForwardRenderer.cs:748), then immediately calls DrawView(...), whose light-probe Z-prepass does a raw depth clear (ForwardRenderer.cs:504):

drawContext.CommandList.Clear(drawContext.CommandList.DepthStencilBuffer, DepthStencilClearOptions.DepthBuffer);

That CommandList.Clear overload defaults float depth = 1 (CommandList.Direct3D11.cs:905), so the depth buffer is re-cleared to 1.0, discarding the configured value. The prepass runs only when LightProbes && GBufferRenderStage != null (ForwardRenderer.cs:495) — the configuration the default stride new compositor (GraphicsCompositor.sdgfxcomp) ships with — so on a stock project Clear.Depth never takes effect.

To Reproduce

Minimal, self-checking repro (pure code, no Game Studio assets): https://gitlab.com/lazy-works/stride-forwardrenderer-cleardepth-bug

1. Default forward compositor (LightProbes = true + a GBufferRenderStage).
2. forwardRenderer.Clear.Depth = 0.5f;
3. Empty scene (no meshes) so the whole depth buffer equals the clear.
4. Render a frame and read back a center depth texel.
5. Expected 0.5; actual 1.0.
6. Control: set LightProbes = false, re-render → now it's 0.5. This isolates the light-probe Z-prepass as the cause.

The repro prints and sets its exit code accordingly:

LightProbes: ENABLED (default template)
Configured ForwardRenderer.Clear.Depth: 0.5
Observed center depth: 1
BUG REPRODUCED: Clear.Depth (0.5) was IGNORED; depth is 1 (the light-probe Z-prepass re-cleared it to a hardcoded 1.0).

Expected behavior

The depth buffer should be cleared to the configured Clear.Depth. It is, with light probes off; with them on it ends up at 1.0 regardless of Clear.Depth.

Screenshots

N/A — headless depth read-back; see the repro output above.

Log and callstacks

N/A — no crash; the symptom is a silently wrong depth value.

Additional context

• Secondary observation: with light probes on, depth is cleared twice per frame (ClearRenderer + Z-prepass) — redundant regardless of the value bug.
• Why it matters: Clear.Depth exists to be set; any depth-based downstream effect that wants a specific background/sentinel depth relies on it. The engine silently overriding it is the defect.
• Possible fix: have the Z-prepass clear to the configured Clear.Depth (e.g. Clear?.Depth ?? 1.0f) instead of the overload default, or skip the redundant depth clear when the ClearRenderer already cleared depth this frame.

Permalinks (pinned to master dc763f93):

• ForwardRenderer.cs:748 — clears depth to the configured Clear.Depth
• ForwardRenderer.cs:504 — Z-prepass re-clears depth (hardcoded 1.0)
• ForwardRenderer.cs:495 — the LightProbes && GBufferRenderStage != null precondition
• CommandList.Direct3D11.cs:905 — the float depth = 1 overload default

Start in sources/engine/Stride.Engine/Rendering/Compositing/ForwardRenderer.cs around lines 495, 504, and 748, then inspect the depth-clear overload at sources/engine/Stride.Graphics/Direct3D11/CommandList.Direct3D11.cs:905. Run the linked repro with light probes enabled and verify that the observed depth matches ForwardRenderer.Clear.Depth instead of being reset to 1.0.