Why does light leak through walls only sometimes?

Light leaks depend on transient state: a specific dynamic light in a specific position relative to thin geometry, viewed from a particular angle. The light may not cast shadows or the bias may be too small for the wall. Capture the active light, its position, shadow setting, and the camera so you can recreate the exact leak.

What causes dynamic lights to flicker or pop?

Flicker and popping usually come from culling boundaries and per-object light limits. When several lights overlap, the engine may drop one and the lighting jumps; distance culling pops lights out; lagging shadow updates pop as they catch up. Capture the light count, the light limit, player position, and framerate to pin the boundary down.

Why does my framerate drop in brightly lit areas?

Every dynamic light touching a pixel adds shading work, so overlapping lights, especially shadow casters and in forward rendering, spike GPU cost. Players report this as an area or firefight slowdown. Capture the active light count and type, framerate, GPU, and location so the cost links back to lighting and reaches the rendering queue.

Bug Reporting for Games With Dynamic Lighting

Quick answer: Dynamic lighting bugs, light leaks, flicker, popping shadows, and GPU cost spikes, depend on the state of the lights at the moment of failure: which lights were active, their counts and overlap, the GI or probe configuration, and the time of day. A screenshot loses that state. Capture the active light state, GI settings, GPU, framerate, and camera, then group reports to see whether the leak tracks one scene, one light setup, or one hardware tier.

Dynamic lighting is what makes a world feel reactive: torches you can shoot out, a day-night cycle, lights that move with the action. It is also a steady source of bugs that depend entirely on the state of the lighting at the moment things went wrong. A player reports light leaking through a wall, or a flickering room, or shadows popping as a light moves, or a framerate that craters when several lights overlap. The cause is in which lights were active and how they were configured, and a screenshot captures none of it. This post covers the lighting state you need to record so these reports become reproducible instead of evaporating when you load the level under different conditions.

Lighting bugs are state bugs

The defining trait of dynamic lighting problems is that they depend on a transient state. A light leak appears only when a particular light is in a particular position relative to thin geometry. Flicker happens when two lights or a light and a shadow fight over the same surface, or when a light is being culled in and out at a boundary. Popping happens as a moving light crosses a shadow update threshold. None of these are properties of the scene at rest; they are properties of the scene at the instant the offending lights were arranged just so, which is why a static screenshot rarely reproduces them.

That makes the active light state the single most valuable thing a lighting report can carry. Which lights were on, their positions and intensities, how many overlapped the player, whether a day-night cycle put the sun at a specific angle, and what the GI or probe configuration was. With that snapshot you can recreate the exact arrangement that leaked or flickered. Without it you wander the level toggling lights and waiting for the cycle to come around, hoping to stumble into the configuration the player hit, which is slow and unreliable for something this state-dependent.

Light leaks and the geometry behind them

Light leaking through walls is among the most reported dynamic lighting bugs and one of the most context-dependent. It happens when a light reaches a surface the level designer expected to be occluded, usually because shadows are not cast by that light, the geometry is too thin for the shadow bias, or a baked occlusion does not match a moved dynamic light. The leak only shows from certain angles and only when that light is active, so reproducing it demands both the light state and the camera position the player had when they saw the glow under the door.

Capturing the specific light involved is what makes a leak fixable. If the report records which dynamic light was active, its position, and whether it was set to cast shadows, you can immediately check whether the fix is enabling shadows on that light, thickening the geometry, or constraining the light's range. Lacking that, a leak report is just a bright smear you cannot place. The same applies to GI leaks, where indirect light bounces through a gap; knowing the probe layout and the active lights tells you whether the probe grid is too coarse for that room.

Flicker, popping, and culling boundaries

Flicker and popping in dynamic lighting usually trace to thresholds and culling. Many engines limit how many dynamic lights affect a surface, so when a player stands where several lights overlap, the engine may drop one and the lighting jumps. Move a step and a light is culled by distance, so it pops out. Shadow updates that lag the light cause a similar pop as the shadow catches up. These are all boundary behaviors: the bug lives at the edge where the engine changes its mind about which lights or shadows to compute, so reproducing it means knowing exactly where that edge was.

To pin these down, a report should capture the count of lights affecting the player, the relevant per-object light limit, and the player position relative to the lights, plus the framerate, since low framerate exaggerates shadow lag. A flicker that only happens with four overlapping lights and a low light limit is a precise, fixable situation once you can see those numbers. Treating flicker as a vague visual glitch loses that precision; treating it as a culling-boundary problem with the counts attached sends it straight to the right fix, whether that is raising the limit, reordering light priority, or smoothing the transition.

The GPU cost of overlapping lights

Dynamic lighting has a performance profile that punishes overlap, because every light that touches a pixel adds shading work, and forward renderers especially can choke when many lights stack in one view. So a frequent dynamic lighting report is not a visual bug but a framerate that collapses in a specific room full of torches or in a firefight where many muzzle and explosion lights pile up. Players report this as a slowdown tied to a place or an event, not to lighting, so the connection is lost unless the report captures the light count alongside the framerate.

Capturing the number and type of active lights, the framerate, and the location lets you confirm the drop scales with overlapping lights and decide how to fix it: cap the number of shadow-casting lights, switch that scene to a cheaper lighting path, or merge nearby lights. On low-end and integrated GPUs this cliff is steeper, so the GPU model belongs on the report too. Once you can see that the framerate dive happens only when six dynamic lights overlap on a particular card, the fix is concrete instead of a vague plea to optimize lighting in general.

Setting it up with Bugnet

Bugnet captures the lighting state these bugs hinge on without the player needing to understand any of it. When someone hits the in-game report button at a glowing wall or a flickering room, the report automatically carries the active light state, the light count affecting them, the GI or probe configuration, the time of day, the GPU, the framerate, and the camera transform. You add custom fields for the per-object light limit and the specific lights involved, and a category for leak, flicker, popping, or performance. Instead of a placeless smear, you receive the exact lighting arrangement to recreate.

Occurrence grouping then folds the duplicate lighting complaints into counted issues you can prioritize. The leak reports that all share one scene and one light become a single issue with a count, separate from the performance reports clustered in the torch-lit hall. You filter by scene and GPU to confirm the flicker is a culling-limit problem on a specific card, rank by occurrence to fix the leak the most players see, and after enabling shadows on the offending light you watch that count fall. One dashboard ties each lighting complaint back to the state that caused it.

A dynamic lighting review pass

Protect your lighting with a deliberate review pass that exercises its state space. Walk each scene across the full day-night cycle so sun-angle leaks surface, stand where dynamic lights overlap to provoke culling flicker, and follow moving lights to catch shadow popping. Stage a worst-case overlap, many lights stacked in one view, and watch the framerate to find the cost cliff before players do. Run it on an integrated GPU and a forward-rendering path if you ship one, because both make lighting costs and limits bite sooner. Capture reference shots to diff later builds.

Then feed the report stream back into the pass so it tracks where your real players struggle. Each new leak cluster in a particular room becomes a permanent case, and each shadow or culling fix gets a moving-light regression check so the pop cannot return unnoticed. Over a few releases you map which scenes leak, which light setups flicker, and which hardware hits the overlap cliff, and you light your world knowing those edges. That is how you keep reactive, dramatic lighting without each new torch becoming a fresh batch of unreproducible reports.

Dynamic lighting bugs are state bugs. Snapshot which lights were active plus the GPU and camera, and leaks and flicker stop vanishing when you reload the level.