背景
最近在实现一个 3D 的沙盒类游戏，基本的功能就是在一个 3D 平面里，进行建筑物的搭建，可以在场景内添加或者编辑建筑物，然后平面内存在一个人物模型，他可以穿梭行走于建筑物之间。
在实现人物的行走功能的时候，我们很自然地想到取终点和起点两点的坐标，然后连成直线进行行走即可，在没有建筑物的时候这个想法确实很好，可是一旦在地图中出现建筑物之后就会发现：忒喵的人物穿模啦！
至此，寻找避障方案之旅开始了。
使用 Babylon.js 自带的避障功能
由于我们的项目是使用 Babylon.js 框架来进行开发的，因此本着“能不自己写坚决不自己写”的原则，我们的第一个想法就是使用 Babylon.js 自带的避障功能。
介绍
简单介绍一下 Babylon.js 中自带的避障功能，它属于框架的一种拓展功能，需要结合 RecastJS 依赖进行使用。
利用 RecastJS 进行导航网格（Navigation Mesh）的生成。然后再通过 RecastJS 中的 Crowd Agents 模块进行自动的寻路和避障。
可能看到这里的你会有一个疑问，什么是导航网格，这里引用一段我在其他博客中看到的定义和介绍：“导航网格（Navigation Mesh），也俗称行走面，是一种用于在复杂空间中导航寻路、标记哪些地方可行走的多边形网格数据结构。”
一个导航网格是由许多的凸多边形组成的，大白话地讲就是将地图切割成 N 份，每份都是一个凸多边形，我们称一个多边形为一个 Poly。
然后当人物在导航网格中行走时，会判断起点和终点是否在同一个 Poly 中，如果是的话，则直接将起点和终点连成直线，该直线即为人物的行走路线；否则就需要使用相应的寻路算法进行路径的计算，计算出人物需要经过哪些 Poly，再利用这些 Poly 算出具体路径。
应用
在知道 Babylon.js 自带了这么一个功能的时候，当时我的内心是狂喜的，于是乎照着官网示例对着键盘一顿乱按后，刷新页面，新增一个建筑，点击地图，期待着人物模型自动地绕开建筑物，结果：
What happened?
经验告诉我，应该是导航网格没有正常生成导致的，幸好，RecastJS 提供了多样化的参数让我可以去调整导航网格的生成规则。
于是乎，经过了几乎一整天的参数调整，最后发现是我太天真了，结果根本没有发生什么变化。只有当添加的障碍物体积很小很小的时候，人物的避障功能才能成功生效，当障碍物的体积稍微大一点点，人物就会直直地穿过建筑到达终点。
当时我的想法是：行吧，既然调参也没有用，那我去看看 RecastJS 的源码，看看它是如何生成导航网格的，以及是什么导致它导航网格生成不正常的。
所以，我转战到了 github。不搜不知道，一搜吓一跳，发现这个 RecastJS 原来前身是一个 C 语言开发的库，后来不知道被谁转成了 Javascript 版本发到了 npm 上，也就是说，我们看不到 Recast 的 Javascript 版本源代码。
额，好吧，使用 Babylon.js 自带的避障功能这条路算是彻底堵死了。
自建导航网格和搜索算法
既然自带的功能没用成，而且在 Babylon.js 的社区生态中尚未有更好的解决方案，那么就只能自力更生了，打造一套适用于当前场景的导航网格和搜索算法。
我们先来理一下整体的思路和流程：
- 获取地图数据，生成合适的导航网格
- 获取人物行走的起点和终点
- 利用搜索算法在导航网格中找到起点到终点的最短路径
- 操作人物按照最短路径进行行动
选择合适的搜索算法
先来讲讲搜索算法，说起寻路的搜索算法，最先让人想到的应该是大名鼎鼎的广度优先搜索算法。
广度优先搜索
广度优先搜索算法是一种很常用的寻路算法，被广泛地应用在计算机的各种场景，比如 Windows 的画板涂鸦功能，就是用广度优先算法实现的。
我们可以将整个地图简单地拆分成 N 个 1X1 的正方形格子，广度优先算法的基本原理很简单，就是从起点格子出发，每次可以朝上下左右进行移动。下图中的绿色标记点是起点，而红色标记点是终点。
每一轮探索完毕之后，会标记这一轮探索过的方块为边界（Frontier），也就是下图中的绿色正方形格子。
然后算法会从这些边界方块开始，逐一继续下一轮的探索，直到在探索过程中找到了终点方块后，算法才会停止探索。
在每次探索时，我们需要顺势记录路径的来向，也就是形成一个类似链表的结构，在到达终点后，我们便可以根据这个来向的记录找到对应的最短路径。
另外，每一轮所探索的路径格子在下一轮探索开始前要对其进行标记，让算法知道这个格子已经被遍历过了，之后的探索过程中如果遇到了被标记的格子，将直接跳过不会纳入后续的探索轮次。下图中灰色的格子即为被标记不再探索的格子。
其实广度优先算法实现起来很简单，应用场景也很广，但是它也有很明显的缺点，那就是它很蠢，最坏情况下需要遍历整张地图才能找到目标点，所以很容易因为移动次数过多导致出现性能问题。
A-Star 算法
为了解决广度优先算法的性能问题，于是乎我们引入了启发式搜索 A-Star 算法，与广度优先算法有所不同的是，我们在每一轮搜索的时候，不会去探索所有的边界方块，而是会选择当前代价（cost）最低的方向进行探索，因此它是具有一定的方向性的，它前进的方向取决于当前边界方块里最低代价方块所在的位置。
代价分成两部分，一部分是当前路程代价 ，或者叫做当前代价（f-cost），它表示你当前已走过的路径数量，比如当前格子需要走三步才能到达，则当前代价为 3。
另一部分代价是预估代价（g-cost），表示从当前方块到终点方块大概需要多少步，由于它叫“预估”代价，因此它并不是一个精确的数值，这个估计值主要是用于指导算法去优先搜索更有希望的路径。
这里介绍两种常用的预估代价：
- 欧拉距离（Euler Distance）：当前格子到终点的直线距离，用数学公式来表示的话就是 Math.sqrt((x1 - x2)^2 + (y1 - y2)^2)
- 曼哈顿距离（Manhattan Distance）：指当前格子和终点两点在竖直方向和水平方向上的距离总和，用数学公式来表示就是 |x1 - x2| + |y1 - y2|，曼哈顿距离的计算不需要开方，速度快，性能较高
当我们得知某个边界方块的当前代价和预估代价，我们就可以通过把这两个数值相加便可以得到它的总代价，即：
总代价 = 当前代价 + 预估代价
每一轮寻路我们都寻找当前边界里总代价最低的方块进行探索，并和广度优先算法类似的记录其来向并标记自身，直到探索到终点为止，我们就可以通过 A-Star 算法获得相应的最短路径。
相比于广度优先算法，A-Star 算法由于具有一定的方向性，因此一般而言它比广度优先算法少了许多无用的探索，遍历地图格子的数量也少很多，因此一般情况下整体的性能会比广度优先算法要好。
至此，我们已经有了合适的搜索算法，下一步就是要看看怎么样去生成我们的导航地图了。
自建导航网格
在讲如何自建导航网格之前，我们必须了解一个概念，那就是在 3D 场景中的模型，都是由一个又一个的三角面构成的，因此在构建导航网格时，我们也要遵循这个原则来进行设计。
Recast 中导航网格的生成原理
那么我们可以简单了解一下在上文提到的 Recast 中，构建一个导航网格需要经过哪几个步骤？简单来说一共是六步。
- 场景模型体素化（Voxelization），或者叫“栅格化”（Rasterization）。简单来说就是将三角面数据转换为像素信息（也叫体素信息），可以理解为是从一个一个三角形面转换成了一个个的点阵信息。
- 过滤出可行走面（Walkable Suface），即通过第一步得到的体素信息计算出体素顶部可行走面的数据。
- 生成 Region，在获得可行走面后，我们通过一些算法将这个面切割成一个个尽量大的、连续的、不重复的且中间没有洞的区域，这些区域成为 Region。
- 生成简化边缘（Simplified Contours），通过上一步得到的 Region 信息，算出每个 Region 的边缘信息，再通过一些简化算法对边缘轮廓进行简化，我们称这个简化轮廓为（Simplified Contours）。
- 生成 Poly Mesh，我们通过对简化轮廓进行划分，把每个简化轮廓划分成多个凸多边形，每个凸多边形我们可以称之为一个 Poly，它是寻路算法里的基本单元。
- 生成 Detailed Mesh，最后我们对每个 Poly 进行三角形化，将它划分成多个三角形，生成我们最后搜索算法需要用的导航网格。
这里值得一提的是，场景模型在经过第三步生成 Region 后，三维的场景其实已经被简化成类似二维的存在了，方便了后续的一些计算和操作。但与此同时，这一步也导致模型在移动时没办法完全垂直于地表，只能一直保持垂直于 xOz 坐标平面的状态。
结合实际情况的导航网格的生成方式
而在我们这次的沙盒游戏当中，其实地图和建筑都是相当简单的，地图可以简单地看作一个 64*64 的正方形平面，而建筑也可以简化成一个个简单的正方体。
参考上述 Recast 网格导航的生成步骤，最后生成出来的是一份不重叠的网格数据。
由于我们的沙盒地图并不是特别的大，因此，我们导航网格的生成方式其实就很简单了，一句话概括：直接用 64*64 正方形平面的顶点数据作为原始的导航网格数据，再将与建筑物在地面的正方形投影接触的顶点数据排除掉，最后剩下顶点数据所构成的网格就是我们需要的导航网格了。
在文章的后续我们会更加详细地讲到该生成方式，此处读者有个基本的概念即可。
A-Star 搜索算法与导航网格的结合
至此，我们已经基本了解了 A-Star 搜索算法的原理和导航网格的生成方式了，是时候将他们组装结合起来了。
首先我们前面在讲 A-Star 搜索算法的时候，我们假设地图是由 1X1 的正方形格子组成的，但在实际情况里，由于 3D 场景下的物体都是由三角面组成的，因此我们的导航网格也是由一个个三角形构成的，因此我们 A-Star 算法中的一些计算也要进行相应的调整。
在计算总代价的值时，我们会像上述说的那样，将总代价分成当前代价和预估代价两方面，在当前代价方面，我们仍然按照当前已走过的路径数来进行计算。
而预估代价则使用欧拉距离来进行计算，这里的计算会从正方形格子间的距离计算转为三角面间的距离计算，因此我们需要计算每个三角面的中心点，格子间的距离我们会使用中心点间的距离来进行代替，欧拉距离的值则为边界三角面的中点到终点三角面中点的距离。
接下来我们需要对地图顶点数据进行处理，将顶点数据中与建筑物投影存在交集的顶点过滤出来，然后求出过滤后顶点数据组成的每个三角形的中心点，以及与这个三角形相邻的三角形列表（neighbours） 以及他们的邻边数据（portals）。
最后我们传入起点和终点数据，A-Star 算法会根据起点数据和终点数据找到这个点所在的对应的三角形面数据，然后从起点三角形出发，根据其相邻三角形所对应的代价值进行寻路，直至找到终点三角形后，返回路径数据（paths）。
最后，我们通过让人物沿着返回的路径数据进行相应的移动，即可达到对应的避障效果。
实际应用下的优化
其实到此为止，我们已经基本实现了沙盒游戏的寻路算法了，但是在测试过程中我们发现，由于得到的路径经过了太多的三角形节点，导致人物在行走过程中出现了过多的拐点，且一些三角形之间的路径明显可以通过一条直线来表示，但是实际上中间却需要经过许多三角形的中点。
因此，我们引入了拉绳算法，通过拉绳算法解决路径拐点太多的问题，在这里就不过多介绍拉绳算法了，有兴趣的可以通过文章拉绳算法之漏斗算法来进行了解。
通过加入拉绳算法后，人物行走的路径也得到了优化，最后产生的实际效果也基本与理想效果达到一致了。
后续的待优化项
目前我们的寻路算法其实并不是我心目中的最优解。因为在本次导航网格的生成过程中，由于我们把整张地图都抽象成网格的形式，导致图的节点太多，在地图较大的情况下遍历起来会非常低效。
因此我们需要把网格地图简化成节点更少的路标形式（Waypoints），去对导航网格中一些不必要的点和面，对他们进行删减和合并。
另外，我们还能加入八叉树的概念，在三维空间中利用 x, y, z 轴将空间划分为 8 个部分，来优化查找效率。
鉴于文章的篇幅，这里就不对这些内容进行过多的展开了，希望读者秉持着好学的心态，自己在读后继续进行深入的研究。