譯者：趙菁菁（軒語軒緣）  審校：李笑達（DDBC4747）

對於任何追求UE4效能最佳、同時又想保持極高質量視覺效果的人來說，本文有一些可遵循的一般性建議和原則。

侷限性

為了效能，你通常受CPU時間（通常和遊戲設定相關）和GPU時間限制（渲染場景花費的時間）。CPU建立由GPU渲染的場景會耗費一些時間。

通常情況下，當你發現遊戲的執行速度不像你想要的那麼快時，第一步是找出你現在受以上哪個環節的約束，然後確定需要修改的資源或設定來修正問題。UE4的一些內建工具就是為了實現這個目標而存在的，我建議好好掌握這些工具，特別是CPU和GPU分析器。

瞭解可用工具

控制檯指令

UE4中有很多可用工具，它們可以用來分析效能和幀率，許多工具採用控制檯指令形式，可用在控制檯輸入這些程式指令，控制檯可以在遊戲中通過按波浪鍵顯示，也可以在編輯器的顯示選單裡找到。這裡圈出的是幾個特別有用的指令（這些可以按“stat__”也就是“stat unitgraph”或者“stat fps”的形式在控制檯輸入）。

先是Stat的“Engine”組：

這裡讓我們仔細看看從“Detailed”Stat組得到的資訊（自動選中上面圈出的多數其他stat組）：

1.     這是當前幀率（每秒幀數）和幀時間（每幀毫秒數）。

2.     這是幀時間

a.      這被分解成兩組：

                                   i.          Frame（幀）：幀花費的總時間。

                                  ii.          Game（遊戲）：這是一個任意的CPU邏輯，它不與渲染直接關聯。如果該組很慢，通常的情況是程式設計師有需要修正的內容，但是它可以是與藝術相關的，比如：螢幕上有太多顆粒。內建在CPU分析器中的Frontend工具可以用來研究CPU效能並且觀察正執行緩慢程式碼。特定的、與複雜任務相關的遊戲設定只能在CPU上執行，像A.I.和Navigation的設定。

                                iii.          Draw（繪圖）：這是一個與GPU上渲染設定相關的CPU邏輯。它包括圖形API和繪圖呼叫的設定，或者如果渲染程式碼已經以非最佳的方式修正了，它就可能與渲染程式碼相關。

                                iv.          GPU：GPU渲染幀花費多長時間。它包括：執行圖形API呼叫、繪圖呼叫、著色器和後過程著色器的執行、獲取紋理……這裡的問題通常與資源相關，它可能是場景中類似著色器這樣非常複雜的東西，或者場景中有許多不同的網格，結果就是每幀中發生太多的繪製呼叫。這可能會讓一個專業美工或程式設計師找到問題根源，但是通常情況下需要一些決策——為了達到預期效能，應該做哪些藝術權衡。這裡能幫到您的最棒的工具是GPU分析器和著色器複雜性檢視，這些會在之後進行討論，同時下面還會討論“Advance”目錄中顯示的特定stats。

b.      這裡有兩個度量

                                   i.          第一個是這個幀的當前幀時間（左）

                                  ii.          第二個是在最後幾秒的最差幀時間（右）

c.      注意GPU和CPU（遊戲&繪製）是同時執行的，所以幀花費的總時間不是它們時間的總和，但是任一項拖了後腿都可能是幀率降低的原因。

3.     這是遊戲、繪圖和GPU的幾個幀裡的幀時間圖。

4.     這是圖中的峰值——當一個特定過程（遊戲、繪圖或者GPU）的執行花費了很長時間時。它用毫秒標記了那個頂峰的最慢幀的時間。

這也是stats的一個“Advanced”組，它有更詳細的內容需要說明。

在“Advanced”組中的大多數項是特別針對像Lighting或者AI Behavior這樣特定系統的，所以這樣的系統也包含專門針對“Advanced”組的stats。這裡讓我們看一些特殊興趣點的例子：

場景渲染指令和繪製呼叫

場景渲染是特別方便的，因為它顯示了你的場景中繪製呼叫發生的次數，取決於你的繪圖API，這可能是一個極其重要的數字（例如：在手機OpenGL平臺上，繪製呼叫代價太高了以至於開發者經常將大多數的環境併入一個靜態網格中來讓它作為一個單一的繪製呼叫）。

初始檢視指令和選擇

在驗證場景剔除時這個stats組很有用。“剔除”就是當你選擇性地不執行或渲染部分場景，這些場景當前檢視中不會使執行加速。通過參考Frustum Culled初始量值，你可以檢視渲染系統決定不繪製的初始量的數量，因為這些量是不可見的。相反，可見的動態初始量部分顯示了被定義為可見初始量的數量。

另一個視覺化的方式就是使用除錯攝像頭，你可以在玩遊戲的時候通過控制檯命令“ToggleDebugCamera​  ”轉至除錯攝像頭。在那裡，如果你點選“F”鍵來停止渲染並且把除錯攝像頭移到另一個角度，你可以清晰地看到哪個初始量被渲染了、哪些被修改了。

在上面的螢幕截圖中你可以看到預覽視窗中的角色攝像的原始檢視，該檢視是在Play模式中通過在場景大綱中選擇攝像頭呈現的。ToggleDebugCamera用來停止渲染，在移動攝像頭到另一邊檢視剔除的初始量時，要保證攝像位置的剔除是穩定的。

效能視覺化工具

線框檢視模式可以告訴你場景和獨立網格中有多少頂點和三角形，要實現這個模式，你可以在編輯器等級視口的視覺化模式選單中找到，或者在遊戲執行期間按F1鍵，或者在控制檯輸入“viewmode wireframe”命令：

如果你的網格有三角形/頂點的富餘，而且遠比攝像頭的充足時，線框就會變成實線。如果你的網格不總是實線的，這意味著你有可能需要比渲染更高的複雜性，你就應該減少網格中的多邊形數量。

著色器複雜性視覺化

當你的場景中存在很多材質時，可能很難確定哪些是複雜的。幸運的是，UE4中有一個內建檢視：著色器複雜性。通過編輯器關卡視窗中的視覺化模式選單可以找到它，還可以在遊戲執行時通過按F5找到它，或者進入“viewmode shadercomplexity”控制檯指令：

這裡的暗綠色區域比淺綠色區域含有更復雜的著色程式邏輯，紅色和白色區域也仍有更加複雜的著色邏輯。著色複雜性最大的原因通常是：當多重透明材質重疊時，需要為所有重疊區域計算著色。

當你已經確定了一個紅色區域，你可以右擊物件來編輯那個角色，在這種情況下——一個靜態網格：

從這個靜態網格編輯器中，你可以在Details面板中看到網格正使用的材質：

單擊放大鏡就可以在內容瀏覽器中選擇材質資源，你可以雙擊它來開啟材質編輯器：

在材質編輯器中，你可以推動stats按鈕來開啟stats的材質標籤。在這裡你可以看到材質對應的著色器的說明數量。但是說明數量不是與效能的影響一一對應的（因為一些說明比其它更昂貴）了，於一個材質的複雜度來說，說明的總數是一個很好的表徵，總體來講，減少說明的數量可以產生更好的效能。

著色器在其它領域的效能也可以是受約束的——如紋理快取。如果你在你的材質中用了許多紋理，那麼就可能沒有足夠的空間來立刻將它們寫入快取，所以它們最終會被調入、調出記憶體，這樣是非常慢的。因為這個原因，有可能的話最好減少每個材質的紋理取樣器。在材質編輯器的stats視窗和說明數量中，你可以看到材質目前正使用的紋理取樣器的數量。

另一方面，著色器在紋理檢查中效能也受約束。比如說如果你正在使用一個大型紋理，但是它距離攝像頭很遠，相對只有一小部分紋理是會被取樣的，但是為了給它取樣，要讀比實際用到的多得多的紋理。這裡錐形紋理技術（mip map）就起作用了，因為錐形紋理在紋理的連續區域內包含的紋理更小，所以只有紋理的小得多的部分需要被讀入來得到取樣。這樣一來，保證在所有紋理中充分利用錐形紋理技術是很重要的。

光線複雜度檢視模式

光線複雜度檢視模式​ 顯示了影響你的幾何圖形的非靜態光線的數量，它可以通過編輯器等級視口的視覺化模式選單得到，或者在遊戲執行中按F9鍵：

這對於追蹤光線代價是很有用的——光影響外觀越多，它產生陰影的代價就越大。

一個光線可以被剔除的方式有很多，包括半徑削減、z型交叉、攝像頭背對光源、光函式是0等等，所以光會在不同陰影中出現是非常有可能的。光線複雜度檢視模式在將代價與顏色亮度聯絡起來的方面是做得最好的。

減少半徑削減或者光線的錐形角度可能會有幫助。打光效能是非常依賴角度的，所以它極大程度上取決於玩家的攝像頭在哪裡，由於這個原因，最好在不同角度研究光復雜度。

靜止光線重疊檢視模式

靜止光線重疊檢視模式用紅色顯示了哪些靜止光線正被迫移動。

靜止光線一次最多隻允許4次重疊。一旦你有了大於等於5個的靜止光線重疊，擁有最小半徑的那個靜止光線會開始投射動態陰影，這會產生很高的效能代價。

其他Stats檢視

在Window>Statistics選單中有一些其他統計資料檢視：

紋理Stats

這個工具顯示了在當前關卡下使用的所有紋理，它們的解析度、使用次數和遊戲中出現的時間。如果你的場景中有高解析度的紋理並且沒有被很多使用次或者不常見，它們不僅會佔據很多不必要的記憶體，而且也會造成GPU處理緩慢，增加GPU渲染場景花費的時間。

初始量Stats

這裡你可以看到許多有用資訊，開始是在你的骨骼網格、靜態網格和場景中有多少三角形初始量。如果你在你的場景中定義了一個物件，它的三角形數量很多，試著線上框層次上觀察這個角色。

視覺化用來觀察線框在一個正常的觀察距離外是否保持著實線（或接近實線），這意味著在你的網格中你有比你需要的更多的細節，你可以使用DCC工具或者UE4支援的網格簡化工具來減少網格中的頂點數量。

初始量Stats檢視也包括數量，這個數量是在當前關卡上使用的數量；還包括例項部分，就是網格中類似著色器和繪製呼叫這樣的元素的數量，主要就是繪製這個物件例項複雜度的度量。如果兩個值數量值很高（在你的關卡設定了許多相同物件），例項部分值也很高（物件渲染複雜），那麼這可能導致渲染時大量的繪製呼叫或者圖形API狀態發生變化，這會顯著增加GPU渲染場景的時間。基本上，如果數量×例項部分與場景中其他物件相比是一個相對大的數，這個物件就是應該優化的區域。達到這個目標的一個潛在方法是把單一角色用高多邊形數量分解成多個角色，允許他們被單獨選擇，因此你就有機會一次性繪製比整個多邊形數量少的影象了。但是這主要只對CPU載入有影響，所以如果你的遊戲不是CPU受限的，那麼最好把你的優化時間集中在其它任務上。

只有一種不適用的情況：當使用例項化的靜態網格特徵時，你可以使用這個特徵在你的關卡周圍設定許多相同靜態網格的拷貝，但是在渲染時應把它們合併為一個單獨的繪製呼叫。這可以提升效能，但也意味著那些網格不能被單獨選擇，所以如果它們中的任何一個在螢幕上可見，它們都會被渲染。

分析器 

也許在優化效能時應該熟悉的兩個最重要的工具是CPU分析器和GPU分析器。

CPU分析器

CPU分析器作為一個獨立應用執行，可以從Session前端或者Unreal前端獲取到，Session前端可以在Unreal編輯器的視窗選單中找到。這裡我將會討論如何使用Unreal前端，因為兩者的介面幾乎是完全相同的。

首先你應該啟動你的遊戲，最好是作為一個獨立應用程式執行，但是你也可以在Unreal編輯器中分析執行（在編輯器中分析意味著會有很多的編輯器選單邏輯和其他程式碼在你的分析記錄中出現，所以最好把它作為一個獨立遊戲來分析）。

分析的最好配置就是測試建立，因為所有不必要的除錯輸出都可以被省略，而且它含有全部的程式碼優化，並且使用烘焙的優化內容。你可以讀到更多關於不同建立配置的資訊。你也會需要烘焙來讓你的內容作為獨立遊戲來執行，這可以通過Unreal編輯器的File Menu > Cook Content for*Platform*完成，或者你可以為其他平臺給你的內容打包。

無論是何種原因，如果你不能完成測試建立或者烘焙你的內容，你可以完成一個開發編輯器建立，帶著遊戲選項執行，這會為很好地為你顯示不同特徵的相對效能代價，但是一個含有烘焙內容的測試建立對於得到最終資料是最佳選擇。

當啟動你的遊戲時，啟用遊戲和Unreal前端之間的內部過程通訊，通過使用命令列上的­messaging選項是很必要的。Unreal前端不僅支援在相同機器上執行的UE4應用分析，也支援在網路中分析。

在你完成啟動遊戲之後，你可以執行UnrealFrontend.exe，這可以在UE4/Engine/Binaries 資料夾中找到。你可以看到如下的介面，先在導航找到Session前端標籤，之後找到分析器標籤。

 一旦你選擇了一個session和一個例項，資料抓取按鈕就會變得可用，你可以立即點選它開始資料抓取，再點選一次停止。當你停止的時候，你可以看到一個對話方塊詢問你是否想要把抓取結果傳遞到這臺機器上：

在這裡，它會把檔案傳到你的機器上（如果你不是在網上分析的話就本地拷貝），你會看到這個彈出框：

 當完成時，會詢問你是否想要載入：

 當分析器已經載入了，它長成這樣： 

我會詳細解釋各個部分：

1.     這是一個渲染執行緒vs遊戲執行緒的簡圖，根據CPU邏輯與渲染的關係，一眼你就會知道你是否是CPU受限的，或者它是否是與遊戲相關的且花費最多效能的邏輯。

2.     這個區域顯示了抓取期間的整個CPU載入的簡圖。在這裡，你可以沿著時間線單擊任何部分來觀察對應幀的CPU分析，或者你可以單擊、拖拽來選擇幀的範圍並且檢視均值。根據你這裡的選擇，函式時間（3）的層級列表中的分析資料會改變。

3.     這是呼叫的不同函式和所花時間的層級列表，花費時間最長的函式排在頂端。花費最多時間的函式以紅色顯示，其它用黑色顯示。你可以通過單擊左側三角來展開對應層，你可以看到這個函式呼叫過程的分解以及執行花費的時間。

a.  

b.  注意這裡的CPU停轉是CPU閒置等待其它執行緒結束的時間。

4.     如果你在函式時間（3）的層級列表中選擇了特定的函式，你可以看到這裡的顯示變化，這裡顯示了什麼函式呼叫了這個函式，以及該函式呼叫了哪些函式，同時可以看到這些呼叫和被呼叫函式執行時間的比例。

5.     左側面板展示了stats和stat組。頂層是stat組，你可以展開它檢視內部的獨立stat。這些stat可以是整型、浮點型數字或者記憶體，你可以控制哪些顯示在stat過濾器面板（6）中。如果你滑鼠停留在一個stat上，會彈出該stat的分析資訊（8）。

6.     在這裡你可以通過搜尋想要的stat、改變分組和排序、隱藏/顯示不同型別的stat（浮點/整型/記憶體）以及啟用/禁用層級檢視控制stat面板的顯示（5）。

7.     這些控制元件用於顯示函式時間的層級列表和所選函式的分解資訊（4）

a.  型別——如果在影象檢視中你只選擇了一幀（2），你唯一的選擇就是顯示資訊那幀，但是如果你選擇了一系列幀，你可以選擇是否顯示平均時間或者花費的最長時間。

                                               i.           

b.  檢視模式——這會改變函式時間分層的層級列表檢視（3），或者改變單純的函式列表，裡面包括這些函式的子程式包括的或排除的時間。

                                               i.          

c.  向前、向後按鈕可以讓你在影象檢視的不同部分之間跳轉（2）。所有你可以看到一系列資訊，之後縮小你的選擇範圍直到一個幀，然後用這些按鈕來在兩者之間切換。下拉箭頭顯示了之前的選擇。

                                               i.           

d.  這裡的火焰按鈕是用來展開你當前選擇函式的時間層級列表的（3），用來查詢花費最多時間的路徑，它也會用一個小火焰圖示來標識該路徑。

                                                                      i.          

8.     滑鼠在stat面板（5）的一個stat上面停留時，會顯示關於該stat的分析資訊，最重要的是最小值、平均值和最大值：

e.   

GPU分析器

有一個與研究GPU效能的類似工具。

首先，如果你想要啟動你的遊戲，最好先作為一個獨立應用來啟動，但是你也可以在Unreal編輯器中分析它的執行（因為編輯器UI渲染等也會在你的分析檔案中顯示，所以最好單獨分析遊戲）。

分析的最好配置就是測試建立，它含有全部的程式碼優化，並且使用烘焙的優化內容。你可以讀到更多關於不同建立配置的資訊。你也會需要烘焙來讓你的內容作為獨立遊戲來執行，這可以通過Unreal編輯器的File Menu > Cook Content for*Platform*完成，或者你可以為其他平臺給你的內容打包。

如果因為無論任何原因你不能完成測試建立或者烘焙你的內容，你可以完成一個開發編輯器建立，帶著遊戲選項執行，這會為很好地你顯示不同特徵的相對效能代價，但是一個含有烘焙內容的測試建立對於得到最終資料是最佳選擇。

在這個遊戲中，你可以在控制檯輸入profilegpu來啟動GPU分析器，或者按Ctrl+Shift+,來啟動，這會開啟GPU觀察器：

這裡你可以看到一張形象圖，裡面有渲染場景的步驟，在頂部可以看到它們在GPU上花費多少時間，在底部你可以在文字列表中看到相同的資訊。在圖或者列表中任選一個入口都會在兩地方同時選定選中物件，如果滑鼠在圖上停留，會顯示GPU的任務名稱。

這個命令不僅打開了觀察器，同時也向日誌檔案和輸出日誌輸出了相同資訊（也有一些額外資訊）。你可以從視窗選單中開啟輸出日誌：

輸出日誌標籤中的輸出內容如下：

你可以在輸出日誌中看到這裡也有百分比資訊，還有繪製、初始量和頂點的數量。

為你的內容做計劃和預算

優化的最初階段之一應該是為你的內容計劃性能預算。為製作內容制定指導方針是必要的，所以當美工為遊戲製作不同角色和環境時，它們的效能和記憶體特徵變化不大，一些內容的合併會以一個不好的幀率執行，因為一些合併未充分利用潛在可用的CPU和圖形效能。

特殊的效能提升建議

合併網格

如之前線上框視覺化解釋中提到的，減少三角形和頂點的數量永遠都是提高效能的方法，但是很多時候，一個單獨網格比多個網格刻畫集合圖形的效能要好得多（一個有1000個頂點的網格可能比10個有100個頂點的網格的更新和渲染都快）。這是因為不僅這些網格可能會分別單獨呼叫GPU來繪製，也因為UE4會為每個網格單獨儲存和更新變換資訊，而且可能檢查這些獨立網格間的碰撞。所以，如果沒有功能性的原因來設定單獨網格的話，你應該考慮在把它們引入UE4之前在DCC工具中選擇合併它們。

關於合併網格反對的說法是：一個單獨的網格可能不能被部分剔除，所以如果它的任何一部分是可見的，整個網格都會渲染。由於這個原因，可能把你的整個關卡都合併成一個單獨網格可能不是一個好主意，但是讓每一個三角形都成為一個單獨網格同樣也不是最理想的，所以在兩種極端中取得平衡至關重要。

由大量網格組成的單一物件

使用由很多獨立網格組成的物件（比如說一輛車的每個獨立部分由成百成千的單獨網格組成）對於引擎來說可能任務非常繁重，如果引擎在模擬時把每個網格當做獨立物件，而且為每個網格單獨執行引擎系統（例如：在你的物件中為幾千個網格進行單獨的輓歌物理模擬）。

像這樣對許多網格元件進行父處理並且把它們作為一個物件處理比較好，但是我們有一些建議提供給你，來避免在這些事情上浪費不必要的CPU和GPU的週期。

首先，如果你的物件中有許多網格並且經常不可見，試著不要在移動場景中建立這些網格直到它們可見。即使網格沒被渲染，每當一個父級網格元件的變換改變時，每個子網格元件的變換都會被更新，而且在網格需要可見前不要呼叫Components.Add()方法，這樣可以節省許多處理器週期。

同樣道理也適用於在遊戲系統中註冊不可見的網格，如果網格不可見，它的物理形態等可能不需要每幀都更新，所以，在網格需要變為可見之前不要在不可見網格元件上呼叫RegisterComponent()方法。

避免在由相同物件組成的、或不需要相互碰撞的網格間執行碰撞檢測。

對於那些不需要碰撞的子網格元件，把它們的碰撞情況設定為無：

ChildMeshComponent​­>​SetCollisionProfileName​(​UCollisionProfile​::​NoCollision_ProfileName​); 

如果你的角色一點也不需要碰撞，那麼就在你的父級網格元件上設定相同的內容，否則就在父級上啟用碰撞，但是給它一些能表示它和它的孩子的碰撞說明。

如果包含你的角色的網格元件是接觸的或重疊的，它們就會產生重疊時間。如果你不在意這些事件，禁用它們會提升效能：​MeshComponent​­>​bGenerateOverlapEvents​ = ​false​;

螢幕剔除系統用網格元件的邊界來確定該網格是否應該在這一幀中渲染。對於那些含有許多網格元件的物件來說，即使物件部分在螢幕外，為每個獨立子物件檢查邊界的代價也可能比單純渲染所有網格元件的代價要大。試著設定子網格元件使用它們父級元件的邊界，來測試觀察效能是否沒有提升。

ChildMeshComponent​­>​bUseAttachParentBound​ = ​true​;

給所有這些網格單獨打光是不必要的繁重任務——在CPU配置檔案中渲染執行緒部分中“更新間接照明快取”的毫秒數值很高。通過在你物件的根元件中設定bLightAttachmentsAsGroup為true，你可以選擇在你的物件的每個網格中使用相同的間接照明快取資訊，這會節省獨立更新網格的時間。

推薦的光線效能設定

動態物件的每個物件陰影可以通過不選關卡平行光中的bUseInsetShadowsForMovableObjects 的flag來禁用，這會提升效能。

在你的關卡的平行光屬性中，經常減少動態陰影級聯的數量不會對陰影外觀產生非常大的影響，但是會提升效能，我認為預設的是5，但是減少至大約3的樣子就會產生大致差不多的效果。

動態陰影

動態陰影的代價可能很大，尤其是全域性動態陰影。這是因為三角形必須得為動態陰影對映重新渲染。如果你在移動光源上需要許多動態陰影來使多邊形儘可能少，如果你想要更多多邊形，那就試著少用帶有動態陰影的可移動光線。

記住，設定了4個以上的重疊固定光線會迫使半徑最小的那個變成可移動的，這樣就會開始投射動態陰影。本文他處討論的固定光重疊視覺化是確保沒有過多重疊的好方法。

限制後過程效果

後過程效果同樣是代價很大的，禁用你不需要的效果也可以很大地提升效能。一些可以考慮禁用的後過程效果包括鏡頭閃光、土地深度和螢幕空間反射。為了提升效能，你可能也想要以低質量執行螢幕空間抗混疊，以更小的散景尺寸執行散景DOF，因為這裡的尺寸與效能是負相關的（更大的散景意味著更差的效能）。

如果最終你可以在其它系統中取得足夠的效能提升，你可以之後選擇性地把這些效果重新啟用。

高儲存低質量影響

●     在後過程設定中禁用scene color fringe

●     禁用​ ambient cubemap​，用​ LightmassEnvironmentColor代替

●       通過設定強度在後過程設定中禁用​imagebased lens flares 。 

在單一鏡頭中限制貼花數量

如果在攝像頭中同時有許多彼此接近的貼花，有時這樣的代價是很大的。如果你有比如說50個貼花正同時被渲染，這對於效能可能有消極影響。試著稀釋或擴散這些貼花，那麼就不會有那麼多貼花同時被渲染了。

以更低解析度和更少變形渲染

如果你想要試著以稍低的解析度和稍少的變形進行渲染來節省效能，試著做、看看它看起來和執行起來效果如何是非常簡單的。

當遊戲執行時，你可以開啟控制檯輸入“r.screenpercentage 90”，其中90是全憑尺寸和渲染的百分比。

更永久的設定方法是：選中你的後步驟列表裡的“覆寫螢幕百分比”框，之後將螢幕百分比設定成想要的百分比（小於等於100）。

場景捕捉物件

場景捕捉物件（如場景捕捉立方體）的預設設定是捕捉每幀。捕捉這些基本涉及到從不同視角渲染整個場景（對於一個場景捕捉立方體來說，會這做6次，每次渲染立方體的一個面），還有從玩家的視角來渲染。這樣的代價明顯是很大的（如果一個場景中有許多這樣的物件尤其如此），所以，除非每幀都抓取它們是你的遊戲的一個重要特點，抓取應該被禁用。

總體來講，同樣的原因，限制場景抓取物件的總數量是有道理的。

其它涉及事項：

設定最大和最小幀率

可以在DefaultConfig.ini.檔案中設定來控制這個變數，預設如下：

 [/Script/Engine.Engine]bSmoothFrameRate=true MinSmoothedFrameRate=22

MaxSmoothedFrameRate=62

禁用遮擋剔除

對於一些特定型別的遊戲，遮擋剔除可能會花費比它本身所節省的時間更多。比如：在打鬥遊戲中，通常場景中的所有內容都應該是被渲染的，不常見的情況是許多幾何圖形被其他物件遮擋，在這些情況下，使用全域性預計算可見覆選框也許有幫助？