ReSTIR DI occlusion cull: object-space blocky dark patches (stochastic light shadows)

sky_line commented

2026-10-25 05:20:45 +00:00

Owner

Dark patches with straight, angular (polygon / triangle-shaped) edges appear in shadowed areas: on snow, and on an avatar's face (a triangle-shaped darker region). They look related to shadows. Small coloured square specks (teal / yellow) are also visible on the snow in the same view; that may be a separate issue.

Seen on dev 1.5 (b2761279e3), RTX 5090, RT shadows, after several settings changes in the session (reflection probes and upscaler toggled). The patches went away on their own after a while.

Ruled out: the split shadow kernels. The owner A/B'd RenderVKShadowSplitKernels 0/1.

Suspects:

The shadow-terminator / receiver-facet logic (choosing the shadow ray origin from the receiver's triangle), which would explain the facet-shaped regions.
Shadow denoiser history that is stale after settings changes, which would explain why it is transient.
Shadow-map cascade bias on snow.

Needs a repro: which settings were changed just before, and whether it shows on 1.4.

Dark patches with straight, angular (polygon / triangle-shaped) edges appear in shadowed areas: on snow, and on an avatar's face (a triangle-shaped darker region). They look related to shadows. Small coloured square specks (teal / yellow) are also visible on the snow in the same view; that may be a separate issue. Seen on dev 1.5 (b2761279e3), RTX 5090, RT shadows, after several settings changes in the session (reflection probes and upscaler toggled). **The patches went away on their own after a while.** **Ruled out:** the split shadow kernels. The owner A/B'd RenderVKShadowSplitKernels 0/1. **Suspects:** - The shadow-terminator / receiver-facet logic (choosing the shadow ray origin from the receiver's triangle), which would explain the facet-shaped regions. - Shadow denoiser history that is stale after settings changes, which would explain why it is transient. - Shadow-map cascade bias on snow. Needs a repro: which settings were changed just before, and whether it shows on 1.4.

sky_line added the

rendering

bug

labels

2026-10-25 05:20:45 +00:00

sky_line added this to the Slipstream project

2026-10-25 05:20:45 +00:00

sky_line commented

2026-10-25 05:29:29 +00:00

Author

Owner

Owner's follow-up: the patches on the snow may be a separate issue from the ones on the avatar. They look like they could be per snow cell: blocks that line up with the snow height-field / accumulation grid or the snow mesh tiles, rather than with shadow casters.

For the snow half, check per-cell / per-tile values that differ between neighbouring cells: snow depth or coverage, the normal or relief, the shelter / cover map, and the per-tile mesh rebuilds (RenderVKWeatherSnowMeshInterval and local tile patches). The shadow half (the facet-shaped patch on the face) keeps the terminator / denoiser suspects. Split into two tickets if they turn out to be separate.

Owner's follow-up: the patches on the snow may be a separate issue from the ones on the avatar. They look like they could be **per snow cell**: blocks that line up with the snow height-field / accumulation grid or the snow mesh tiles, rather than with shadow casters. For the snow half, check per-cell / per-tile values that differ between neighbouring cells: snow depth or coverage, the normal or relief, the shelter / cover map, and the per-tile mesh rebuilds (RenderVKWeatherSnowMeshInterval and local tile patches). The shadow half (the facet-shaped patch on the face) keeps the terminator / denoiser suspects. Split into two tickets if they turn out to be separate.

sky_line commented

2026-10-25 06:33:30 +00:00

Author

Owner

New evidence (owner, 1.5 candidate 724175e6e4 under validation layers): the same blockiness on an ordinary object (a red cylinder, 'Paper roll'). The patches are axis-aligned rectangles in screen space, of different sizes, each with a thin outline. Their edges stay horizontal / vertical across the curved surface. So it is probably not snow cells or shadow casters, but a tiled screen-space pass where neighbouring tiles took different shading paths.

Suspects, in order:

Deferred-lighting tile classification (#831): a tile on the cheap vs full path, e.g. with / without shadows or local lights.
Variable-rate shading tiles.
Reduced-resolution / denoiser tiles (RT shadow mask, GI, projector-shadow atlas).

A/B to run:

RenderVKDeferredSplit 0 (no tile classification);
full-rate shading (RenderVKShadingRate / RenderVKAlphaShadingRate 1);
GI on / off.

Also check whether the pattern is fixed to the screen when the camera moves. The face patch from the first report may be the same thing.

New evidence (owner, 1.5 candidate 724175e6e4 under validation layers): the same blockiness on an ordinary object (a red cylinder, 'Paper roll'). The patches are **axis-aligned rectangles in screen space, of different sizes, each with a thin outline**. Their edges stay horizontal / vertical across the curved surface. So it is probably **not** snow cells or shadow casters, but **a tiled screen-space pass where neighbouring tiles took different shading paths**. **Suspects, in order:** 1. Deferred-lighting tile classification (#831): a tile on the cheap vs full path, e.g. with / without shadows or local lights. 2. Variable-rate shading tiles. 3. Reduced-resolution / denoiser tiles (RT shadow mask, GI, projector-shadow atlas). **A/B to run:** - RenderVKDeferredSplit 0 (no tile classification); - full-rate shading (RenderVKShadingRate / RenderVKAlphaShadingRate 1); - GI on / off. Also check whether the pattern is fixed to the screen when the camera moves. The face patch from the first report may be the same thing.

sky_line commented

2026-10-25 06:34:18 +00:00

Author

Owner

Correction: the pattern is in object space. It stays on the object when the camera moves, so it is not a screen-space tile pass.

Rectangular patches of varying size with thin outlines, fixed to the surface, on unrelated objects (snow, an avatar face, a plain prim cylinder) point at textures rather than lighting. If the normal map is affected, it reads as shading / shadows.

Suspects:

GPU texture compression (RenderVKTextureCompression, adaptive by default since 1.4 Beta 5): neighbouring regions encoded with different formats / quality, or a bad BC5 normal-map region, leave visible seams.
#991 partial mip-chain upgrade in place (new in 1.4.1 and dev): regions of a texture on different mip levels or encodings after an upgrade.

Decisive test: RenderVKTextureCompression 0, then reload textures (teleport away and back, or restart). Both suspects are in 1.4.1 as well, so check there too.

Correction: the pattern is in **object space**. It stays on the object when the camera moves, so it is not a screen-space tile pass. Rectangular patches of varying size with thin outlines, fixed to the surface, on unrelated objects (snow, an avatar face, a plain prim cylinder) point at **textures** rather than lighting. If the normal map is affected, it reads as shading / shadows. **Suspects:** 1. GPU texture compression (RenderVKTextureCompression, adaptive by default since 1.4 Beta 5): neighbouring regions encoded with different formats / quality, or a bad BC5 normal-map region, leave visible seams. 2. #991 partial mip-chain upgrade in place (new in 1.4.1 and dev): regions of a texture on different mip levels or encodings after an upgrade. **Decisive test:** RenderVKTextureCompression 0, then reload textures (teleport away and back, or restart). Both suspects are in 1.4.1 as well, so check there too.

sky_line commented

2026-10-25 06:37:58 +00:00

Author

Owner

Root cause confirmed (owner A/B): the blocks come from the ReSTIR DI occlusion cull (RenderVKReSTIROcclusionCull, #869, default 1).

With stochastic shadows off, there are no blocks.
With stochastic shadows on and RenderVKReSTIROcclusionCull 0, the blocks are gone.

Mechanism: the cull's world-space surface-patch cache (0.25 m near the camera, coarser with distance) drops a light from a patch's light list once the patch's rays to it all come back blocked. A wrong or stale verdict darkens the whole patch, which shows as object-space rectangles with hard edges at patch borders, of varying size by distance.

With the cull off there are other shadow issues (details from the owner pending); likely what the cull was added to prevent (sweeping shadows / noise next to blocked lights).

Dev only (not in 1.4); stochastic shadows are off by default.

**Root cause confirmed (owner A/B):** the blocks come from the ReSTIR DI **occlusion cull** (RenderVKReSTIROcclusionCull, #869, default 1). - With stochastic shadows off, there are no blocks. - With stochastic shadows on and RenderVKReSTIROcclusionCull 0, the blocks are gone. Mechanism: the cull's world-space surface-patch cache (0.25 m near the camera, coarser with distance) drops a light from a patch's light list once the patch's rays to it all come back blocked. A wrong or stale verdict darkens the whole patch, which shows as object-space rectangles with hard edges at patch borders, of varying size by distance. With the cull off there are other shadow issues (details from the owner pending); likely what the cull was added to prevent (sweeping shadows / noise next to blocked lights). Dev only (not in 1.4); stochastic shadows are off by default.

sky_line changed title from ~~Blocky, polygon-edged dark patches in shadows (snow, avatar face); transient~~ to ReSTIR DI occlusion cull: object-space blocky dark patches (stochastic light shadows)

2026-10-25 06:37:58 +00:00

sky_line referenced this issue from a commit

2026-10-25 09:08:08 +00:00

#1052: ReSTIR DI stochastic light shadows -- soft occlusion cull (no hard-edged patches) + converged shortcut only where one light dominates (no rimmed blotches)

sky_line added the

status

testing

label

2026-10-25 09:08:12 +00:00

sky_line commented

2026-10-25 09:54:49 +00:00

Author