Unity AI Navigation新导航系统：动态烘焙与寻路实战解析-北京尧图网络

1. 从旧版导航到 AI Navigation这次升级到底动了什么先说结论如果你还在用 Unity 内置的 NavMeshNavigation 旧版组件那你这几年做的地图寻路其实一直处于“能用但不好扩展”的状态。Unity 从 2022 LTS 开始把导航功能整体挪到了com.unity.ai.navigation这个官方包里面也就是大家常说的 AI Navigation 包新 NavMesh 系统。它解决的痛点非常直接旧版导航网格必须在编辑器里预先烘焙好一张场景图只能有一套固定的 NavMesh运行时想动态改路、动态开桥、动态生成地图基本都要靠 Hack而且烘焙结果和场景耦合得很死谁动一下 Terrain 或者挪一堵墙导航网格就废了。新版 AI Navigation 的核心变化是把“烘焙”从场景编辑期解耦出来变成了可编程、可组合、可异步执行的流程。底层寻路算法仍然是 A*但数据生产和数据使用彻底分开了。你不再需要去 Window AI Navigation 面板里点那个 Bake 按钮而是通过NavMeshSurface组件把导航网格拆成多块、多层、多 Agent 类型运行时可以单独调用BuildNavMesh()重新生成某一片区域。这样一来动态地图、程序化生成地图、MOBA 类技能指示器、RTS 寻路、副本随机地图这些场景才真正有了解法。这篇我默认你是用过旧版 NavMesh 的至少知道 NavMeshAgent 是干嘛的、Bake 面板大概长什么样。如果你完全没接触过也没关系我会从安装包开始一步一步讲到运行时动态烘焙、动态链接、区域代价调整全程按项目实战的方式来。2. 安装与环境配置AI Navigation 包的正确打开方式2.1 包版本怎么选、什么时候必须升级AI Navigation 包从 2020.3 开始提供预览版2022.2 之后逐步稳定。你可以在 Package Manager 里搜索AI Navigation但注意内置的com.unity.modules.ai模块和新包不是一回事后者才是当前唯一维护的路线。我的建议是直接用 1.1.5 以上的正式版本1.1.x 是 2023 和 2024 LTS 的常见稳定线包括如下核心程序集Unity.AI.Navigation运行时导航网格组件与构建逻辑Unity.AI.Navigation.Editor编辑器烘焙窗口、Surface 调试视图如果你是 2021 LTS需要先确认 Unity 版本 ≥ 2021.3.21f1否则会有部分 API 不存在。2022 以后基本没有兼容顾虑了直接装就行。安装后你会发现菜单栏Window AI Navigation依然存在但打开后跟旧版的页面完全不同它是一个以 NavMeshSurface 为核心调试工具的总览面板。同时GameObject 的 Inspector 上如果挂载了NavMeshAgent路径调试、速度调试、剩余距离这些字段会直接显示在 Scene 视图里不用再靠 Gizmos 手写。2.2 Agent 类型、Area 类型、Layer三者的关系别搞混新手最容易迷糊的是这样几个东西NavMeshAgent 组件上的 Agent Type烘焙面板里的 Area Type以及物理用的 Layer。它们是完全不同的三个维度。Agent Type代理类型决定寻路时“谁可以走哪张网格”。你可以定义 Humanoid、Ranged、Large 等多个 Agent每个 Agent 各自烘焙一套数据互不干扰。Area Type区域类型是网格上的加权属性比如道路、草丛、水域影响同一个 Agent 在不同地块上的寻路代价。Layer 是物理碰撞分组跟寻路没有直接关系但会影响 Raycast 检测很多人做动态寻路时 Raycast 打不中地面就是因为 Layer 配置不对。从实际项目角度我的经验是最少配 3 个 Agent Type正常步行单位、飞行单位、大型单位比如 BOSS。飞行单位不依赖 NavMesh用 CharacterController 直接飞但如果你要做飞行单位在固定高度跟随地面导航点那也需要一个单独的 NavMeshSurface把 Surface 的烘焙高度调成固定数值。2.3 场景里要走的第一步把 Surface 组件挂上新建一个空场景创建一个 Plane 或者加载你的地形然后选中地面 GameObject。Inspector 里 Add Component搜索NavMeshSurface。确认Use Geometry选的是Render Meshes还是Physics Colliders。这一步很多人会选错。Render Meshes模式是直接拿 MeshFilter 的数据烘焙速度快不检查碰撞器Physics Colliders模式是所有碰撞体都参与烘焙包括 Box Collider、Mesh Collider适合复杂场景。如果你场景里的地面有凸凹地形、有自定义碰撞边界我建议用Physics Colliders因为最终 Agent 移动时碰撞体参与物理交互如果烘焙数据来渲染网格而碰撞是另一个形态会出现“导航能走但撞墙”的怪异现象而这类问题极难排查。设置完后点击 Inspector 上的 Bake 按钮场景里会出现蓝色的半透明网格这就说明第一张导航网格已经出来了。注意这一整张网格都属于这个 Surface如果你场景很大别让一个 Surface 去覆盖所有地图性能会有问题后面第三部分讲拆分。3. 烘焙参数深度拆解这张网格是你所有 AI 移动的底层地基3.1 参数表别照抄每一项都要知道后果AI Navigation 的烘焙参数都集中在NavMeshSurface组件上跟旧版 Bake 面板长得像但意义有些不同。参数名默认值影响Agent Radius0.5决定通道最小宽度所有小于两倍半径的缝隙不可通过Agent Height2.0决定最低头顶高度低于该值的天花板会被视为不可通行Max Slope45°超过该角度的坡面会被剔除Step Height0.4允许 Agent 迈上的台阶最大高度Drop Height1.0允许 Agent 从高处跳下的最大高度差Jump Distance2.0跨越缝隙的最大直线距离用于生成 LinkMin Region Area2.0小于该面积的孤立区域会被擦除Traversal Height0.0自定义可穿越高度通常配合洞穴类场景组的核心在于这些数值不是独立的而是共同定义一个“胶囊体”的通过能力。Radius 和 Step Height 决定水平方向的通过性Height 和 Max Slope 决定垂直方向的通过性。举个例子你有一个 0.8 米宽的走廊Agent Radius 设置成 0.5那这个走廊对寻路来说就是堵墙烘焙出来的网格不会延伸进去不管里面有没有宝物。这不是 Bug是你把它定义成了“过不去”。很多项目里“明明路能走Agent 就是不走”的问题80% 出在 Radius 太大或者 Min Region Area 把可走区域擦掉了。3.2 动态障碍物这块网格不是把 Collider 挪开就能解决的在做动态门、自动升降平台、可破坏墙体时很多人试着在运行时把障碍物 Collider 隐藏或者enabled false然后等着网格自己更新。这是最普遍的误解。NavMesh 网格是静态数据Collider 变化不会自动改网格。正确做法是给障碍物挂载NavMeshObstacle组件勾选Carve选项设置Carve Time Stamp和Carve Only When Stationary如果是移动平台。这样组件会在障碍物进入区域时实时“挖掉”导航网格里的对应部分Agent 就能在当前帧得到新的可通行路径。这里有个很关键的细节Carve Only When Stationary必须勾选上否则一个挪动的箱子会让避障系统每帧重新挖网格路径会频繁抖动单位会像无头苍蝇一样来回抽风。还有一个坑NavMeshObstacle 和 NavMeshAgent 不能同时挂在同一个 GameObject 上其实是允许挂但行为完全错乱。动态敌人先挂 NavMeshAgent 寻路又挂 NavMeshObstacle 阻挡别人——这种做法你看着逻辑没问题但它会让其他单位对这个敌人同时避让和跟随同一份数据路径计算会产生不可预知的抖动。3.3 多人格、大场景Surface 拆分与多 Agent 并行烘焙一个很大的开放世界关卡如果只用一块 NavMeshSurface 全部烘焙场景加载后第一次寻路会卡很久而且烘焙数据占内存巨大。正确的做法是按区块拆成多个 Surface每个 Surface 只负责一块区域通过NavMeshDataInstance机制在场景加载时把多片数据合并到一张全量 NavMesh 里。比如一个 4km x 4km 的地图我按 1km 一块切成 16 块 Surface每块独立烘焙。加载时用多线程分别调用BuildNavMesh()即使某一小块需要更新比如一个街区被炸塌了也只需要重新烘焙那一小块其余 15 块不动。这里的性能收益是非常明显的局部更新烘焙时间从秒级降到几十毫秒级。实际操作中合并数据时的边界缝是最大的敌人。两个 Surface 的边界如果参数不一致尤其 Agent Radius 不同中间会留出一条寻路走不到的缝。解决办法是让相邻 Surface 往外扩展烘焙范围这叫CollectObjects标记里的Volume模式加Padding值。我一般设置 Padding 为两倍 Agent Radius边界缝合得非常完美单位从一块地走到另一块路径是完全连续的不会出现在边界反复掉头的情况。4. 代码侧核心实现从烘焙到动态寻路的完整闭环4.1 运行时烘焙不预先烘焙直接代码生成程序化生成地图时最常见的需求是地图场景运行时创建墙体和路障的摆放每局随机导航网格只能在运行时跟着生成。这个新 NavMesh 系统给你提供了标准方案核心代码很简单using UnityEngine; using Unity.AI.Navigation; public class RuntimeNavBaker : MonoBehaviour { public NavMeshSurface surface; public void BakeCurrentScene() { surface.RemoveData(); surface.BuildNavMesh(); } public void BakeOnlyAround(Vector3 center, float range) { surface.RemoveData(); surface.collectObjects CollectObjects.Volume; surface.size new Vector3(range * 2, 20f, range * 2); surface.center center; surface.BuildNavMesh(); } }看到RemoveData()了吗这一步非常重要。很多人重复调用BuildNavMesh()却忘了卸载旧数据结果是每调一次内存里就多一份 NavMeshData寻路表现却越来越卡。正确习惯是每次烘焙前先RemoveData()或者用NavMesh.RemoveAllNavMeshData()做一个全局清理。需要注意BuildNavMesh()在主线程执行如果你在场景加载时同时跑很多逻辑会产生一个小卡顿。如果你做的是非常零碎、小块的地图更新可以尝试用NavMeshSurface的异步接口——但官网文档一直标注异步还属于实验性质。我个人建议小块地图更新直接同步烘焙就行实测 50m x 50m 的范围烘焙耗时在 20ms 以内感知不到卡顿。大范围更新该用拆分 Surface 的方式处理而不是赌异步。4.2 动态链接从断崖到吊桥用 NavMeshLink 连接孤岛两张静态网格中间如果隔着一条断崖你想让单位从一处跳到另一处靠烘焙参数里的 Jump Distance 永远不可靠因为那是试探性的“有效缝隙”不是明确指定的路。此时需要手动建一条NavMeshLink。在场景里创建一个空的 GameObject挂上NavMeshLink组件。组件上需要指定两个Transform位置作为起点和终点。最核心的字段是Cost Override这个值决定走这条链接的额外代价默认 -1 表示不覆盖用默认代价 1。如果你造了一座独木桥希望单位尽量少走就把 Cost 设为 3单位只有在实在绕不过去的时候才走桥。实际使用中一个很常见的需求是“自动根据运行时的开关决定桥是否可用”代码如下using UnityEngine.AI; public class BridgeController : MonoBehaviour { public NavMeshLink link; void ToggleBridge(bool isOpen) { link.enabled isOpen; NavMeshLink.UpdateLinkData(link); } }仅仅enabled false不够你还需要调用NavMeshLink.UpdateLinkData()让它把数据从全量 NavMesh 里移除。同一个坑在旧版 OffMeshLink 也出现过——把组件禁用后网格数据没刷新单位还是会傻傻地往断崖走。4.3 区域代价让 AI 避开沼泽、绕开危险区你有一片沼泽区单位踩上去会减速或者一片雷区单位走进去就死。正常的 AI 应该尽量绕开这些地方。但完全绕开又不行地图会变成绕远路走到天荒地老。这时候用 Agent 的Area Mask配合区区域代价来调整在烘焙前把沼泽所在的地形块设置成 Area Type 为Water或自定义类型。然后在代码里动态修改using UnityEngine.AI; public class AreaCostExample : MonoBehaviour { public NavMeshAgent agent; void UpdateCost() { int waterArea NavMesh.GetAreaFromName(Water); // 把水的代价提升到 10单位除非无路可走否则不会主动踩水 agent.SetAreaCost(waterArea, 10f); } }注意SetAreaCost的数值是倍数不是加法。默认 1你设成 10表示寻路算法判定走水路的长度乘 10所以只有在绕行距离超过水路的 10 倍时才会选择踩水。这个倍数怎么调完全看游戏节奏。休闲类游戏我建议保持 5 以内因为过高的代价会让 AI 在障碍判断时产生“所有路径都贵”的情况表现上显得非常纠结原地转圈却拿不出决定。4.4 路径生成与追踪不仅仅是 SetDestinationNavMeshAgent.SetDestination()是最基础的但实战不能只用一个函数就把所有 AI 奔跑做得自然。下面是我自己项目中稳定使用的一套“移动控制转向平滑停止判定”的写法public void MoveToPoint(Vector3 dest) { if (!agent.isOnNavMesh) { // 重新投射到最近的 NavMesh 点 if (NavMesh.SamplePosition(dest, out NavMeshHit hit, 5f, NavMesh.AllAreas)) { agent.Warp(hit.position); } return; } agent.isStopped false; agent.SetDestination(dest); } public bool HasReachedDestination() { if (!agent.pathPending) { if (agent.remainingDistance agent.stoppingDistance) { if (!agent.hasPath || agent.velocity.sqrMagnitude 0f) { return true; } } } return false; }关键的地方在于remainingDistance不是一个可靠的停止信号因为单位在拐弯、上下坡时这个值会上下跳动。一定要加上速度判断单位真的完全停下才算到达。另外还有一个隐蔽问题如果你的 Agent 初始位置没有精确贴在 NavMesh 表面而是稍微悬空或者在墙里面SetDestination默认会静默失败单位原地不动也不报错。排查这种问题最直接的办法是把NavMeshAgent的Warp()调用放到场景初始化的最后一步。5. 结合技能指示器场景从寻路到目标范围判定的联动实践5.1 为什么技能指示器会和 NavMesh 有关系你可能看到标题里的“技能指示器”一头雾水技能范围展示跟 AI 导航有什么关系有而且关系很大。MOBA 和 ARPG 类游戏里非指向性技能需要在地面上画出扇形、圆形、矩形指示范围。而这块指示区域是否合法是否在障碍物后面、是否超出地形边界、是否被墙体遮挡恰恰需要一个基于地面几何数据的判断机制。Unity 原生的Physics.Raycast是无法判断这些的它只能告诉你有没有 Collider 被击穿而 NavMesh 本身就是一张完整的可地面数据网格。用 NavMesh 做技能指示器的地面合法性检测有两个天然优势一是它自带可走性标记墙体后的地面根本没有网格二是它自带区域类型你可以针对不同地面区域决定技能是否可用。5.2 用 NavMesh 做技能地面检测的写法假设你做一个圆形范围技能需要判断这些事圆心是否在可走地面内范围内是否有不可通行的大片区域以及受击单位站在网格上的哪个位置。这个用 NavMesh API 可以实现如下using UnityEngine; using UnityEngine.AI; public class SkillGroundValidator : MonoBehaviour { public bool IsCircleAreaAvailable(Vector3 center, float radius) { if (!NavMesh.SamplePosition(center, out NavMeshHit hit, 1f, NavMesh.AllAreas)) return false; int sampleCount 12; for (int i 0; i sampleCount; i) { float angle (360f / sampleCount) * i * Mathf.Deg2Rad; Vector3 point center new Vector3(Mathf.Cos(angle), 0f, Mathf.Sin(angle)) * radius; if (!NavMesh.SamplePosition(point, out NavMeshHit edgeHit, 0.5f, NavMesh.AllAreas)) return false; } return true; } }把圆的周围 12 个点分别做SamplePosition检测任何一个点落不到导航网格上就认为这个技能中心或范围被墙体卡掉或者卡到了不可走地面。边界上的点是技能最容易被墙体挡掉的地方如果中心点合法但边缘点不合法我会让技能前摇阶段额外播放一个“不可用”的红色提示。这套逻辑在项目里实测表现非常顺畅它的性能开销小到可以忽略SamplePosition本身就类似查字典不用像 Physics 检测那样做几何碰撞。缺点是不能检测空中单位空中单位请走自己的判定方案高度差判断扇形角度数学不要混用。6. 性能调优与动态烘焙常见坑6.1 主线程卡顿的排查顺序如果每次局部烘焙都出现明显帧率波动我的排查步骤是查 Surface 的collectObjects设置。如果还是All每次烘焙会把全场景对象全部重新收集一遍性能必然崩。改成Volume后只收集范围内的物体CPU 开销能降一个数量级。查 Collider 数量。Physics Colliders模式下烘焙要读取所有碰撞体数据一个场景几千个 Collider光收集数据就几十毫秒。用Render Meshes模式的话烘焙就完全跳过碰撞体性能极快缺点是没有物理耦合。查 Agent 数量。每一张 NavMesh 上如果同时有 100 个以上的 NavMeshAgent 在寻路即使网格生成再快每帧的寻路路径计算也是不小的开销。这种情况要做 LOD 寻路离玩家远的小兵不逐帧寻路每隔 0.5 秒更新一次目的地。6.2 运行时路径抖动单位在移动中每帧调用SetDestination()去追一个移动的玩家会出现路径抖动这是正常现象不是 BUG。原因是寻路找到一个新路径后Agent 依照当前速度执行转向下一帧数据更新又产生新路径反复循环导致身体来回晃。解决办法public class SmoothChase : MonoBehaviour { NavMeshAgent agent; Transform target; float updateInterval 0.3f; float nextUpdateTime 0f; void Update() { if (Time.time nextUpdateTime) { nextUpdateTime Time.time updateInterval; agent.SetDestination(target.position); } } }把SetDestination的调用频率卡在 0.3 秒一次路径更新不会影响追击手感抖动明显消失。同时把 Agent 的Angular Speed调低比如 120 到 360 之间太高反而让身体转得比路径变更还快看起来像精神分裂。6.3 被 NavMesh 卡出世界的场景我的角色模型自己在跑但莫名的某一次寻路时突然消失或者瞬移了。这个几乎都是Warp的锅。Warp是强行走网格传送如果目标点在此帧的网格数据上是空洞正在被 NavMeshObstacle 挖掉那 Warp 就会把单位送到网格边界外甚至掉到 Y 轴负方向。做法是在 Warp 前先做SamplePosition检测确认目标点存在网格数据再传送必要时加一个最大尝试次数连续失败就终止行为不要无限传送。6.4 多 Agent Type 烘焙数据串场如果场景里同时有 Humanoid 和 Ranged 两个 Agent Type而对应 Surface 的agentTypeID没有分别指向各自类型烘焙出来的 NavMesh 会只有一个类型的数据导致某些 Agent 完全无法寻路。我遇到过最鬼畜的表现是单位站在原地isOnNavMesh返回 true但目标路径怎么都不生成。原因就是它的 Agent Type 没有对应到任何 Surface 烘焙数据。用NavMeshAgent的agentTypeID属性检查运行时直接打出来看千万别只在编辑器里猜。7. 一些实操经验与最终建议我前前后后在新旧导航系统之间切换了差不多一年多踩过不少坑有几个体会特别深。第一新 AI Navigation 包最值得投入的其实是可编程烘焙和运行时动态更新这块能力。如果你的项目还停留在“编辑器手动 Bake”的阶段那新系统带来的提升感知不会太强甚至会觉得 API 变复杂了。但你一旦开始做随机地图、动态地形、RTS 多单位调度回头看旧版会发现旧版那些所谓的 OffMeshLink、动态障碍物方案在工程化面前完全不够看。第二Map 生成逻辑和导航烘焙逻辑不要写进同一个脚本。最理想的做法是把地图数据生成、导航烘焙、路径行为三个模块完全分开。地图脚本只负责放置方块和墙体导航脚本只监听地图生成完毕的事件然后唤醒烘焙行为脚本去申领 Agent 并下发移动目标。这样代码调试和性能定位都清晰得多。第三多件套方案不要混用。有些同学觉得 NavMeshAgent 的单位需要避开另一个移动单位就给两个单位都加 NavMeshObstacle结果就是相互克制经常卡死。移动单位的互相避让应该用 NavMeshAgent 自身的Obstacle Avoidance参数Radius、Quality 这些来处理而不是堆组件。NavMeshObstacle 这个组件只服务于真正的静态或可破坏障碍物。最后说一个很多人直到项目上线都没发现的小细节NavMeshAgent的Auto Traverse OffMesh Link默认是开启的。它在典型场景下会帮你自动走 NavMeshLink但在你通过代码动态管理链接可用性时如果你没关掉它可能会出现 Agent 自己走过去然后又走回来的死循环。如果你需要完全控制移动就把这个选项关掉用自己的状态机控制哪里该执行跳跃动画、哪里该自动走桥。尤其是跳跃类动作游戏这个选项必须关否则角色的跳跃动作永远跟路径系统打架。这个内容后续如果你要继续深入我建议从NavMeshQuery系统入手它允许你在运行时用 Raycast、Pathfinding 的底层查询接口做更细粒度的控制比如做技能寻路范围算法、多单位分组寻路都会比现在基于组件的写法更高效。但那是后话了先把 Surface 烘焙、动态障碍和链接这套基础打牢你的 AI 移动系统就能应付绝大多数游戏场景了。

Unity AI Navigation新导航系统：动态烘焙与寻路实战解析

相关推荐

iOS 17 Fasting Tracker模板拆解：SwiftData与WidgetKit实践

Agent-Native应用实战：从架构设计到旧系统改造的完整指南

金融服务业技术实践：从合规场景出发的工程化落地

更多资讯

CNN人脸识别考勤系统：PyQt5端到端实现与毕设落地指南

基于LM317T和LM337T的高稳低噪双路线性电源设计

宝峰UV9R-Plus写频全攻略：CHIRP软件、驱动安装与自制写频线实操

10款降AI工具实测对比：从73%到7%的论文AIGC查重通关指南

Spring Boot大学生创业网站系统：源码拆解流程、权限与统计

superpowers：AI编程代理的标准化技能框架实战指南

今日更新

济南做网站多少钱：3个案例拆解，防黑源码下载全攻略

婚恋网站实战案例：避开3个高价坑，省钱50%还能跑赢流量

制作网页比较方便的软件怎么选?一文搞懂避坑指南

本周精选

如何彻底离线使用 Laya-CoreML：Hugging Face 下载、缓存机制与 local_files_only 详解

基于1Panel 部署MySQL MCP 服务：TaoToken 统一 Key 接入与 config.toml 配置实战

崇州园区营销网站建设避坑指南：5大注意事项保备案安全

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？