Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

最佳化建置檔案大小

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

• Performance problems with parsing scene tree nodes for navigation mesh baking.

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

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

• 實際路徑搜索的性能問題。

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

在以下部分中可以找到有關如何識別和修復或至少減輕其對影格速率的影響的資訊。

Performance problems with parsing scene tree nodes

小訣竅

喜歡使用邊緣盡可能少的簡單形狀，例如，不要像圓形、球體或圓環那樣呈圓形。

優先使用物理碰撞形狀而不是複雜的視覺網格作為來源幾何體，因為網格需要從 GPU 複製，並且通常比必要的詳細得多。

一般來說，避免使用非常複雜的幾何體作為烘焙導覽網格的來源幾何體。例如，永遠不要使用非常詳細的視覺網格，因為將其形狀解析為資料陣列並將其體素化以進行導覽網格烘焙將花費很長時間，而不會在最終導覽網格上獲得真正的質量增益。相反，請使用形狀的非常簡化的細節等級版本。更好的是，使用非常原始的形狀，例如盒子和矩形，它們僅大致覆蓋相同的幾何形狀，但仍然會產生足夠好的路徑搜尋烘焙結果。

喜歡使用簡單的物理碰撞形狀而不是視覺網格，作為烘焙導覽網格的來源幾何。預設情況下，物理形狀是非常有限且經過最佳化的形狀，可以輕鬆快速地解析。另一方面，視覺網格的範圍可以從簡單到複雜。最重要的是，為了存取視覺網格資料，解析器需要從渲染伺服器請求網格資料陣列，因為視覺網格資料直接儲存在 GPU 上，而不是快取在 CPU 上。這需要鎖定 RenderingServer 線程，並且在渲染以多線程運作時會嚴重影響運作時的影格速率。如果渲染運作單線程，影格率影響可能會更嚴重，並且網格解析可能會在複雜網格上凍結整個遊戲幾秒鐘。

烘焙導覽網格的性能問題

小訣竅

在運作時，總是更喜歡使用後台執行緒來烘焙導覽網格。

增加 NavigationMesh cell_size 和 cell_height 以建立較少的體素。

將“SamplePartitionType”從分水嶺更改為單調或分層以獲得烘焙性能。

警告

切勿使用節點縮放源幾何體以避免精度錯誤。大多數比例僅適用於視覺，即使縮小比例，在基本比例下非常大的形狀仍然需要大量額外的處理。

如果可能的話，在運作時烘焙導覽網格應該始終在後台執行緒中完成。即使是小尺寸的導覽網格物體的烘焙時間也可能比擠入單個影格所需的時間長得多，至少在影格率保持在可忍受的水平的情況下是如此。

Complexity of source geometry data parsed from scene tree nodes has big impact on baking performance as everything needs to be mapped to a grid / voxels. For runtime baking performance the NavigationMesh cell size and cell height should be set as high as possible without causing navigation mesh quality problems for a game. If cell size or cell height is set too low the baking is forced to create an excessive amount of voxels to process the source geometry. If the source geometry spans over a very large game world it is even possible that the baking process runs out off memory in the middle and crashes the game. The partition type can also be lowered depending on how complex the games source geometry is to gain some performance. E.g. games with mostly flat surfaces with blocky geometry can get away with the monotone or layers mode that are a lot faster to bake (e.g. because they require no distance field pass).

切勿使用節點縮放源幾何。它不僅會導致大量精確度錯誤（頂點和邊配對錯誤），而且某些縮放僅以視覺形式存在，而不存在於實際解析的資料中。例如，如果網格在編輯器中以視覺方式縮小，例如在 MeshInstance 上將比例設為 0.001，則網格仍然需要巨大且非常複雜的體素網格來處理烘焙。

NavigationAgent 路徑查詢的性能問題

小訣竅

避免不必要的路徑重設並查詢 NavigationAgent 腳本中的每一影格。

避免更新同一影格中的所有 NavigationAgent 路徑。

自訂NavigationAgent 腳本中的邏輯錯誤和浪費性操作是導致效能問題的常見原因，例如，請注意每影格重設路徑。預設情況下，NavigationAgents 經過最佳化，僅在目標位置變更、導覽地圖變更或被迫遠離所需路徑距離時查詢新路徑。

例如，當 AI 應移動到玩家時，目標位置不應每影格都設定為玩家位置，因為這會每影格查詢新路徑。相反，應該比較從目前目標位置到玩家位置的距離，並且只有當玩家移動得太遠時才應該設定新的目標位置。

不要預先檢查每個畫面是否可以到達目標位置。看似無害的檢查實際上相當於幕後昂貴的路徑查詢。如果計劃無論如何都要請求新路徑（如果位置可達），則應直接查詢路徑。透過查看返迴路徑的最後一個位置，如果該位置距檢查位置處於“可到達”距離，則它會回答“該位置是否可到達？”問題。這避免了對同一個 NavigationAgent 每影格執行兩次完整路徑查詢的等效操作。

將導覽代理程式的總數分割為更新組或使用隨機計時器，以便它們不會在同一影格中全部請求新路徑。

實際路徑搜索的性能問題

小訣竅

透過減少多邊形和邊的數量來優化過於詳細的導覽網格。

實際路徑搜尋的成本與導覽網格多邊形和邊緣的數量直接相關，而不是與遊戲世界的實際大小相關。如果一個巨大的遊戲世界使用非常優化的導覽網格，只有少數多邊形覆蓋大面積，那麼效能應該是可以接受的。如果遊戲世界被分割成非常小的導覽網格，每個導覽網格都有微小的多邊形（如 TileMap），則尋路效能將會降低。

一個常見問題是當路徑查詢中無法到達目標位置時效能突然下降。這種性能下降是“正常的”，是導覽網格太大、未優化的結果，需要搜尋大量多邊形和邊緣。在可以快速到達目標位置的正常路徑搜尋中，一旦到達該位置，尋路就會提前退出，這可以暫時隱藏這種優化不足的情況。如果無法到達目標位置，則尋路必須對可用多邊形進行更長的搜索，以確認該位置絕對無法到達。

導覽地圖同步的性能問題

小訣竅

合併導覽盡可能透過頂點而不是邊連接來網格化多邊形。

當對導覽網格或導覽區域進行變更時，導覽伺服器需要同步導覽地圖。根據導覽網格的複雜性，這可能需要大量時間，這可能會影響影格速率。

導覽伺服器透過頂點或邊連接合併導覽網格。當兩條不同邊的兩個頂點落在同一地圖網格單元中時，就會發生以頂點合併。這是一個相當快速且低成本的操作。對於所有尚未合併的邊，按邊連接進行合併發生在第二遍。透過距離和角度檢查所有自由邊緣是否有可能的邊緣連接，這是相當昂貴的。

因此，除了具有盡可能少的多邊形邊的一般規則之外，還應透過頂點預先合併盡可能多的邊，以便只留下少量邊用於成本更高的邊連接計算。偵錯導覽效能監視器可用於取得有關可用多邊形和邊的數量以及其中有多少未合併或未按頂點合併的統計資料。如果頂點合併和邊連接之間的比率相差很大（頂點應該明顯更高），則導覽網格會正確建立或放置得非常低效。