tags: [vr-ar]
Navigation mesh setup for VR locations
NavMesh for VR locations is not the same as NavMesh for regular game. In VR space perceived differently: NPC or enemy passing too close to player causes physical discomfort. NavMesh must account for this — including agent radius and walkability mask setup.
Additionally, VR locations often have complex vertical geometry: stairs, platforms, railings, uneven floor. Standard NavMesh Bake from Unity Window → AI → Navigation gives incorrect results without additional setup.
NavMeshSurface vs Legacy NavMesh
Component NavMeshSurface from AI Navigation package (com.unity.ai.navigation) replaces deprecated built-in NavMesh Bake. Key differences for VR:
NavMeshSurface can bake at runtime — necessary for procedurally-generated VR locations. In legacy mode NavMesh static. For VR games with destructible geometry (broken crates, fallen walls) either recalculate NavMesh locally via UpdateNavMeshData with limited NavMeshBuildSettings.Bounds, or use NavMeshObstacle for temporary zone blocking.
Agent Type is critical setting. For VR create minimum two agent types: Enemy_Standard with 0.35 m radius (tight navigation) and Enemy_Large with 0.6 m radius (bosses, large creatures). Using one type for all, large creatures squeeze into tight corridors, looks unrealistic.
Step Height — maximum step height agent traverses without NavMeshLink. For VR locations with realistic architecture: 0.25 m is one standard stairs step. If higher need NavMeshLink components.
Stairs and vertical transitions in VR
Stairs in NavMesh constant pain. By default NavMesh bake doesn't handle stairs correctly: either doesn't cover them (too steep slope), or creates NavMesh directly on geometry — with jagged profile, along which agents move in jumps.
Correct solution for VR: for each stairs create NavMeshLink with start point at bottom and finish point at top. Agent teleports between them instantly, climb animation plays as separate Animator state. Much cleaner than trying to make NavMeshAgent physically climb steps.
For open balconies and platforms: two separate NavMeshSurface (lower level + upper), connected with NavMeshLink on stairs and elevators. NavMeshLink should be bidirectional (Bidirectional = true) if agent can move both ways.
Off Mesh Link (deprecated) and NavMeshLink (new) differ: Off Mesh Link requires manually pointing two scene points, NavMeshLink is component with Area Mask and width. For VR better NavMeshLink — correctly handles multi-player overlaps.
Area Masks and walkability zones
NavMesh Area allows surface type marking: Walkable, Not Walkable, Jump. For VR add custom: Dangerous (fire zone, cliff — agent walks only if no alternative), PlayerPersonalSpace (3-meter zone around spawn — enemies don't enter without aggression trigger).
PlayerPersonalSpace implemented via NavMeshModifierVolume with Not Walkable type, attached to player object with offset. On enemy approach trigger removes, area recalculates via NavMesh.AddNavMeshData for local patch. Rough, but gives effect "enemy doesn't rush directly at face".
Dynamic obstacles: NavMeshObstacle
NavMeshObstacle is component for dynamic objects blocking agent paths. Two modes: Carve = false (object pushes agents like physical body) and Carve = true (object cuts hole in NavMesh).
Carve = true recalculates NavMesh in real time — expensive operation. For VR with destructible surroundings can't hang Carve on each crate: simultaneous 10-object destruction each initiates NavMesh recalc. Correct approach: Carve = false for objects disappearing (leave path anyway), Carve = true only for permanent obstacles (fallen wall, collapsed floor).
NavMeshObstacle.carveOnlyStationary = true is optimization: carving only when object stopped. Moving objects (rolling barrel) don't trigger continuous recalc.
Timelines and process
Work starts with location geometry audit: static/dynamic, vertical space complexity, agent count. Then Agent Types setup, Area Masks, base NavMesh bake. Next — testing all transitions (stairs, platforms) and NavMeshLink tuning. Finally — test with several simultaneous agents on stress scenarios.
| Location scale | Estimated timeline |
|---|---|
| One room / small arena | 2–4 days |
| Multi-level location (2–4 floors) | 1–2 weeks |
| Open world / procedural generation | 3–8 weeks |
Cost calculated after location geometry analysis and agent navigation requirements.