随便聊几句关于UE3的Navigation Mesh

http://lichong.blogbus.com/logs/53924912.html


UDK这次给公众看到的各种新功能里头，我个人比较感兴趣的一个就是其Navigation Mesh系统

说起Navigation Mesh这个词，就不由得勾起诸多回忆，打个不恰当的比方，就好比玩摄影很多很多年之后，让你回忆当初最早倾心和认真使用的那台也许很便宜很低档的相机

最早接触这个词还是在做Splinter Cell 4的时候，我们拿了SC3的引擎，一看，加了好多UE2本身所没有的功能，其中一个让人眼睛一亮的，就是一套新的寻路系统，Navigation Mesh，我们一般管它叫Nav Mesh

我还记得某位洋大人给大家培训讲解该引擎关卡编辑方面的使用（当时我们觉得他讲得不行，然而如今知道原来上海去取经的人总是不招那边待见的，那也许。。。），觉得这东西好啊，2D的面，比路点那套东西的点到点的寻路信息多多了，更加精确，更少bug

然而实际使用，并没有那么理想，用起来不少的麻烦，比如：
- 要手动编辑Mesh
- 要人肉检查靠近Collision处的边线标记是否合适
- 要和攀爬用的GEO系统配合
- 要区分Sub NavMesh，区分好上下层次
- Mesh之间无法连接，故交接部分要避免NPC的活动，或者互相多留出一部分Mesh

所以当时LD纷纷觉得场景里头的Nav，能不动就最好别动了，全部手动地人肉地保证每个细节的正确，是非常耗时耗力的事，所以当看到SC5最初演示的那一套改进的自动生成的NavMesh系统时，真要泪目阿（当然后来的事情峰会路转肯定是当时谁都想不到的）

然后是做Beowulf，用的一个叫做Yeti的引擎，这引擎的寻路用的一种叫做NavShape的东西，这东西概念上和NavMesh是一回事，但具体体现在编辑层面上还有许多不同：
- 不光是2D的概念，而是在2D面上增加了一个高度概念（相当于在一个2D拓扑上面Extrude一个高度出来），高度需覆盖所需的检测
- Shape之间的层次区分得人肉设定且必须分明，其高度所涵盖的区域也忌讳叠加
- Shape之间的连接通过一些特殊的Polygon来实现，人肉在其相对的边上打标记，Polygon的角度等需要严格的遵守规则
- Shape的2D拓扑边缘造型，需要全手动编辑
- 从一个Shape寻路到另一个Shape，需要计算其间涉及的Shape的数量，会寻找经过Shape最少的一条路，但这经常是不合理的一条路
- Shape和NPC分组的人数相关，通过它来限制某块区域上的NPC数量

这套系统制作起来没有SC4那套繁琐，毕竟需要应付的AI情况不会如SC那么复杂，但实际上这套东西bug非常多，最主要的就是各种寻路路线选择的bug以及卡在某些角落不能动弹的问题，反而SC4里NPC卡住的情况比较少，感觉主要的问题其实涉及到两套东西的设计理念：

1）SC4 NavMesh的理念就是，尽可能只用一个Mesh，用三角形去寻路，用边线控制和障碍的互动。而Mesh其实就是一层薄皮，无论你怎么扭曲，它都是没有厚度的，而没有厚度可以理解为厚度无限，这要求制作上必须考虑避免上下层次叠加，但这实际是不能避免的，为解决这问题，就增加两个规则，一个是Mesh内分不同的SubMesh，另一个是不同层次用不同Mesh，但NPC在寻路上只能局限于各自的层次。用三角形寻路，容易为制作人员所理解且对数据可靠性的要求不是很高，牺牲制作人员的手工劳动即可换得bug较少的基本寻路，用边线控制和障碍的关系，直观但同样耗费人力

2）Yeti这种，理念就是，用一堆基于2D拓扑的拉伸出高度的Shape,相当于volume（实际上很不相同）的东西，将一个连续的环境分割包容，以形成游戏小分区，之间通过边线和Polygon连接，区块的数量参与寻路的计算。由于是拉伸出的高度，所以其底面和顶面都是水平的，带来两个问题：一个，没有一个贴合复杂地表的底面可供观察，第二，Shape的底面必须低过场景（可寻路的）最低处，顶面必须高过最高处，当高度差很大而大部分面积的地面又比较平缓时，Shape的大部分是浪费的，这种浪费不会造成什么计算的问题，但影响地形布局的弹性，因为Shape是不允许互相叠加或者嵌套。这就是和Volume很不相同的地方（Volume其实是卷曲而闭合的Mesh）。高度的有限让分层显得容易，但刻意的区分成数块（这基本是为了迎合Beowulf这个脏游戏的需要，不知道GRAW在这方面如何）事实上削弱了这种分层方便带来的好处，区块同时参与游戏分区和寻路路线的计算，我觉得是最脏的一点，相比较于NavMesh的三角面，区块的大小受游戏逻辑分区的限制而无法均匀化，而Mesh的话你可以手动优化三角面，Shape区块的数量和实际寻路意义上的重要性经常不成比例，比如一块大面积的平地，就用一块，而一个小的过道，也是一块，如果有个上下坡，还得增加几块，所以用数量来选择寻路路线非常可笑，经常是明明一条很短的路，因为多了几块Shape，NPC就不用，非要跑大老远绕一圈回来，因为那一头Shape少，这件事情上SX法国人的说法是让制作人员适应规则，但能么？Shape之间通过边线和Polygon来连接，本身没什么问题，唯一就是polygon的造型弹性太小，但这更多的也不是和寻路相关

所以回头看, SC4那套就是麻烦，而Yeti就是Buggy
这种情况下，我就一直很期待EPIC能够在UE里头引入NavMesh的概念，毕竟用过NavMesh的，不会觉得PathNode系统有多好，然则一度EPIC给我的感觉是要在路点上头走到黑了，连Gears都用阿用的（当然路点在某些方面也有其魅力）。然后在去年的时候，从UDN的某些页面上已经悄悄出现了NavMesh，然后今年终于借着UDK，给公众看到了EPIC的这套东西。具体怎么用，UDN上面只有很简单的几篇文章，官方说法是近期在写文章

在UDK里头，默认的AI因为是基于UT3的，所以寻路上不能用NavMesh，但实际编辑制作的东西已经在了
初步地试了一下，感觉还是有些不一样的，目前的印象来说颇为不错：
- 自动生成NavMesh，你所要做的只是放置一个叫做Pylon的Actor，然后给它个半径圈一块地，Build Path，它就在圈进来的范围内给你生成NavMesh。你就想像成从Pylon中心点出发，向半径内的四方进行探测，合法的地方生成Mesh，由于是探测（Explore），所以如果半径内有两块彼此不物理连接的区域（走不通），则只能在Pylon中心点所处的那块区域上生成Mesh。由于是探测，所以Pylon本身会检测其下方地面碰撞的合法性，如果离地过高或者陷入地下，则不生成Mesh，当然一定距离内，它可以自动适配到最近的地面碰撞体上
- 如果两个Pylon有穿插，A可以是B的子集，或者AB有交集，但AB的中心点如果同时在交集里且一方不是另一方的子集，则计算时忽略其中一个（具体忽略谁好像和Instance的先后或者说自动命名的排序有关），故这种情况是要避免的。AB的交错部位上会自动生成连接
- 生成的Mesh是基本用长方形Polygon，在靠近障碍处根据Collision来进行剪裁，根据UDN文档的说法，进行了面数的优化，尽量用越少和越大的方形，其间的间隙用小一些的、更小一些的方形去填补。方形之间也不是严格的顶点焊在一起，但又不是一整个方形的平面（我仔细观察了一下，其实是用三角形来分的，只是显示为方形），整个Mesh给人的感觉，有点像用一块块鳞片镶成的，这和SC那种严格衔接的三角形完全不同（当然实际底层运算上有什么差别就不好说了）
- 能够适应地形的起伏，在起伏角度超出合法范围处就自动生成边缘竖面，每个面上都有标出法线，可以直观地看到起伏状况，边缘竖面非常直观地表示了Mesh的边界
- 能够自动处理上下层的情况，因为没有高度上的逻辑制约（我得再看看文档，然则今天UDN挂了），所以只要能Explore到的不同层次，就都能生成，且会检测层之间Collision的间隙高度是否合法，不合法的部分就会剪掉
- 提供了Dynamic Pylon，针对可移动的表面（Mover），还有一种叫做AI Switchable Pylon，还没试过，不好说，但名字看着很浅显
- 根据UDN的文档，EPIC认为Pylon可以支持动态再生成（SC5一度让人羡慕的东西，不过现在么。。。）
初步的感觉是，EPIC的这套东西还是可以的，下面就是期待什么时候能用一下AI直接能跑的版本

然后有些关于SC5的NavMesh的一些消息：
- 用的是SC4的引擎改的
- NavMesh可以在UED里Build生成，但需要在StaticMesh上打AffectNav的标记来告诉你哪些地方Build（这点上我觉得比Pylon繁琐）
- NavMesh可以人肉编辑
- 需要先放置一个NavMesh，然后用它作为源头来Build，我的理解是（因为是打听到的，所以只能猜测），你先人肉拉动NavMesh以覆盖整个你要算的区域，然后编译的时候把不需要的给剪掉
- 还是用三角形，自动生成的三角形造型上没有优化，容易有细长条的，面数据说也进行了优化
- 因为用了SC4引擎，所以华丽的动态生成NavMesh没有了，Ingame里的Dynamic事件，都是预先准备好变化之后的Mesh，这些相关的Gameplay Object会打包成Actor Group
- 原则上一个连贯的场景还是只用一个Mesh，不同Mesh之间的衔接要注意避免，或者用一些强制不能回头的手段