World Overlay Gizmos And Culling
Purpose
World overlay gizmos render authoring context for triggers, NPCs, entry points, sounds, lights, post-process volumes, navigation zones, and related scene objects. They are diagnostic overlays, not extra scene data.
How It Works
Overlay providers own the projection for each object kind. Dependency indexes connect overlays to referenced catalogs and related scene objects. Culling limits drawing to the viewport while keeping selected objects visible enough to diagnose even when they sit outside the current visible bounds.
Workbench goal relevance and visibility toggles decide which overlays should be visible for the active authoring task.
Steps
Turn on overlays for the object family you are editing, then inspect dependency badges before moving or renaming referenced content. NPC overlays show status, interaction badges, AI radii, and conflict signals. Trigger and entry-point overlays should be checked before changing transfers or scene boundaries.
If an overlay contradicts validation, treat validation as the gate and use the overlay to locate the authored object.
Expected Outputs
A successful overlay pass shows the selected object, relevant dependency badges, culling-aware bounds, and conflict or status hints that match validation.
Invariants
Overlays must not write scene data directly. Culling should reduce draw cost without hiding selected objects. Dependency badges must reflect the same references validation checks. Visibility toggles should affect presentation only, not graph or validation state.
Common Mistakes
Common mistakes include treating overlay visibility as validation, editing scene data to match a stale overlay, hiding a layer and assuming the object is gone, or ignoring dependency badges before a rename.
Recovery Paths
Missing NPC definitions, hidden layers, selected objects outside the cull window, and stale dependency indexes are the usual causes of confusing overlays. Refresh the scene snapshot when overlay state does not match recently saved catalog data.