最佳化導覽效能

常見的導覽相關效能問題可分為以下幾類：

• 解析場景樹節點以進行導覽網格烘焙時的效能問題。

• 烘焙實際導覽網格時的效能問題。

• NavigationAgent 路徑查詢的效能問題。

• 實際路徑搜尋的效能問題。

• 同步導覽地圖時的效能問題。

以下章節將說明如何識別並修正這些問題，或至少減輕它們對影格率的影響。

解析場景樹節點的效能問題

小訣竅

建議使用邊緣數量盡量少的簡單形狀，例如避免使用圓形、球體或甜甜圈等曲面。

建議以物理碰撞形狀取代複雜的視覺網格作為來源幾何，因為網格需要從 GPU 複製，且細節通常遠超所需。

一般來說，避免使用過於複雜的幾何作為烘焙導覽網格的來源。例如，切勿使用細節極高的視覺網格，因為將其解析為資料陣列並體素化以進行導覽網格烘焙會花費大量時間，且對最終導覽網格品質幾乎沒有提升。建議改用非常簡化的細節等級，甚至使用像方塊、矩形等原始形狀，只需大致覆蓋同樣的幾何範圍，就能產生足夠好的路徑規劃效果。

導覽網格烘焙時，請優先選擇簡單的物理碰撞形狀作為來源幾何。物理形狀預設就是精簡且最佳化的，解析速度快、效率高。反之，視覺網格的複雜度落差很大。特別是，解析視覺網格資料時，系統需從 RenderingServer 請求網格資料陣列，因為這些資料直接儲存於 GPU，並未快取於 CPU。這會造成 RenderingServer 執行緒鎖定，若渲染運作於多執行緒時，會嚴重影響運行時影格率；若為單執行緒，效能影響更明顯，解析複雜網格時甚至可能讓整個遊戲卡住數秒。

導覽網格烘焙的效能問題

小訣竅

執行時如需烘焙導覽網格，請務必使用背景執行緒。

將 NavigationMesh 的 cell_size 和 cell_height 調高，可以減少產生的體素數量。

將 SamplePartitionType 從 watershed 改為 monotone 或 layers，可以提升烘焙效能。

警告

切勿用節點縮放來源幾何，以免產生精度誤差。大多數縮放僅影響視覺效果，若物件本身極大，即使縮小後仍需大量額外處理。

運行時進行導覽網格烘焙，應盡可能在背景執行緒完成。即使是小型導覽網格，也可能需要花費超過單一影格可容納的時間，特別是在必須維持流暢影格率時。

從場景樹節點解析的來源幾何資料複雜度會大幅影響烘焙效能，因為所有資料都需對應到格線或體素。在運行時，建議將 NavigationMesh 的 cell size 與 cell height 設定得儘量大，只要不影響遊戲導覽網格的品質即可。若 cell size 或 cell height 設定過小，烘焙過程會被迫產生大量體素來處理來源幾何。若來源幾何涵蓋極大遊戲世界，甚至可能導致烘焙時記憶體耗盡而當機。Partition type 也可依據來源幾何複雜度調整，例如多為平坦、方塊狀幾何的遊戲，可以採用 monotone 或 layers 模式，烘焙速度更快（如無需距離場處理）。

切勿用節點縮放來源幾何。這不只會導致頂點與邊緣對齊錯誤產生精度誤差，且部分縮放僅作用於視覺，並未反映於實際解析資料。例如你在編輯器將 MeshInstance 的 scale 設為 0.001，雖然畫面很小，實際烘焙時仍需處理極大且複雜的體素網格。

NavigationAgent 路徑查詢的效能問題

小訣竅

在 NavigationAgent 腳本中，避免每一影格都重設或查詢路徑。

避免在同一影格內同時更新所有 NavigationAgent 的路徑。

自訂 NavigationAgent 腳本中的邏輯錯誤與多餘操作，是效能問題的常見主因。例如每影格重設路徑就是常見錯誤。預設情況下，NavigationAgent 只會在目標位置變動、導航地圖變更，或被迫偏離預期路徑距離過遠時才查詢新路徑。

例如，當 AI 需移動至玩家時，不應每一影格都將目標位置設為玩家座標，否則會每影格查詢新路徑。正確做法是：比較目前目標位置與玩家位置的距離，只有當玩家移動過遠時才設定新目標位置。

不要每一影格都檢查目標位置是否可到達。這種看似無害的檢查其實等同於進行昂貴的路徑查詢。如果本來就打算查詢新路徑，可直接查詢，然後只需檢查返迴路徑的最後一點與目標位置的距離，判斷是否「可到達」。這樣可避免同一 NavigationAgent 每影格進行兩次完整路徑查詢。

可將所有 NavigationAgent 分組更新，或用隨機計時器，使它們不會在同一影格同時請求新路徑。

實際路徑搜尋的效能問題

小訣竅

若導覽網格過度細緻，請減少多邊形與邊的數量以提升效能。

實際路徑搜尋的運算成本與導覽網格的多邊形數量與邊數直接相關，而非遊戲世界的大小。若龐大遊戲世界僅用少量大面積的多邊形作為導覽網格，效能通常可接受；反之，若世界被分割成許多極小的網格（例如 TileMap），尋路效能會大幅下降。

常見問題之一是，當查詢路徑時目標位置不可達，效能會突然下降。這其實是「正常」現象，原因是導覽網格過大且未優化，需遍歷過多多邊形與邊。若可快速抵達目標，尋路會提前結束，暫時掩蓋優化不足的問題；若目標不可達，系統必須遍歷所有多邊形才能確認，導致效能急劇下滑。

導覽地圖同步的效能問題

小訣竅

盡量透過頂點合併導覽網格的多邊形，而非僅以邊連接合併。

如對導覽網格或區域進行更動時，NavigationServer 需同步導覽地圖。依網格複雜度，這可能相當耗時，進而影響影格率。

NavigationServer 會以頂點或邊連接的方式合併導覽網格。當兩個不同邊的頂點落於同一地圖格時，會進行頂點合併，這是快速且低成本的操作。尚未合併的邊則在第二階段進行邊連接合併，會根據距離與角度檢查所有自由邊，這步驟相對耗時。

除了盡量減少多邊形邊數的原則外，也應盡可能預先以頂點合併多邊形，只留下極少數邊交給耗時的邊連接合併。可使用偵錯導覽效能監視器（Navigation PerformanceMonitor）檢查多邊形、邊的數量，以及未合併或未經頂點合併的比例。若頂點合併與邊連接的比例失衡（應以頂點合併為主），代表導覽網格建立或擺放方式極為低效。