翻譯自: http://www.critterai.org/projects/nmgen_study/config.html

參考: http://blog.csdn.net/kun1234567/article/details/41714511

　　 其他各處記不清了,不一一列出

說明: 英語水平有限,僅限於翻譯原網頁,並參考了以上作者的翻譯,加以整理,並沒添加過多的個人經驗.(後面會有些個人經驗說明),由於理解可能出現偏差,建議對照原英文文檔參閱

一. 總覽

二.詳細

CellSize

限制: > 0

說明: cellSize是最核心的參數,會影響幾乎剩下所有的參數的效果

構成x/z平面的體素場

較低的值可以更加貼近原Mesh，但會導致更高的處理和內存消耗

有時可能會發現尋路網格沿著障礙物邊緣的會出現一些不期望的較大邊距，或者尋路網格與同一個物體的不同邊有不同的邊距。這是尋路網格生成過程中的一個固有行為。尋路網格中的頂點被限制在x/z平面內體素的頂點上，因此cellSize確定的體素越大，這種誤差越大。這是由於cellSize確定的體素的分辨率決定的，是無法去除的，除非cellSize可以無限小，體素可以無限小的細分原Mesh

[低分辨率下：尋路網格與原Mesh偏差offset,在兩邊不相同，左邊偏差明顯大於右邊]

[高分辨率下,兩邊的偏差並沒有明顯差別]

CellHeight

限制: > 0

說明: cellHeight也是一個核心參數,影響幾乎剩下所有的參數的效果, minTraversableHeight, maxTraversableStep, contourMaxDeviation應該大於cellHeight才能保證效果正常. maxTraversableStep的效果受cellHeight取值的影響十分明顯.

對原Mesh進行采樣時采用的高度分辨率.是x/z平面確定的體素場的體素高度

cellHeight采用原Mesh的y軸方向

cellHeight取值較小時生成的尋路網格更貼近原Mesh,並且會導致更高的處理耗時,但是並不會明顯增加內存消耗.

[cellHeight和體素場的關系,可以看到,體素場是x/z屏幕的cellSize確定的,cellHeight是確定體素的高度的,即y軸,cellHeight值的大小確定了尋路網格對原Mesh在高度y軸方向的采樣精度]

CellHeight和CellSize一起,控制了尋路網格上頂點的位置

最終生成的尋路網格將依據確定原Mesh形狀的體素的頂部來生成,而不是原Mesh.也就是,尋路網格是覆蓋在根據原Mesh得到的體素場的上表面上的.體素場即x/z平面確定了尋路網格的有無,而在(x,z)處出現的y方向的所有體素的CellHeight確定了尋路網格的高低.

因此尋路網格的頂點的y坐標是由體素的CellHeight確定的

即CellHeight越大,尋路網格上的頂點和原Mesh的y軸偏差越大.

[cellHeight越大,原Mesh采樣的高度分辨率越低,尋路網格和原Mesh在y軸的偏差越大]

minTraversableHeight

限制: > 0

說明: minTraversableHeight應該大於等於2倍的CellHeight,來達到最佳效果

控制可以通過的最小高度

判斷一些有頂的區域是否可以通過,比如城門,橋洞,避免過矮的地方可以通過,如桌子下面.

用來檢查上方Mesh和下方Mesh的高度差,將高度差距過小的地方設置為不可行走.也可以被認為是agent的最大高度.

[minTraversableHeight設置恰當時,桌子底下不生成網格]

[minTraversableHeight設置太小時,桌子底下生成了網格]

[minTraversableHeight設置過大時,陽臺下方的房間沒有生成網格]

maxTraversableStep

限制: >= 0

說明: maxTraversableStep應該大於2倍的cellHeight

(maxTraversableStep > cellHeight * 2), 否則體素場的分辨率將不足以準確的檢測到可行走的高度偏差,導致高度偏差被合並,使得臺階的高度被顯著的加倍,特別是樓梯這種地方,會出現明顯的問題

控制可通過的最大的凸起高度

防止輕微的高度偏差被識別為障礙物。用來檢測樓梯狀結構，路緣石等.

避免一些小凸起的地方被認為不可走,例如地面上的一層石板,樓梯臺階等.

[恰當的取值,可以正確的在樓梯上生成尋路網格]

[取值過小,導致樓梯區域被認為是不可行走. Agent無法攀爬樓梯臺階的高度]

[設置數值過大,導致尋路網格可以爬上桌面,導致Agent可以直接走到桌子上]

maxTraversableSlope

限制: >= 0

最大可行走的坡度(以度為單位)

[合適的取值,可以在斜坡上生成尋路網格]

[取值過小,使得斜坡上無法生成尋路網格]

ClipLedges

限制: 無

邊緣突出部分裁剪,確定突出邊緣是否可走

如果traversableAreaBorderSize > 0 則邊緣部分的邊距會比其他地方更寬,因此如果使用了traversableAreaBorderSize參數,一般並不需要邊緣裁剪這個參數了.

traversableAreaBorderSize

限制: >= 0

說明: traversableAreaBorderSize取值必須大於cellSize,才能生效.

當開啟了clipLedges時,實際邊距會更大.

當smoothingThreshold > 0時,實際的邊距會更大

控制尋路網格距離原Mesh障礙物的最小邊距.

通常該值被設置為Agent利用尋路網格進行尋路的最大邊界半徑

比如Agent自身有寬度,則Agent在尋路時需要考慮自己的寬度(胖瘦),則尋路網格在靠近障礙物生成時的邊距,需要預留出來Agent的寬度,這樣Agent在尋路網格上移動和尋路時才不會和障礙物之間發生重合.

[設置border > 0時,尋路網格和樓梯墻壁之間產生邊距.]

[設置border = 0時,尋路網格和樓梯墻壁之間緊密的貼合,剩下的 間隙是由體素的分辨率導致的]

SmoothingThreshold

限制: >= 0

當生成用於導出區域的距離場時要執行的平滑量

該參數控制區域的形成和邊距檢測,一般來說,該參數取值越大,生成的區域越大,生成的瘦長三角形越少,尋路網格與原Mesh的邊距越大,當該參數=0時,將關閉平滑處理

[SmoothingThreshold = 0時,會出現更多的細長三角形]

[SmoothingThreshold = 2時,三角劃分效果較好]

如上面描述提到的,SmoothingThreshold會導致網格邊距增大,哪怕是將traversableAreaBorderSize 設置為0,也就是SmoothingThreshold會顯著放大traversableAreaBorderSize 的效果.

[SmoothingThreshold = 0時,網格邊距由traversableAreaBorderSize 定義,效果符合期望]

[traversableAreaBorderSize 取值不變時, SmoothingThreshold = 2,網格出現較大的邊距]

隱含的問題: 當SmoothingThreshold取值過大時,會出現畸形的區域, 導致三角測量和輪廓匹配失敗, 測試發現,當SmoothingThreshold > 4時會出現問題。

該問題出現在區域生成階段,如果區域處本來沒有邊距,平滑的邊距處理會導致區域變的畸形.

一般來說, SmoothingThreshold不會設置為>2,若出現該問題,可以設置traversableAreaBorderSize > 0 或者降低SmoothingThreshold

UseConservativeExpansion

限制: 無

使用保守的區域擴張算法,用來規避畸形區域的生成.

如果尋路網格缺少一些應有的部分,開啟該特性可能會解決這個問題

開啟該特性會顯著增加處理耗時

這個特性在Recast中沒有,不確定這個功能所涉及的問題,是否也存在於Recast中

[不開啟保守區域擴展算法時,區域沿著兩列生成{?},這導致三角劃分算法無法對非簡單多邊形進行最終完全劃分,導致一些區域無法生成尋路網格]

minUnconnectedRegionSize

限制: > 0

未連接的,獨立的區域的最小尺寸.

該取值是以體素為單位的.

一些不和其他區域相連的尋路網格,如果其尺寸小於該值,會被剔除.比如一些屋頂或者巖石的表面,這些區域一般來說是很零散的,尺寸都不大,一般是不可以尋路的,不需要生成網格,該參數合理的取值會避免在這些無謂的區域生成尋路網格.從而優化網格,提升效率.

[該參數合理的取值,使得桌子上面沒有生成網格.不可尋路]

[該參數取值過小,導致桌面出現網格]

mergeRegionSize

限制: >= 0

當一些區域的尺寸小於此參數時,如果可以,會和較大區域合並.

取值以體素為單位

該參數可以幫助減少一些尺寸較小的區域

由於區域生成算法的固有錯誤,會產生一些不期望的小區域.這在三角路徑區域劃分時,更為明顯.

如果小區域無法被合並到臨近的區域,則這些小區域會被保留,不會改變.比如合並後會導致非簡單多邊形等原因導致無法合並.

[該參數取值過小,產生了一些細長三角形]

[該參數取值足夠大,一些細長三角形被合並,網格有更少的細長三角形]

maxEdgeLength

限制: >= 0

表示尋路網格的多邊形邊的最大長度。

如果網格中多邊形的某些邊的長度超過該參數,會在邊上增加頂點以劃分過長的邊.

在一些情況下,會減少出現細長的三角形

[該參數取值為0時,禁用該特性,三角形邊長較大]

[該參數合理取值,會在較長邊上增加頂點,將較長邊劃分為多個短邊]

edgeMaxDeviation

限制: >= 0

尋路網格多邊形的邊偏離原Mesh的最大偏移量

更小的取值會使得尋路網格更加貼近x/z平面的原Mesh邊緣.這會顯著的增加三角形的數量以更加精細的貼近原Mesh,也會顯著的增加處理耗時

當取值=0時,會導致尋路網格中多邊形的數量大量增加,以及較高的處理耗時.這是不建議的.

[邊緣匹配完全關閉時,尋路網格的邊與原Mesh之間偏差很大]

[適度的邊緣匹配參數取值,尋路網格較好的匹配原Mesh的邊緣]

[邊緣匹配參數取最大值時,尋路網格十分緊密的貼合原Mesh,但是尋路網格上增加了大量的多邊形]

maxVertsPerPoly

限制: >= 3

在體素到多邊形轉換過程中生成的多邊形中每個多邊形的最大頂點數

較大的取值會導致較高的處理耗時,但是會在尋路網格上生成較好的多邊形.

一般取6左右的值即可,更高的取值,收效遞減

contourSampleDistance

限制: >= 0

設置尋路網格的細節網格與原Mesh表面匹配時的采樣距離

影響細節網格對原Mesh表面輪廓的匹配程度.較高的取值,會使得尋路網格的邊緣與原Mesh的邊緣匹配的越精細,越貼近.同時會導致尋路網格上出現更多的三角形和更高的處理耗時

說明: contourSampleDistance(輪廓匹配)和edgeMaxDeviation(邊緣匹配)的區別是:輪廓匹配是在y軸上和原Mesh進行近似匹配,輪廓匹配將整個尋路細節網格的表面和原始Mesh的輪廓進行匹配.而邊緣匹配只拿尋路網格的多邊形的邊和原始Mesh的輪廓進行匹配.(即輪廓匹配是整個尋路網格面對原Mesh的抽樣近似,而邊緣匹配只是尋路網格上多邊形的邊對原Mesh的抽樣近似.所以,輪廓匹配更加細致)

當取值 < 0.9 時,該參數不生效.

[輪廓匹配關閉,邊緣匹配適度時,尋路網格邊緣部分貼近原Mesh的邊緣,但是尋路網格的中間部分相對於原Mesh不夠精細]

[輪廓匹配和邊緣匹配都取適當值時,尋路網格的中間區域也有了更多三角形]

[輪廓匹配取值較高,邊緣匹配取值適度時,尋路網格內部出現了非常多的三角形]

contourMaxDeviation

限制: >= 0

尋路網格的細節網格偏離原Mesh表面的程度

該參數的準確性受contourSampleDistance的影響

如果contourSampleDistance = 0 則該參數無效

當取值=0時,會導致尋路網格中多邊形的數量大量增加,以及較高的處理耗時.這是不建議的

效果可以參考contourSampleDistance

三. 其他補充

1. 根據對Unity NavMesh的分析,發現Unity使用的NavMesh烘培參數要和Recast提供的默認參數差別很大,因此如果單純的按Recast的參數範圍調節,很難達到Unity的精細度,另外,參數調節一定要慎重分析其對其他參數的影響

這篇博客意在通過分析CritterAI來對照Recast的參數.以便更好的理解Recast,但是兩者參數並不完全一致.

2. 盡可能的減少瘦長三角形,由於瘦長三角形夾角過小,計算機數據類型精度限制,容易導致尋路路徑產生奇怪的彎曲.(Unity的NavMesh尋路算法在Recast基礎上進行了很大的修改)

參考: http://www.cnblogs.com/yaukey/p/recastnavigation_unity_optimize_visible_result.html

參考: <<3d數學基礎 圖形與遊戲開發>>

3. 註意網格參數精細度和性能之間的平衡,如果過分追求精細度,有可能導致尋路路徑點過多,達到Recast限制

若有補充感謝補充

文章錯誤,請務必指出,以免誤導他人,十分感謝

CritterAI 翻譯 Configuration Parameters