Background
Dual-paraboloid shadow mapping (DPSM), used by the vanilla engine for
omnidirectional point-light shadows (which SCM's atlas repackages, not
replaces), has an inherent seam at the equator between its two paraboloid
halves. Confirmed via RenderDoc on this branch: the depth atlas band
straddling that seam is ~83% cleared/empty for a representative omni light
tile, causing receiver pixels near the light's local equatorial plane to
read back "no occluder" (unshadowed) even when a real caster blocks the
light. Most visible on player-held torches, since their orientation swings
constantly relative to any nearby receiving geometry.
Why this issue, separate from the seam mitigation PR
A same-architecture mitigation (rejecting/discounting shadow taps that land
on cleared depth near the seam, since the render-side paraboloid FOV is the
vanilla engine's own vertex shader and not something SCM controls or can
widen) is being tested separately. That reduces the visual defect but can't
add shadow data that was never rendered.
What to investigate
Cube shadow maps are the standard modern replacement for DPSM in point-light
rendering (Unreal, Unity, id Tech, etc.) -- no equator degeneracy, and
hardware seamless-cubemap filtering handles cross-face sampling correctly.
The tradeoff: SCM's atlas currently packs lights as flat, variable-size 2D
tiles, which cube maps (6 faces per light) don't fit into without a real
packing-strategy change -- either 6x the tile count or a separate cube-array
path outside the atlas.
Scope for a future investigation:
- How much VRAM/tile-budget impact a 6-face-per-omni-light atlas would have
at typical ShadowLightCount values.
- Whether omni lights could be selectively promoted to cube maps (e.g. only
ones close to the player / player-held) rather than a blanket switch.
- Whether this is worth it at all vs. accepting the seam mitigation's
reduced (but non-zero) residual defect.
Not scoped for near-term work; this is a research/design issue.
Background
Dual-paraboloid shadow mapping (DPSM), used by the vanilla engine for
omnidirectional point-light shadows (which SCM's atlas repackages, not
replaces), has an inherent seam at the equator between its two paraboloid
halves. Confirmed via RenderDoc on this branch: the depth atlas band
straddling that seam is ~83% cleared/empty for a representative omni light
tile, causing receiver pixels near the light's local equatorial plane to
read back "no occluder" (unshadowed) even when a real caster blocks the
light. Most visible on player-held torches, since their orientation swings
constantly relative to any nearby receiving geometry.
Why this issue, separate from the seam mitigation PR
A same-architecture mitigation (rejecting/discounting shadow taps that land
on cleared depth near the seam, since the render-side paraboloid FOV is the
vanilla engine's own vertex shader and not something SCM controls or can
widen) is being tested separately. That reduces the visual defect but can't
add shadow data that was never rendered.
What to investigate
Cube shadow maps are the standard modern replacement for DPSM in point-light
rendering (Unreal, Unity, id Tech, etc.) -- no equator degeneracy, and
hardware seamless-cubemap filtering handles cross-face sampling correctly.
The tradeoff: SCM's atlas currently packs lights as flat, variable-size 2D
tiles, which cube maps (6 faces per light) don't fit into without a real
packing-strategy change -- either 6x the tile count or a separate cube-array
path outside the atlas.
Scope for a future investigation:
at typical
ShadowLightCountvalues.ones close to the player / player-held) rather than a blanket switch.
reduced (but non-zero) residual defect.
Not scoped for near-term work; this is a research/design issue.