Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
最佳化導覽效能
常見的導覽相關效能問題可分為以下幾類：
解析場景樹節點以進行導覽網格烘焙時的效能問題。
烘焙實際導覽網格時的效能問題。
NavigationAgent 路徑查詢的效能問題。
實際路徑搜尋的效能問題。
同步導覽地圖時的效能問題。
以下章節將說明如何識別並修正這些問題，或至少減輕它們對影格率的影響。
解析場景樹節點的效能問題
小訣竅
建議使用邊緣數量盡量少的簡單形狀，例如避免使用圓形、球體或甜甜圈等曲面。
建議以物理碰撞形狀取代複雜的視覺網格作為來源幾何，因為網格需要從 GPU 複製，且細節通常遠超所需。
一般來說，避免使用過於複雜的幾何作為烘焙導覽網格的來源。例如，切勿使用細節極高的視覺網格，因為將其解析為資料陣列並體素化以進行導覽網格烘焙會花費大量時間，且對最終導覽網格品質幾乎沒有提升。建議改用非常簡化的細節等級，甚至使用像方塊、矩形等原始形狀，只需大致覆蓋同樣的幾何範圍，就能產生足夠好的路徑規劃效果。
導覽網格烘焙時，請優先選擇簡單的物理碰撞形狀作為來源幾何。物理形狀預設就是精簡且最佳化的，解析速度快、效率高。反之，視覺網格的複雜度落差很大。特別是，解析視覺網格資料時，系統需從 RenderingServer 請求網格資料陣列，因為這些資料直接儲存於 GPU，並未快取於 CPU。這會造成 RenderingServer 執行緒鎖定，若渲染運作於多執行緒時，會嚴重影響運行時影格率；若為單執行緒，效能影響更明顯，解析複雜網格時甚至可能讓整個遊戲卡住數秒。
實際路徑搜尋的效能問題
小訣竅
若導覽網格過度細緻，請減少多邊形與邊的數量以提升效能。
實際路徑搜尋的運算成本與導覽網格的多邊形數量與邊數直接相關，而非遊戲世界的大小。若龐大遊戲世界僅用少量大面積的多邊形作為導覽網格，效能通常可接受；反之，若世界被分割成許多極小的網格（例如 TileMap），尋路效能會大幅下降。
常見問題之一是，當查詢路徑時目標位置不可達，效能會突然下降。這其實是「正常」現象，原因是導覽網格過大且未優化，需遍歷過多多邊形與邊。若可快速抵達目標，尋路會提前結束，暫時掩蓋優化不足的問題；若目標不可達，系統必須遍歷所有多邊形才能確認，導致效能急劇下滑。