GI radiance cache is wiped almost every frame in busy places (change spheres) #1482
Labels
No labels
amd
avatars
bug
builder
cannot-reproduce
crash
epic
feature
from-viewer
gl-removal
known-limitation
monitoring
parity
perf
platform
priority
critical
priority
high
priority
low
priority
medium
provenance
rendering
rt
status
in-progress
status
testing
status
up-next
triage
ui
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sky_line/Slipstream#1482
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In The Void (Celestis, 130/31/999), GI costs about 10 ms per frame: 26.6 ms GPU with RenderVKGI 3, 16.1 ms with GI off. The radiance cache hardly helps there. Only 3-7% of lookups find a cell, and about 100k of 145k live cells are invalidated each frame, while no light changes. Every GI header carries change spheres.
Two causes:
A change sphere far outside the region, at about (301695, -29056, 20), from the geometry (moved/registered) path. Once a header has 64 spheres, giAddSphere grows the last sphere to enclose any extra one. That merge produced a sphere with a radius of about 151 km, which wipes the entire cache for that frame. The store's radiance list (noteGiRadianceDirtyLocked) also merges into the last sphere when full.
Large emitters that move every frame. The builds there have glowing fullbright beams 1024 m long and 0.5 m thick (glow 0.2), plus a 300 m box. Their pose changes every frame, about 75 deltas/s each. Each beam becomes a sphere of about 190 m, plus 2 x 64 m of emitter reach. Every cell near that structure is inside one, every frame. A sphere is a poor fit for a long, thin emitter: the beam only lights what is near its line.
Fix for 1 (PR to follow):
Fix for 2 (planned, same PR or a follow-up; it touches the #1406 design):