3D 沙盒遊戲之避障踩坑和實現之旅

背景

最近在實現一個 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 進行三角形化，將它劃分成多個三角形，生成我們最後搜索算法需要用的導航網格。