Fix: Unity Occlusion Culling Hides Visible Objects

The player walks toward a doorway. Two steps in, the chandelier in the next room vanishes. Three more steps, it re-appears. The bake completed cleanly with no warnings. Something in the visibility data is wrong.

How Occlusion Culling Decides

Unity’s occlusion culling divides the world into a grid of view cells. For each cell, the bake precomputes which renderers are visible from any camera position within the cell, considering all Occluder Static geometry as blockers. At runtime, the camera’s current cell is looked up and only the precomputed-visible set is drawn.

The system has three knobs:

• Smallest Occluder: minimum size to be considered as a blocker (default 5).
• Smallest Hole: minimum size for a gap rays can pass through (default 0.25).
• Backface Threshold: how much backface area an object can present before being treated as one-sided.

Pop bugs almost always trace back to mis-tuned Smallest Hole or to dynamic objects accidentally marked static.

Fix 1: Set Smallest Hole Below Your Doorway Width

If your narrowest passage is 1.5 m wide, set Smallest Hole to 0.5 (one-third of the passage). Larger values cause the baker to treat the doorway as solid and hide everything beyond it; smaller values bloat the bake.

Open Window → Rendering → Occlusion Culling → Bake and adjust Smallest Hole. Rebake. Check the Visualization tab to confirm the previously invisible room is now in the visible set when the camera is inside the doorway frustum.

Fix 2: Audit Static Flags

Select every dynamic object in the scene (players, enemies, projectiles, doors that move) and ensure Static is unchecked. Specifically, both Occluder Static and Occludee Static must be off.

For a door that opens, you need it to not be Occluder Static — the bake captured it closed. When it opens at runtime, the visibility data still thinks the doorway is blocked. Either keep doors out of the static set, or use Occlusion Areas with separate baked variants for open and closed states.

Fix 3: Use Occlusion Areas for Cell Density

In large levels, view cells get coarse and pops increase at cell boundaries. Add an Occlusion Area volume around regions where the camera actually goes (corridors, rooms) and leave large open spaces without one. The bake produces denser cells inside the area, more accurate visibility within them, and far fewer pops at cell transitions.

Fix 4: Mesh Bounding Box Sanity

If a mesh’s bounding box extends far beyond its visible geometry — common with characters whose rig includes off-mesh helper bones — the renderer is correctly culled when its bounds enter occluded space, even when the visible part is in plain sight. Inspect the MeshRenderer Bounds in the Scene view (toggle “Show bounds” in the inspector). Recalculate bounds with SkinnedMeshRenderer.updateWhenOffscreen = true for animated meshes:

GetComponent<SkinnedMeshRenderer>().updateWhenOffscreen = true;

This costs per-frame bounds recomputation but eliminates “hidden when on screen” bugs for animated characters.

Step-by-Step Diagnosis

1. Open Occlusion → Visualization and move the camera to where the pop happens.
2. Note the highlighted cell.
3. Click “Lock” and rotate the camera. The visible renderer list updates with each rotation. If the popping object never appears in the list, it’s missing from the cell’s visibility data.
4. Check the object’s static flags and renderer bounds. Likely culprit.
5. If everything looks correct, lower Smallest Hole and rebake.

Verifying

Build a navigation script that pans the camera through the affected area and logs Renderer.isVisible on the popping object. Before the fix, you’ll see false at the pop location with true a step later. After the fix, the value stays true across the transition.

“Occlusion culling is a precomputed lie. If the lie doesn’t match runtime reality, your scene pops. Tune the bake to match reality.”

When in doubt, lower Smallest Hole and add an Occlusion Area — both errors are towards over-conservative visibility.