What causes SDFGI light leaking into interiors in Godot?

SDFGI stores scene geometry in a coarse signed-distance field, so walls thinner than a voxel let outside light bleed through into interior spaces.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix SDFGI Light Leaking Into Interiors in Godot

Quick answer: Make walls thicker than the SDFGI cell size, reduce the number of cascades or the first cascade's size for finer voxels, and bake interiors with a separate occluder if needed.

SDFGI is a coarse voxel approximation, so thin single-sided walls do not register as solid and outdoor light leaks inside. Giving walls real thickness and shrinking cascade cells closes the gap.

How to fix it

1. Thicken thin walls

Add real geometric thickness to single-plane walls so they exceed one SDFGI cell. Paper-thin geometry is invisible to the distance field and cannot block light.

2. Shrink the first cascade

Reduce the SDFGI first cascade size in the WorldEnvironment so each voxel covers less world space, giving finer occlusion near interior walls.

3. Mind double-sided faces

Ensure walls are not flipped or one-sided where SDFGI expects solid volume; back-facing or zero-thickness faces let the field treat the wall as empty.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Godot error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Most of the time the fix is small. Seeing the failure clearly is the part that actually costs you.