一種接近最優的導航網格生成算法以及基於導航網格的尋路算法
關鍵詞：導航網格、A*尋路、3D環境中的尋路
提出背景：
長距離尋路會出現掉幀現象，爲了提高尋路速度，併爲3D環境中的尋路方案提供基礎算法實現。
目前狀況：
由於3D遊戲對幀率要求很高，而在遊戲中進行一次長距離的尋路可能要花費8-10幀的時間，在地圖複雜的情況下尋路時間甚至可能會更嚴重，而在這段時間，渲染循環會暫停渲染並等待尋路結果。會給玩家帶來不流暢的操作體驗。
特別是3D遊戲中地圖比較複雜，地圖規模比較大，對於一張600*600的地圖，尋路的搜索空間的節點數目有可能達到數十萬之多，這給傳統的A*尋路算法提出了挑戰，如果地圖比較複雜，直接在這些節點上直接尋路的時間可能會以秒來計算。
解決方案：
解決上述問題的方法，可以通過生成導航網格來減少尋路算法的搜索空間。這也是3D世界中最常用的尋路解決方案。
常見的導航網格生成方法有兩種，一種是通過手工創建，這需要專門的人員很細心的花費一定的時間來創建。另外一種是通過程序來自動生成，不過稍微複雜一點。這次創新採用了自動生成導航網格的方法。可以通過我們自己的AStarExplore工具，在不改變現有資源的情況下自動生成導航網格。
DK Online 中楓林片區地圖爲例，可通過節點55616個，如下圖：
上圖爲一張435*310的地圖，可通過節點55616個
通過我們自己的工具自動生成的導航網格(不需要人工手動創建)，可通過尋路節點僅爲2238個，生成算法採用了Hertel-Mehlhorn算法和3-2Merging算法。
自動生成的導航網格。節點數爲2238個
生成結果顯示：可通過節點由原先的55616個節點合併成爲了2238個節點。大大減少了尋路時的搜索空間，爲更快，更遠的路徑搜索提供了可能性。
3D空間中的導航網格
A*尋路優化：
1、 內存優化：
尋路中，搜索路徑耗費的時間並不是最主要的損耗，而是尋路開始時的內存重置，或者是內存的不斷分配和釋放。由於節點數目的減少，在尋路之前就建立了節點的數組（只佔用100-200K內存），使用一個bool的一維數組來標識這些節點是否被搜索過，每次尋路結束之後只需重置這個bool數組即可。
2、 使用二叉堆優化Open表：
使用二叉堆可使最優的節點一直處於堆的頂部，而不用消耗太多的時間在對Open表的排序上，或者遍歷Open表查找最優節點上。
一次中短距離尋路對比：
遊戲中實際距離如圖A到B的距離。
掩碼尋路結果 導航網格尋路結果
掩碼尋路耗費時間 導航網格耗費時間
通過對比：一次中短距離的基於原始節點的尋路，尋路時間爲1.615ms，遍歷節點數284個。而一次基於導航網格的尋路，遍歷節點僅爲58個，尋路時間只有0.0711毫秒。
一次中距離尋路對比：
遊戲中實際距離如圖A到B的距離。
實際尋路時間：
掩碼尋路結果 導航網格尋路結果
通過對比：一次中距離的基於原始節點的尋路，尋路時間爲69ms，遍歷節點數8393個。而一次基於導航網格的尋路，遍歷節點僅爲522個，尋路時間只有0.38毫秒。
一次長距離的尋路對比:
遊戲中實際距離如圖A到B的距離，尋了一個對角長度。
掩碼尋路結果 導航網格尋路結果
通過對比：一次長距離的基於原始節點的尋路，尋路時間爲468ms，遍歷節點數46636個。而基於導航網格的尋路，遍歷節點僅爲2198個，尋路時間只有1.604毫秒。
擴展：
由於生成導航網格的算法是完全基於3D空間的多邊形，可將此算法應用到場景面片當中，生成基於實際場景的導航網格，從而可實現分層尋路。如下圖。
參考文獻：參考《Ai Game Programming Wisdom》中《建立接近最優的導航網格》文獻。
採用了Hertel-Mehlhorn算法和3-2Merging算法建立接近最優的導航網格。
Hertel-Mehlhorn算法
3-2Merging算法
尋路算法仍然採用A*算法，但搜索空間變成了導航網格。啓發函數的計算公式有所改變。
G值 = 穿入邊中點與穿出邊中點的距離。
H值 = 多邊形中點到目標點的直線距離。
F值 = G值 + H值。