What causes light probe seams on a character mesh?

Each renderer samples one tetrahedron of the probe network at its bounds center and applies that lighting to the whole mesh. When a large character mesh straddles a high-contrast probe boundary (sunlight to shadow), the entire body pops between two lighting values as the center crosses the boundary.

What is a Light Probe Proxy Volume?

LPPV samples the probe network at multiple points across the mesh's bounding volume rather than at a single center point. Lighting interpolates smoothly across the mesh and the seam disappears. Enable it via the Mesh Renderer's Light Probes dropdown.

How dense should my probe placement be?

Pack probes tightly across lighting boundaries (shadow edges, doorways, corners), and sparsely across uniform regions. The point of probes is interpolation; placing them where light gradient is smooth wastes bake time without improving quality.

Fix: Unity Light Probe Seams Visible on Baked Meshes

Quick answer: Densify your Light Probe Group around high-contrast lighting boundaries (shadow edges, doorways) and enable a Light Probe Proxy Volume on any renderer larger than the probe spacing. Single-sample probes always seam on big meshes.

Your character walks across the floor and her body suddenly goes dark mid-step. Or two pieces of identical scenery, an inch apart, are obviously different brightnesses. Light probe seams are showing through, and the answer is more probes plus an LPPV.

The Symptom

Dynamic or non-lightmapped meshes show a hard band where lighting changes abruptly. Walking across the band, the entire mesh pops from one lighting state to another. The boundary follows the geometry of the probe tetrahedralization rather than anything in the actual scene.

What Causes This

Light probes are sampled per renderer, at the renderer’s bounds center. The probe network is tetrahedralized; the sample point falls into one tetrahedron and the lighting is interpolated from that tetrahedron’s four corner probes. When the renderer’s center crosses a tetrahedron boundary, the four corner probes change — sometimes drastically — and the whole mesh pops.

The Fix

Step 1: Densify probes across lighting boundaries. Open your Light Probe Group. Add probes along every shadow edge, doorway, window cast, and indoor/outdoor transition. Keep probe spacing tighter than the smallest visual lighting change you care about.

// Rough rule of thumb
indoor uniform region:    one probe per ~3 m
shadow boundary:          probes every ~0.5 m along the line
doorway:                  probes inside, in plane, outside
character height range:   probes at floor and at head height

Step 2: Enable Light Probe Proxy Volume on big meshes. On any Mesh Renderer that is large compared to your probe spacing (terrain, large props, big characters), set Light Probes → Use Proxy Volume. Add a LightProbeProxyVolume component on the same GameObject. The mesh now samples the probe network at a 3D grid of points across its bounds and interpolates per-fragment.

Step 3: Re-bake. Window → Rendering → Lighting → Generate Lighting. Probe data is part of the bake; new probes are sampled here.

LPPV Settings That Matter

Resolution Mode = Custom. Set explicit X/Y/Z probe counts for the volume. 4×4×4 is plenty for most characters.
Bounding Box Mode = Automatic Local. Tracks the renderer’s bounds.
Probe Position Mode = Cell Corner. Sample at corners; interpolate inside.

Why Static Meshes Should Be Lightmapped, Not Probed

Probes are for dynamic or movable geometry. A static prop should be marked Contribute GI in the lightmapping settings; it then receives baked direct lighting per-texel and probes are irrelevant to it. If you see seams on a clearly static mesh, check that it has a lightmap UV channel and is marked Contribute GI → Lightmap.

Verifying It Worked

Window → Rendering → Light Probe Visualizer (or use the Lighting Window’s Probe Visualization mode). Walk a test object across the boundary in Play Mode; lighting should now interpolate smoothly. Toggle the LPPV on and off to compare.

Understanding the issue

This bug class falls into a pattern that's worth understanding beyond the specific case. In Unity Engine, the underlying behavior is shaped by how the engine layers its abstractions - the public API you call, the runtime systems that respond, and the platform-specific implementations underneath. A bug at any layer can produce symptoms that look like they originate at a different layer. Triaging effectively means recognizing which layer the symptom belongs to, even when the gameplay code is what's visible.

The specific bug described above is the kind that surfaces during integration rather than unit testing. It depends on a combination of factors: the asset configuration, the runtime state, the platform's specific behavior. In isolation, each piece looks correct; in combination, the bug emerges. This is why thorough integration testing - playing the actual game in realistic conditions - catches things that automated tests miss.

Why this happens

The triage path for this kind of bug is long. The symptom appears in gameplay, but the cause is in a different system. The reporter describes the gameplay effect; the engineer has to translate that into a hypothesis about the underlying cause. Misdirection is common.

At the engine level, the behavior comes from a deliberate design decision in Unity. The engine team chose a particular trade-off - usually performance versus convenience, or generality versus specificity - and that trade-off has consequences when you push against it. Understanding the trade-off is what turns 'this bug is mysterious' into 'this bug is the expected consequence of this design'.

Verifying the fix

After applying the fix, the verification step has three parts: confirm the original repro is resolved, confirm no obvious regressions in adjacent functionality, and (for shipping titles) deploy to a small player cohort first and watch the crash and report rates. Each step catches something the others miss.

Reproducibility is the prerequisite for verification. If you can't reliably reproduce the bug pre-fix, you can't reliably verify it post-fix. Spend time getting a clean reproduction before you write any fix code. The fix is fast once you understand the reproduction; the reproduction is the slow part.

Variations to watch for

Related bug classes often share the same root cause. If you find yourself fixing this issue, look for cousins: similar symptoms in adjacent systems, the same data flow but a different value, or the same fix pattern in another module. The catalog of 'we've seen this before' becomes valuable institutional knowledge.

Adjacent bugs often share a root cause. After fixing the case you've found, spend an hour searching the codebase for similar patterns. What's the same call with different arguments? The same data flow with a different entity type? The same lifecycle issue in a sibling system? Each match is a candidate for the same fix, or a related fix that prevents future bugs of the same class.

In production

In shipping builds, this issue may interact with other production-only behavior. Stripping, encryption, asset bundling, and platform-specific code paths can each modify the symptoms. When players report a related issue, capture build SHA, platform, and any feature flags - those three fields cover most of the production-only variations.

When triaging a similar issue in production, prioritize gathering data over hypothesizing causes. A player report describes a symptom; what you need is a build SHA, a session timestamp, and ideally a screen recording or session replay. With those, the bug becomes tractable. Without them, you're guessing at hypothetical reproductions that may not match what the player actually hit.

Performance considerations

If this issue manifests under high load (many actors, many particles, many network connections), profile the post-fix code path with realistic counts. The original cost was a bug; the new cost is real work, and real work has a budget.

Diagnostic approach

The diagnostic tools available depend on your engine and platform. Use the engine's native profilers and debug overlays before reaching for external tools. The native tools have context that external tools lack - they know which subsystem owns the code, which assets are loaded, and what state the engine is in.

For Unity-specific diagnostics, the editor's profiler is the canonical starting point. Capture a representative frame with the symptom present; compare against a frame without the symptom; the diff often points directly at the cause. If the symptom is non-deterministic, capture multiple frames and look for the pattern - the cause is usually a state transition or a specific input value rather than a continuous effect.

Tooling and ecosystem

Modern engine versions ship better tooling for this kind of issue than older versions. If you're on an older release, the diagnostic step may take significantly longer because the tools you'd want don't exist yet. Sometimes the right answer is upgrading rather than fighting through limited tooling.

Within Unity, the relevant diagnostic surfaces include the standard frame debugger, memory profiler, and engine-specific debug overlays. Each one shows a different facet of what's happening. The frame debugger reveals draw call ordering and state transitions; the memory profiler shows allocation patterns; the debug overlay reveals per-system state. Bugs that resist one tool usually surrender to another - the trick is knowing which tool to reach for first.

Edge cases and pitfalls

Platform-specific edge cases are worth enumerating explicitly. iOS handles backgrounding differently than Android; Windows handles focus changes differently than macOS. A fix that works on the development platform may not work on every target. Test on each shipping platform deliberately.

When writing a regression test for this fix, focus on the boundary conditions that surfaced the original bug. Tests that exercise the happy path catch obvious regressions; tests that exercise the boundary catch the subtler regressions that look like new bugs but are really the original returning. The latter are the tests that earn their keep over the long life of the project.

Team communication

Document the fix and its rationale in the commit message or attached engineering doc. Future engineers will encounter related issues; the rationale tells them whether your fix is reusable or specific to the case at hand. Without rationale, the fix gets reverted or copied incorrectly.

If this fix touches a system several engineers work in, a short writeup in the team's engineering channel helps. Not a full design doc - a paragraph explaining what was wrong, what's fixed, and what to watch for. Future engineers encountering similar symptoms will search for the fix; making it findable is a small investment that pays back later.

“Probes where light changes. LPPV on big meshes. Lightmaps on static. Seams disappear.”

Related Issues

For reflection probe staleness, see reflection probe runtime. For static lightmap UV problems, see lightmap UV overlap.

Densify probes. Add LPPV. Re-bake. The lighting becomes one smooth gradient.