UE4性能優化
在使用虛幻4做項目的過程中性能一直是不可忽視的話題，為了畫面效果我們至少需要每秒20幀左右。根據不同的項目要求這個幀數可以能要40或者60，甚至在某些情況下會要求更高。
本文根據官方文檔部落格等綜合而來，意在發現問題所在更高效的解決問題，下文将根據CPU,GPU來分析。
·首先要确定我們的性能瓶頸出現在哪裡，這時我們在控制台輸入“stat unit”它會顯示如下圖所示：
也可以通過視圖顯示出來
這裡Farme有兩個度量：
第一個是這個幀的目前幀時間（左）
第二個是在最後幾秒的最差幀時間（右）
左側的圖是遊戲、繪圖和GPU的幾個幀裡的幀時間圖。
Frame時間是産生一幀花的總時間，注意GPU和CPU是同時執行的，是以幀花費的總時間不是它們時間的總和，但是任一項拖了後腿都可能是幀率降低的原因。遊戲的實際單幀時間由這三者之一限制：Game（CPU 遊戲邏輯線程），Draw（CPU 渲染線程）或者 GPU（GPU）。 您的幀時間指的是生成遊戲中每一幀所需要花費的總體時間。 由于在完成一幀前會同時同步遊戲和描畫線程，幀時間常常接近于這些線程中的時間。 GPU時間衡量的是顯示卡需要多長時間來渲染場景。 由于GPU時間與幀同步，它的值很可能也類似于幀時間。
Game（CPU 遊戲邏輯線程）：這是一個任意的CPU邏輯，它不與渲染直接關聯。如果該組很慢，通常的情況是程式員有需要修正的内容，但是它可以是與美術相關的，比如：螢幕上有太多顆粒。内置在CPU分析器中的Frontend工具可以用來研究CPU性能并且觀察正運作緩慢代碼。特定的、與複雜任務相關的遊戲設定隻能在CPU上執行，像A.I.和Navigation的設定。
Draw（繪圖）：這是一個與GPU上渲染設定相關的CPU邏輯。它包括圖形API和繪圖調用的設定，或者如果渲染代碼已經以非最佳的方式修正了，它就可能與渲染代碼相關。
GPU：GPU渲染幀花費多長時間。它包括：執行圖形API調用、繪圖調用、着色器和後過程着色器的執行、擷取紋理……這裡的問題通常與資源相關，它可能是場景中類似着色器這樣非常複雜的東西，或者場景中有許多不同的網格，結果就是每幀中發生太多的繪制調用。這可能會讓一個專業美工或程式員找到問題根源，但是通常情況下需要一些決策——為了達到預期性能，應該做哪些權衡。這裡能幫到您的最棒的工具是GPU分析器和着色器複雜性視圖，這些會在之後進行讨論，同時下面還會讨論“Advance”目錄中顯示的特定stats。
如果一幀花的時間跟邏輯線程的時間比較接近，那麼瓶頸在邏輯線程，相反如果跟渲染線程的時間比較接近，那麼瓶頸在渲染線程。如果兩個時間 都不接近，但跟GPU時間比較接近，那麼瓶頸在顯示卡上。圖中我們可以看到 GPU 是限制主因（三者最大的一個）。為了取得更少的 單幀 時間，在這個情形下必須先優化 GPU 的負載。
GPU分析
(1) 為確定引擎中最大的幀速沒有被限制先設定下幀率（- r.VSync可以關閉垂直同步）：
(2) 按Ctrl+shift+或者控制台指令: ProfileGPU，調查GPU檢視器，也可以打開：
可以看出影響GPU瓶頸最主要的是BasePass和PrePass ，
PrePass / Depth only pass： RenderPrePass / FDepthDrawingPolicy 。渲染遮擋物，對景深緩沖區僅輸出景深。該通道可以在多種模式下工作：禁用、僅遮蔽，或完全景深，具體取決于活動狀态的功能的需要。該通道通常的用途是初始化 Hierarchical Z 以降低 Base 通道的着色消耗（Base 通道的像素着色器消耗非常大）。
Base pass ： RenderBasePass / TBasePassDrawingPolicy。渲染不透明和遮蓋的材質，向 GBuffer 輸出材質屬性。光照圖貢獻和天空光照也會在此計算并加入場景顔色。
Lighting ： 陰影圖将對各個光照渲染，光照貢獻會累加到場景顔色，并使用标準延遲和平鋪延遲着色。光照也會在透明光照體積中累加。
Fog ： 霧和大氣在延遲通道中對不透明表面進行逐個像素計算。
Post Processing ： 多種後期處理效果均通過 GBuffers 應用。透明度将合成到場景中。
其中BasePass 0 =不透明網格。
BasePass 1 =用于Z深度的Alpha蒙版不透明網格。
BasePass Dynamic =動畫頂點，如Skeletal，GeoCache（Alembic）等。
幾個值得注意的資料項：
Base Pass
Deferred Decals
Lighting
SSR（環境反射）
Translucency(半透明）
Postprocessing(後期處理效果）
Particle（粒子）
當Base Pass很高，可以使用指令行打開Early Z Pass 可以降低 Base Pass 但同時會少量增加DRAW CALL
檢查影響GPU效率的内容檢視有無超标現象
比如分辨率、HMD SP、投影貼圖大小
1：basepass消耗高的話，就需要了解下哪些模型，貼圖，材質開銷太大。 面數過高的模型就減面；半透明用的多的物件就斟酌下是否必要；材質是GPU消耗過高的一大元兇，比較耗的材質可以檢查下節點，關閉一些非必要的效果。材質複雜程度在這裡可以檢視，越紅的越消耗，原則上減少使用點動畫和曲面細分等一些效果。
紅色：意味着性能消耗非常高 綠色：意味着性能消耗最低半透明：意味着增加性能消耗
可在材質裡檢視着色器的說明數量盡可能減少
另外，場景裡擺放的模型如果不需要參與碰撞計算的話，最好關閉碰撞，減少運算消耗。
遊戲運作時在控制台裡使用showflag（隐藏）指令可以幫我們快速定位具體是模型？特效？光照？等等哪個消耗高，消耗高的就優化，列舉幾個常用的”showflag.”指令“0”關閉“1”打開：
ScreenSpaceReflections： 切換螢幕空間的反射效果，可能會非常影響性能，對那些達到一定粗造度的像素有效
AmbientOcclusion： 螢幕空間環境遮罩
AntiAliasing： 切換各種抗鋸齒（TemporalAA 和 FXAA，FXAA更快，但效果較差）
Bloom： 影響那些受到 lensflares 和 bloom 功能的畫面。
DeferredLighting： 切換所有延遲光照通道。
DirectionalLightsPointLightsSpotLights： 切換不同的光照類型（檢查光照類型影響性能時有用）
DynamicShadows： 切換所有的動态陰影（陰影貼圖的渲染，以及陰影的過濾和投影）
GlobalIllumination： 切換預烘培和動态間接光照（LPV）
LightFunctions： 切換光照函數渲染
PostProcessing： 切換所有後處理效果
ReflectionEnvironment： 切換環境反射效果
Refraction： 切換折射效果
Rendering： 切換整體渲染
Decals： 切換貼花渲染
LandscapeBrushes StaticMeshesSkeletalMeshes Landscape： 輪詢切換幾種不同的幾何體的渲染
Translucency： 切換透明度渲染
Tessellation：切換曲面細分（仍将運作曲面細分 shader，但生成更多三角面）
IndirectLightingCache： 切換是否動态物體或者靜态物體具有使用間接光照 Cache 時無效的光照貼圖。
Bounds ： 顯示編輯器中目前選中物體的邊界框。
VisualizeSSR ：螢幕空間反射像素顯示為亮橙色是計算較慢的區域
關閉stuff檢視效率
r.SetRes： 調整渲染分辨率
r.VSync 開啟/關閉垂直同步（可能依賴于是否原生全屏）。
r.AllowOcclusionQueries 用于禁用遮擋（可以讓場景運作的更慢）。
r.TiledDeferredShading 能夠關閉基于 Tile 的延遲光照技術（GPU粒子的光影則沒有退回方法）
.TiledDeferredShading.MinimumCount 能夠調整使用多少燈光應用在基于 Tile 的延遲光照技術（視覺上并沒有差異但性能會有不同）
r.SeparateTranslucency 這是一個用于修複半透明情況下景深的問題的功能，如果不需要的時候可以把它關閉，并有其他影響（查閱 SceneColor）。
r.Tonemapper.GrainQuantization 用于關閉在 Tonemapper 中添加的噪點來避免 Color Banding，由于 8bit 量化和較小的品質改進在輸出為 10:10:10 并不必須。
r.SceneColorFormat 能夠選用不同的 SceneColor 格式（預設是 64bit 的最佳品質，并支援螢幕空間子表面散射）。
FX.AllowGPUSorting 禁用粒子排序（在大量粒子的使用可以妥協使用）。
FX.FreezeParticleSimulation 禁止粒子的更新。
r.MaxQualityMode： 最高品質
r.MipMapLODBias： Mipmap Bias
r.MobileContentScaleFactor： 畫面縮放比
r.ScreenPercentage： 用于減小内部實際渲染分辨率，畫面會在重新放大
r.ShadowQuality： 移動端Stationaary燈光動态陰影品質，調整其值檢視幀速變化，以判斷瓶頸
r.Shadow.MaxResolution： 移動端Movable燈光動态陰影品質，調整其值檢視幀速變化，以判斷瓶頸
StatMemory：提供關卡中記憶體使用情況
2：燈光消耗高的話，需要檢查動态光照數量（固定光也可以投射動态光照），是否有過多重疊的照射區域，照射範圍參數是否開的太大。由于靜态光照Build後已将燈光資訊存儲進了Lightmap，遊戲中不再計算，是以燈光的主要消耗來自動态光源。先在世界大綱裡檢視所有燈光類型，确定有幾盞動态光和固定光，前面有紅點的是動态，黃點的是固定。
再進一步檢視固定光的照射範圍的重疊部分是否太多，重疊的越多，交集處越亮越紅。用燈的原則是能不用動态光就不用（消耗主要來自被投照射的Mesh），燈光照射範圍盡量不重疊，且同一個地圖裡固定光不能超過4盞。
光照複雜度視圖模式基于動态光源的數量來對場景進行着色。
黑色:意味着沒有收到動态光源影響。
不同顔色:從綠到紅，表示受到動态光源的影響逐漸增加。
關閉燈光的投射動态陰影也可以降低一些消耗，甚至一些燈光可以直接關閉投射陰影功能。
3：後期處理是另一個GPU消耗過高的元兇，需要慎用，原則是盡可能的把一些不必要的參數關掉，尤其是SSR,後期AO，Bloom等。一些參數預設會自帶一些數值，沒必要的全部清零，抗鋸齒模式切換成FXAA。
使用Alt+0/Light Map Density可以對場景中的光照貼圖密度進行分析。
其他資料分析
ShadowDepths
這個生成通過光源進行陰影投射的深度資料的pass。
作用與這裡的消耗主要受到開啟了投影的光的數目、動态光照影響的面數、以及陰影的品質的影響。
陰影的品質可以通過Sg.shadow quality進行全局的調節。
Memory-bound
如果有大量的材質使用了不同的貼圖，導緻Texture Sample的數量爆炸的話，就會自然的變成瓶頸。UE4有使用Texture Streaming，如果存儲空間爆炸了的話，就會出現貼圖模糊的情況，這時候可以使用Stat Streaming指令進行分析。
PrePass DOM_…
EarlyZPass，對非透明物體進行的早期的深度計算。
資料似乎被用于遮蔽計算，如果不使用Dbuffer Decals的話可以關掉。但是早期的深度計算可以在BasePass之前進行遮蔽計算，能讓basepass以及之後所有的通道的計算減少很多。而且即便在這裡不進行深度計算，會影響這裡的運算量的變量依然會作用與後面的深度計算階段，是以關閉EarlyZPass還是需要多做考慮的。另外要使用DBuffer Decals的話必須使用Opaque and masked的zpass計算，否則應該會出現奇怪的現象。
性能上受到非透明物體的面數的影響，同時根據上面的選項不同也受到Masked的材質的影響。
HZB
Hierarchical Z-Buffer，用于計算HZB遮蔽，同時也會被螢幕空間内的射線演算使用，例如螢幕空間反射計算、AO等。同時被用于Mip的設定。受螢幕空間的大小影響。據官方描述，HZB擁有較高的固定性能消耗，每個物體所造成的消耗較小。可以通過r.HZBOcclusion來調整運算的類型。
Base Pass
對非透明的物體進行演算并填充到GBuffer，使用緩沖區可視化模式可以在視圖中看到效果。幾乎所有的延遲渲染都受到其影響，是以才叫基礎通道。
其計算結果包括base color, metallic, specular, roughness, normal, sss profile，并且Decals、Fog以及Velocity的計算也在此處。其開銷受到螢幕空間尺寸、物體數量、面數、Decals的數量、Shader的複雜度，生成的過程中包含光照貼圖的推送，是以也會受到光照貼圖的大小的影響。可以通過Stat rhi指令檢查各種貼圖和triangle的消耗。
另外，前向渲染的光照也在這裡進行，此時光照的數量也會影響到這裡的消耗。
Translucency
半透明的材質以及光照演算，通過Stat gpu中的Translucency and Translucent Lighting可以進一步檢視。消耗受到螢幕空間大小以及螢幕内的半透明物體的數量影響，半透明物體的光照計算要盡量減少過度繪制。以及避免過多的需要進行半透明光照計算的光的數量。
Particle Simulation/Injection
粒子模拟，這裡隻展示GPU粒子的消耗，性能主要受粒子數量以及是否開啟了基于深度的粒子碰撞影響。粒子的優化主要通過LOD以及設計上的優化進行。
Post process
UE4的後期處理功能比較多，AA、DOF、自動曝光以及很多其他的功能都在其中。每種PP特效都會産生額外的性能消耗，如果使用了PP材質的話，其複雜度也會影響性能。
Relection Envirionment
反射捕捉控件的計算緩存可以将顯示模式調整為Reflections來檢視各個控件對緩存的影響通常的建議是，放一個大範圍的低精度反射捕捉，然後在需要的地方盡量不重疊的放置高精度的捕捉控件。影響性能的主要就是捕捉控件的數量及範圍，也受螢幕空間的大小影響。
Render Velocities
速度主要用于TAA以及Motion Blur，受到移動物體的數量以及其面數的影響。主要的優化政策是使用LOD。
Screen Space Reflections
螢幕空間反射通過以下連個指令來進行調節：
r.ssr.maxroughness 0.0-1.0
r.ssr.quality 0..4其中Maximum roughness決定着計算的範圍的大小。
CPU分析
遊戲線程分析
檢視遊戲線程的性能表現的最佳工具是使用統計資料分析程式。在控制台輸入“stat startfile”來啟動分析，等10秒左右輸入 “stat stopfile”收集這10秒的平均值當然也可以等更多的時間。在路徑Saved/Profiling/UnrealStats下，會有關于您項目檔案夾的ue4stats檔案。
也可以用“STAT SLOW”來擷取實時的報告，它可以通過報告運作一幀中特定時間段(預設10毫秒)來逐漸定位幀停頓的位置。
運作速度較慢的資料将會在HUD上顯示一段時間，進而判斷性能波動。“Stat stopslow”來關閉它.
參數以秒為機關(是以10ms也就是0.01秒)參數可設定持續的時間，預設值是 10秒。
例:STAT SLOW 0.01 10這将會渲染在過去的10秒内所有運作時間超過10毫秒的循環統計資料。
現在我們需要分析，需要打開編輯器中的Session Frontend（會話前端）
當您打開了會話前端頁籤後，您需要切換到Profiler(分析程式)的小頁籤。 在該處，您可以選擇載入您最近捕獲的ue4stats分析檔案。
加載後會這樣顯示
1.這是一個渲染線程vs遊戲線程的簡圖，根據CPU邏輯與渲染的關系，一眼你就會知道你是否是CPU受限的，或者它是否是與遊戲相關的且花費最多性能的邏輯。
2.這個區域顯示了抓取期間的整個CPU加載的簡圖。在這裡，你可以沿着時間線單擊任何部分來觀察對應幀的CPU分析，或者你可以單擊、拖拽來選擇幀的範圍并且檢視均值。根據你這裡的選擇，函數時間（3）的層級清單中的分析資料會改變。
3.這是調用的不同函數和所花時間的層級清單，花費時間最長的函數排在頂端。花費最多時間的函數以紅色顯示，其它用黑色顯示。你可以通過單擊左側三角來展開對應層，你可以看到這個函數調用過程的分解以及執行花費的時間。
注意這裡的CPU停轉是CPU閑置等待其它線程結束的時間。
4.如果你在函數時間（3）的層級清單中選擇了特定的函數，你可以看到這裡的顯示變化，這裡顯示了什麼函數調用了這個函數，以及該函數調用了哪些函數，同時可以看到這些調用和被調用函數執行時間的比例。
5.左側面闆展示了stats和stat組。頂層是stat組，你可以展開它檢視内部的獨立stat。這些stat可以是整型、浮點型數字或者記憶體，你可以控制哪些顯示在stat過濾器面闆（6）中。如果你滑鼠停留在一個stat上，會彈出該stat的分析資訊（8）。
6.在這裡你可以通過搜尋想要的stat、改變分組和排序、隐藏/顯示不同類型的stat（浮點/整型/記憶體）以及啟用/禁用層級視圖控制stat面闆的顯示（5）。
7.這些控件用于顯示函數時間的層級清單和所選函數的分解資訊（4）
a. 類型——如果在圖像視圖中你隻選擇了一幀（2），你唯一的選擇就是顯示資訊那幀，但是如果你選擇了一系列幀，你可以選擇是否顯示平均時間或者花費的最長時間。
b. 視圖模式——這會改變函數時間分層的層級清單視圖（3），或者改變單純的函數清單，裡面包括這些函數的子程式包括的或排除的時間。
c. 向前、向後按鈕可以讓你在圖像視圖的不同部分之間跳轉（2）。所有你可以看到一系列資訊，之後縮小你的選擇範圍直到一個幀，然後用這些按鈕來在兩者之間切換。下拉箭頭顯示了之前的選擇。
d. 這裡的火焰按鈕是用來展開你目前選擇函數的時間層級清單的（3），用來查找花費最多時間的路徑，它也會用一個小火焰圖示來辨別該路徑。
8.滑鼠在stat面闆（5）的一個stat上面停留時，會顯示關于該stat的分析資訊，最重要的是最小值、平均值和最大值：
這裡我們隻關注幾個選項，展開GameThread(遊戲線程)項目，然後往下拉，直到您看到超過幾毫秒的“Inc Time”（包含時間）條目，而且其不包含許多子項或不包含任何子項。 同時關注一下“Calls”（調用）數列，它顯示了每幀調用的統計資料的平均次數。 不要被“CPU Stall”（CPU停滞時間）項目弄糊塗了。 它們顯示的是線程等待處理其他内容時所花費的時間，是以不是主要資料，而且僅僅會在幀頻率受限或者遊戲程序不為瓶頸時才會顯示出來。
還有一個重要項目TickFunctionTask。 此項目下是正在更新的每個actor群組件。 一般來說，降低每幀更新的actor群組件的數量都可以很好地加速遊戲。
另一個要關注的是BlueprintTime（藍圖時間）。 找到這個值的最佳方法是切換到包含（合并）視圖并在清單中找到它。 這樣就可以把所有的BlueprintTime（藍圖時間）條目組合到單一行中。 如果您選擇BlueprintTime（藍圖時間），然後切換回層次視圖，則其會選擇所有藍圖代碼被執行的位置，這樣能讓您很好地了解花費時間進行處理的位置及其位于哪個藍圖中。
另一個常見的問題位置是TickWidgets（更新控件）。 如果這個統計資料值很高，這表示您可能同時顯示了太多控件，或者這些控件上的屬性代理過于複雜。 一些slate屬性，比如可見性，可能會在每幀被調用好幾次，這樣它們的值必須要小而且能及時傳回。
您是不是在遊戲中有很多骨架網格物體？ SkinnedMeshComp更新時間有時也會消耗很多系統資源。 請嘗試降低顯示在分析檔案中的骨架中的骨骼數量，或者降低動畫藍圖的複雜度。 如果您不需要在無法看到骨架網格物體時更新動畫，請考慮将骨架網格物體元件上的MeshComponentUpdateFlag（網格物體元件更新辨別）正确設定為OnlyTickPoseWhenRendered（僅在渲染時更新姿勢）。 請注意，将此辨別設定為AnimNotifies（動畫通知）将使得這些網格物體不被渲染時不再對其進行觸發。
https://docs.unrealengine.com/en-us/Engine/Performance/Profiler 參考文檔
一些相關的工具
MergeActors(融合Actor)
合并多個Actor以及它們的材質和貼圖使其轉化成Mesh，可以減少材質數量和材質複雜程度。
DeviceProfile（裝置概述檔案）
對不同裝置設定不同的渲染參數以節省性能
RenderingDetail Mode(渲染細節模式)
設定顯示細節模式和配置
ModelLOD 設定
LOD模型不同細節，根據距離參數優化渲染效率
· CSM聯級動态陰影
CSM 陰影不會出現調制陰影中的雙重陰影，在為多個物體投射陰影時此方法速度較快。
CSM使用了額外的紋理采樣器，可通過項目設定将其禁用：
Rendering -> Mobile-> Combined Static and CSM Shadowing，即可将采樣器空出供材質使用。
線框視圖模式可以告訴你場景和獨立網格中有多少頂點和三角形，要實作這個模式，你可以在編輯器等級視口的可視化模式菜單中找到：
如果你的網格有三角形/頂點的富餘，而且遠比攝像頭的充足時，線框就會變成實線。如果你的網格不總是實線的，這意味着你有可能需要比渲染更高的複雜性，你就應該減少網格中的多邊形數量。
減少三角形和頂點的數量永遠都是提高性能的方法，但是很多時候，一個單獨網格比多個網格刻畫集合圖形的性能要好得多（一個有1000個頂點的網格可能比10個有100個頂點的網格的更新和渲染都快）。這是因為不僅這些網格可能會分别單獨調用GPU來繪制，也因為UE4會為每個網格單獨儲存和更新變換資訊，而且可能檢查這些獨立網格間的碰撞。是以，如果沒有功能性的原因來設定單獨網格的話，你應該考慮在把它們引入UE4之前在DCC工具中選擇合并它們。
關于合并網格反對的說法是：一個單獨的網格可能不能被部分剔除，是以如果它的任何一部分是可見的，整個網格都會渲染。由于這個原因，可能把你的整個關卡都合并成一個單獨網格可能不是一個好主意，但是讓每一個三角形都成為一個單獨網格同樣也不是最理想的，是以在兩種極端中取得平衡至關重要。
ViewMode檢查
當三角面密度太高（高到三角面小于2*2像素 往往發生在遠處物體上） 很容易出現問題。
分别檢視三角面、頂點、燈光數量、陰影設定、Actor數量
LOD 關閉Shadew 、燈光螢幕面積
頂點太多
點動畫的Shader處理過于複雜
Tessellation 過于複雜
多重UV、過多的SG
檢視Staticmesh Editor裡點和面數的差别是否大
點沒有合并、場景GPU粒子模拟數量過多
材質複雜度
Quality、Switch、Sin、 Pow、 Cos、Divide、Noise 這些節點很耗費資源
減少材質Shader的指令的數量。減少Texture Sample的數量：把經常使用到同一個物體上的圖案合在一張貼圖上；去掉對品質影響很小的貼圖，比如Specular、AO等。盡量使用QualitySwitch，Sin, Pow, Cos, Divide, Noise節點。多向量的計算量總是大于單向量的計算量。
遮擋的culling計算
使用預算可見性剔除遮擋的對象。
延遲燈光
當使用lightingfunction、IE、接受投影、區域光、複雜shadingmodes的時候會變得更昂貴。反射SSR如果有問題，請關掉它。另外後期AO也很耗費資源。
參考文檔：https://docs.unrealengine.com/en-us/Engine/Performance
UE4性能優化
在使用虛幻4做項目的過程中性能一直是不可忽視的話題，為了畫面效果我們至少需要每秒20幀左右。根據不同的項目要求這個幀數可以能要40或者60，甚至在某些情況下會要求更高。
本文根據官方文檔部落格等綜合而來，意在發現問題所在更高效的解決問題，下文将根據CPU,GPU來分析。
·首先要确定我們的性能瓶頸出現在哪裡，這時我們在控制台輸入“stat unit”它會顯示如下圖所示：
也可以通過視圖顯示出來
這裡Farme有兩個度量：
第一個是這個幀的目前幀時間（左）
第二個是在最後幾秒的最差幀時間（右）
左側的圖是遊戲、繪圖和GPU的幾個幀裡的幀時間圖。
Frame時間是産生一幀花的總時間，注意GPU和CPU是同時執行的，是以幀花費的總時間不是它們時間的總和，但是任一項拖了後腿都可能是幀率降低的原因。遊戲的實際單幀時間由這三者之一限制：Game（CPU 遊戲邏輯線程），Draw（CPU 渲染線程）或者 GPU（GPU）。 您的幀時間指的是生成遊戲中每一幀所需要花費的總體時間。 由于在完成一幀前會同時同步遊戲和描畫線程，幀時間常常接近于這些線程中的時間。 GPU時間衡量的是顯示卡需要多長時間來渲染場景。 由于GPU時間與幀同步，它的值很可能也類似于幀時間。
Game（CPU 遊戲邏輯線程）：這是一個任意的CPU邏輯，它不與渲染直接關聯。如果該組很慢，通常的情況是程式員有需要修正的内容，但是它可以是與美術相關的，比如：螢幕上有太多顆粒。内置在CPU分析器中的Frontend工具可以用來研究CPU性能并且觀察正運作緩慢代碼。特定的、與複雜任務相關的遊戲設定隻能在CPU上執行，像A.I.和Navigation的設定。
Draw（繪圖）：這是一個與GPU上渲染設定相關的CPU邏輯。它包括圖形API和繪圖調用的設定，或者如果渲染代碼已經以非最佳的方式修正了，它就可能與渲染代碼相關。
GPU：GPU渲染幀花費多長時間。它包括：執行圖形API調用、繪圖調用、着色器和後過程着色器的執行、擷取紋理……這裡的問題通常與資源相關，它可能是場景中類似着色器這樣非常複雜的東西，或者場景中有許多不同的網格，結果就是每幀中發生太多的繪制調用。這可能會讓一個專業美工或程式員找到問題根源，但是通常情況下需要一些決策——為了達到預期性能，應該做哪些權衡。這裡能幫到您的最棒的工具是GPU分析器和着色器複雜性視圖，這些會在之後進行讨論，同時下面還會讨論“Advance”目錄中顯示的特定stats。
如果一幀花的時間跟邏輯線程的時間比較接近，那麼瓶頸在邏輯線程，相反如果跟渲染線程的時間比較接近，那麼瓶頸在渲染線程。如果兩個時間 都不接近，但跟GPU時間比較接近，那麼瓶頸在顯示卡上。圖中我們可以看到 GPU 是限制主因（三者最大的一個）。為了取得更少的 單幀 時間，在這個情形下必須先優化 GPU 的負載。
GPU分析
(1) 為確定引擎中最大的幀速沒有被限制先設定下幀率（- r.VSync可以關閉垂直同步）：
(2) 按Ctrl+shift+或者控制台指令: ProfileGPU，調查GPU檢視器，也可以打開：
可以看出影響GPU瓶頸最主要的是BasePass和PrePass ，
PrePass / Depth only pass： RenderPrePass / FDepthDrawingPolicy 。渲染遮擋物，對景深緩沖區僅輸出景深。該通道可以在多種模式下工作：禁用、僅遮蔽，或完全景深，具體取決于活動狀态的功能的需要。該通道通常的用途是初始化 Hierarchical Z 以降低 Base 通道的着色消耗（Base 通道的像素着色器消耗非常大）。
Base pass ： RenderBasePass / TBasePassDrawingPolicy。渲染不透明和遮蓋的材質，向 GBuffer 輸出材質屬性。光照圖貢獻和天空光照也會在此計算并加入場景顔色。
Lighting ： 陰影圖将對各個光照渲染，光照貢獻會累加到場景顔色，并使用标準延遲和平鋪延遲着色。光照也會在透明光照體積中累加。
Fog ： 霧和大氣在延遲通道中對不透明表面進行逐個像素計算。
Post Processing ： 多種後期處理效果均通過 GBuffers 應用。透明度将合成到場景中。
其中BasePass 0 =不透明網格。
BasePass 1 =用于Z深度的Alpha蒙版不透明網格。
BasePass Dynamic =動畫頂點，如Skeletal，GeoCache（Alembic）等。
幾個值得注意的資料項：
Base Pass
Deferred Decals
Lighting
SSR（環境反射）
Translucency(半透明）
Postprocessing(後期處理效果）
Particle（粒子）
當Base Pass很高，可以使用指令行打開Early Z Pass 可以降低 Base Pass 但同時會少量增加DRAW CALL
檢查影響GPU效率的内容檢視有無超标現象
比如分辨率、HMD SP、投影貼圖大小
1：basepass消耗高的話，就需要了解下哪些模型，貼圖，材質開銷太大。 面數過高的模型就減面；半透明用的多的物件就斟酌下是否必要；材質是GPU消耗過高的一大元兇，比較耗的材質可以檢查下節點，關閉一些非必要的效果。材質複雜程度在這裡可以檢視，越紅的越消耗，原則上減少使用點動畫和曲面細分等一些效果。
紅色：意味着性能消耗非常高 綠色：意味着性能消耗最低半透明：意味着增加性能消耗
可在材質裡檢視着色器的說明數量盡可能減少
另外，場景裡擺放的模型如果不需要參與碰撞計算的話，最好關閉碰撞，減少運算消耗。
遊戲運作時在控制台裡使用showflag（隐藏）指令可以幫我們快速定位具體是模型？特效？光照？等等哪個消耗高，消耗高的就優化，列舉幾個常用的”showflag.”指令“0”關閉“1”打開：
ScreenSpaceReflections： 切換螢幕空間的反射效果，可能會非常影響性能，對那些達到一定粗造度的像素有效
AmbientOcclusion： 螢幕空間環境遮罩
AntiAliasing： 切換各種抗鋸齒（TemporalAA 和 FXAA，FXAA更快，但效果較差）
Bloom： 影響那些受到 lensflares 和 bloom 功能的畫面。
DeferredLighting： 切換所有延遲光照通道。
DirectionalLightsPointLightsSpotLights： 切換不同的光照類型（檢查光照類型影響性能時有用）
DynamicShadows： 切換所有的動态陰影（陰影貼圖的渲染，以及陰影的過濾和投影）
GlobalIllumination： 切換預烘培和動态間接光照（LPV）
LightFunctions： 切換光照函數渲染
PostProcessing： 切換所有後處理效果
ReflectionEnvironment： 切換環境反射效果
Refraction： 切換折射效果
Rendering： 切換整體渲染
Decals： 切換貼花渲染
LandscapeBrushes StaticMeshesSkeletalMeshes Landscape： 輪詢切換幾種不同的幾何體的渲染
Translucency： 切換透明度渲染
Tessellation：切換曲面細分（仍将運作曲面細分 shader，但生成更多三角面）
IndirectLightingCache： 切換是否動态物體或者靜态物體具有使用間接光照 Cache 時無效的光照貼圖。
Bounds ： 顯示編輯器中目前選中物體的邊界框。
VisualizeSSR ：螢幕空間反射像素顯示為亮橙色是計算較慢的區域
關閉stuff檢視效率
r.SetRes： 調整渲染分辨率
r.VSync 開啟/關閉垂直同步（可能依賴于是否原生全屏）。
r.AllowOcclusionQueries 用于禁用遮擋（可以讓場景運作的更慢）。
r.TiledDeferredShading 能夠關閉基于 Tile 的延遲光照技術（GPU粒子的光影則沒有退回方法）
.TiledDeferredShading.MinimumCount 能夠調整使用多少燈光應用在基于 Tile 的延遲光照技術（視覺上并沒有差異但性能會有不同）
r.SeparateTranslucency 這是一個用于修複半透明情況下景深的問題的功能，如果不需要的時候可以把它關閉，并有其他影響（查閱 SceneColor）。
r.Tonemapper.GrainQuantization 用于關閉在 Tonemapper 中添加的噪點來避免 Color Banding，由于 8bit 量化和較小的品質改進在輸出為 10:10:10 并不必須。
r.SceneColorFormat 能夠選用不同的 SceneColor 格式（預設是 64bit 的最佳品質，并支援螢幕空間子表面散射）。
FX.AllowGPUSorting 禁用粒子排序（在大量粒子的使用可以妥協使用）。
FX.FreezeParticleSimulation 禁止粒子的更新。
r.MaxQualityMode： 最高品質
r.MipMapLODBias： Mipmap Bias
r.MobileContentScaleFactor： 畫面縮放比
r.ScreenPercentage： 用于減小内部實際渲染分辨率，畫面會在重新放大
r.ShadowQuality： 移動端Stationaary燈光動态陰影品質，調整其值檢視幀速變化，以判斷瓶頸
r.Shadow.MaxResolution： 移動端Movable燈光動态陰影品質，調整其值檢視幀速變化，以判斷瓶頸
StatMemory：提供關卡中記憶體使用情況
2：燈光消耗高的話，需要檢查動态光照數量（固定光也可以投射動态光照），是否有過多重疊的照射區域，照射範圍參數是否開的太大。由于靜态光照Build後已将燈光資訊存儲進了Lightmap，遊戲中不再計算，是以燈光的主要消耗來自動态光源。先在世界大綱裡檢視所有燈光類型，确定有幾盞動态光和固定光，前面有紅點的是動态，黃點的是固定。
再進一步檢視固定光的照射範圍的重疊部分是否太多，重疊的越多，交集處越亮越紅。用燈的原則是能不用動态光就不用（消耗主要來自被投照射的Mesh），燈光照射範圍盡量不重疊，且同一個地圖裡固定光不能超過4盞。
光照複雜度視圖模式基于動态光源的數量來對場景進行着色。
黑色:意味着沒有收到動态光源影響。
不同顔色:從綠到紅，表示受到動态光源的影響逐漸增加。
關閉燈光的投射動态陰影也可以降低一些消耗，甚至一些燈光可以直接關閉投射陰影功能。
3：後期處理是另一個GPU消耗過高的元兇，需要慎用，原則是盡可能的把一些不必要的參數關掉，尤其是SSR,後期AO，Bloom等。一些參數預設會自帶一些數值，沒必要的全部清零，抗鋸齒模式切換成FXAA。
使用Alt+0/Light Map Density可以對場景中的光照貼圖密度進行分析。
其他資料分析
ShadowDepths
這個生成通過光源進行陰影投射的深度資料的pass。
作用與這裡的消耗主要受到開啟了投影的光的數目、動态光照影響的面數、以及陰影的品質的影響。
陰影的品質可以通過Sg.shadow quality進行全局的調節。
Memory-bound
如果有大量的材質使用了不同的貼圖，導緻Texture Sample的數量爆炸的話，就會自然的變成瓶頸。UE4有使用Texture Streaming，如果存儲空間爆炸了的話，就會出現貼圖模糊的情況，這時候可以使用Stat Streaming指令進行分析。
PrePass DOM_…
EarlyZPass，對非透明物體進行的早期的深度計算。
資料似乎被用于遮蔽計算，如果不使用Dbuffer Decals的話可以關掉。但是早期的深度計算可以在BasePass之前進行遮蔽計算，能讓basepass以及之後所有的通道的計算減少很多。而且即便在這裡不進行深度計算，會影響這裡的運算量的變量依然會作用與後面的深度計算階段，是以關閉EarlyZPass還是需要多做考慮的。另外要使用DBuffer Decals的話必須使用Opaque and masked的zpass計算，否則應該會出現奇怪的現象。
性能上受到非透明物體的面數的影響，同時根據上面的選項不同也受到Masked的材質的影響。
HZB
Hierarchical Z-Buffer，用于計算HZB遮蔽，同時也會被螢幕空間内的射線演算使用，例如螢幕空間反射計算、AO等。同時被用于Mip的設定。受螢幕空間的大小影響。據官方描述，HZB擁有較高的固定性能消耗，每個物體所造成的消耗較小。可以通過r.HZBOcclusion來調整運算的類型。
Base Pass
對非透明的物體進行演算并填充到GBuffer，使用緩沖區可視化模式可以在視圖中看到效果。幾乎所有的延遲渲染都受到其影響，是以才叫基礎通道。
其計算結果包括base color, metallic, specular, roughness, normal, sss profile，并且Decals、Fog以及Velocity的計算也在此處。其開銷受到螢幕空間尺寸、物體數量、面數、Decals的數量、Shader的複雜度，生成的過程中包含光照貼圖的推送，是以也會受到光照貼圖的大小的影響。可以通過Stat rhi指令檢查各種貼圖和triangle的消耗。
另外，前向渲染的光照也在這裡進行，此時光照的數量也會影響到這裡的消耗。
Translucency
半透明的材質以及光照演算，通過Stat gpu中的Translucency and Translucent Lighting可以進一步檢視。消耗受到螢幕空間大小以及螢幕内的半透明物體的數量影響，半透明物體的光照計算要盡量減少過度繪制。以及避免過多的需要進行半透明光照計算的光的數量。
Particle Simulation/Injection
粒子模拟，這裡隻展示GPU粒子的消耗，性能主要受粒子數量以及是否開啟了基于深度的粒子碰撞影響。粒子的優化主要通過LOD以及設計上的優化進行。
Post process
UE4的後期處理功能比較多，AA、DOF、自動曝光以及很多其他的功能都在其中。每種PP特效都會産生額外的性能消耗，如果使用了PP材質的話，其複雜度也會影響性能。
Relection Envirionment
反射捕捉控件的計算緩存可以将顯示模式調整為Reflections來檢視各個控件對緩存的影響通常的建議是，放一個大範圍的低精度反射捕捉，然後在需要的地方盡量不重疊的放置高精度的捕捉控件。影響性能的主要就是捕捉控件的數量及範圍，也受螢幕空間的大小影響。
Render Velocities
速度主要用于TAA以及Motion Blur，受到移動物體的數量以及其面數的影響。主要的優化政策是使用LOD。
Screen Space Reflections
螢幕空間反射通過以下連個指令來進行調節：
r.ssr.maxroughness 0.0-1.0
r.ssr.quality 0..4其中Maximum roughness決定着計算的範圍的大小。
CPU分析
遊戲線程分析
檢視遊戲線程的性能表現的最佳工具是使用統計資料分析程式。在控制台輸入“stat startfile”來啟動分析，等10秒左右輸入 “stat stopfile”收集這10秒的平均值當然也可以等更多的時間。在路徑Saved/Profiling/UnrealStats下，會有關于您項目檔案夾的ue4stats檔案。
也可以用“STAT SLOW”來擷取實時的報告，它可以通過報告運作一幀中特定時間段(預設10毫秒)來逐漸定位幀停頓的位置。
運作速度較慢的資料将會在HUD上顯示一段時間，進而判斷性能波動。“Stat stopslow”來關閉它.
參數以秒為機關(是以10ms也就是0.01秒)參數可設定持續的時間，預設值是 10秒。
例:STAT SLOW 0.01 10這将會渲染在過去的10秒内所有運作時間超過10毫秒的循環統計資料。
現在我們需要分析，需要打開編輯器中的Session Frontend（會話前端）
當您打開了會話前端頁籤後，您需要切換到Profiler(分析程式)的小頁籤。 在該處，您可以選擇載入您最近捕獲的ue4stats分析檔案。
加載後會這樣顯示
1.這是一個渲染線程vs遊戲線程的簡圖，根據CPU邏輯與渲染的關系，一眼你就會知道你是否是CPU受限的，或者它是否是與遊戲相關的且花費最多性能的邏輯。
2.這個區域顯示了抓取期間的整個CPU加載的簡圖。在這裡，你可以沿着時間線單擊任何部分來觀察對應幀的CPU分析，或者你可以單擊、拖拽來選擇幀的範圍并且檢視均值。根據你這裡的選擇，函數時間（3）的層級清單中的分析資料會改變。
3.這是調用的不同函數和所花時間的層級清單，花費時間最長的函數排在頂端。花費最多時間的函數以紅色顯示，其它用黑色顯示。你可以通過單擊左側三角來展開對應層，你可以看到這個函數調用過程的分解以及執行花費的時間。
注意這裡的CPU停轉是CPU閑置等待其它線程結束的時間。
4.如果你在函數時間（3）的層級清單中選擇了特定的函數，你可以看到這裡的顯示變化，這裡顯示了什麼函數調用了這個函數，以及該函數調用了哪些函數，同時可以看到這些調用和被調用函數執行時間的比例。
5.左側面闆展示了stats和stat組。頂層是stat組，你可以展開它檢視内部的獨立stat。這些stat可以是整型、浮點型數字或者記憶體，你可以控制哪些顯示在stat過濾器面闆（6）中。如果你滑鼠停留在一個stat上，會彈出該stat的分析資訊（8）。
6.在這裡你可以通過搜尋想要的stat、改變分組和排序、隐藏/顯示不同類型的stat（浮點/整型/記憶體）以及啟用/禁用層級視圖控制stat面闆的顯示（5）。
7.這些控件用于顯示函數時間的層級清單和所選函數的分解資訊（4）
a. 類型——如果在圖像視圖中你隻選擇了一幀（2），你唯一的選擇就是顯示資訊那幀，但是如果你選擇了一系列幀，你可以選擇是否顯示平均時間或者花費的最長時間。
b. 視圖模式——這會改變函數時間分層的層級清單視圖（3），或者改變單純的函數清單，裡面包括這些函數的子程式包括的或排除的時間。
c. 向前、向後按鈕可以讓你在圖像視圖的不同部分之間跳轉（2）。所有你可以看到一系列資訊，之後縮小你的選擇範圍直到一個幀，然後用這些按鈕來在兩者之間切換。下拉箭頭顯示了之前的選擇。
d. 這裡的火焰按鈕是用來展開你目前選擇函數的時間層級清單的（3），用來查找花費最多時間的路徑，它也會用一個小火焰圖示來辨別該路徑。
8.滑鼠在stat面闆（5）的一個stat上面停留時，會顯示關于該stat的分析資訊，最重要的是最小值、平均值和最大值：
這裡我們隻關注幾個選項，展開GameThread(遊戲線程)項目，然後往下拉，直到您看到超過幾毫秒的“Inc Time”（包含時間）條目，而且其不包含許多子項或不包含任何子項。 同時關注一下“Calls”（調用）數列，它顯示了每幀調用的統計資料的平均次數。 不要被“CPU Stall”（CPU停滞時間）項目弄糊塗了。 它們顯示的是線程等待處理其他内容時所花費的時間，是以不是主要資料，而且僅僅會在幀頻率受限或者遊戲程序不為瓶頸時才會顯示出來。
還有一個重要項目TickFunctionTask。 此項目下是正在更新的每個actor群組件。 一般來說，降低每幀更新的actor群組件的數量都可以很好地加速遊戲。
另一個要關注的是BlueprintTime（藍圖時間）。 找到這個值的最佳方法是切換到包含（合并）視圖并在清單中找到它。 這樣就可以把所有的BlueprintTime（藍圖時間）條目組合到單一行中。 如果您選擇BlueprintTime（藍圖時間），然後切換回層次視圖，則其會選擇所有藍圖代碼被執行的位置，這樣能讓您很好地了解花費時間進行處理的位置及其位于哪個藍圖中。
另一個常見的問題位置是TickWidgets（更新控件）。 如果這個統計資料值很高，這表示您可能同時顯示了太多控件，或者這些控件上的屬性代理過于複雜。 一些slate屬性，比如可見性，可能會在每幀被調用好幾次，這樣它們的值必須要小而且能及時傳回。
您是不是在遊戲中有很多骨架網格物體？ SkinnedMeshComp更新時間有時也會消耗很多系統資源。 請嘗試降低顯示在分析檔案中的骨架中的骨骼數量，或者降低動畫藍圖的複雜度。 如果您不需要在無法看到骨架網格物體時更新動畫，請考慮将骨架網格物體元件上的MeshComponentUpdateFlag（網格物體元件更新辨別）正确設定為OnlyTickPoseWhenRendered（僅在渲染時更新姿勢）。 請注意，将此辨別設定為AnimNotifies（動畫通知）将使得這些網格物體不被渲染時不再對其進行觸發。
https://docs.unrealengine.com/en-us/Engine/Performance/Profiler 參考文檔
一些相關的工具
MergeActors(融合Actor)
合并多個Actor以及它們的材質和貼圖使其轉化成Mesh，可以減少材質數量和材質複雜程度。
DeviceProfile（裝置概述檔案）
對不同裝置設定不同的渲染參數以節省性能
RenderingDetail Mode(渲染細節模式)
設定顯示細節模式和配置
ModelLOD 設定
LOD模型不同細節，根據距離參數優化渲染效率
· CSM聯級動态陰影
CSM 陰影不會出現調制陰影中的雙重陰影，在為多個物體投射陰影時此方法速度較快。
CSM使用了額外的紋理采樣器，可通過項目設定将其禁用：
Rendering -> Mobile-> Combined Static and CSM Shadowing，即可将采樣器空出供材質使用。
線框視圖模式可以告訴你場景和獨立網格中有多少頂點和三角形，要實作這個模式，你可以在編輯器等級視口的可視化模式菜單中找到：
如果你的網格有三角形/頂點的富餘，而且遠比攝像頭的充足時，線框就會變成實線。如果你的網格不總是實線的，這意味着你有可能需要比渲染更高的複雜性，你就應該減少網格中的多邊形數量。
減少三角形和頂點的數量永遠都是提高性能的方法，但是很多時候，一個單獨網格比多個網格刻畫集合圖形的性能要好得多（一個有1000個頂點的網格可能比10個有100個頂點的網格的更新和渲染都快）。這是因為不僅這些網格可能會分别單獨調用GPU來繪制，也因為UE4會為每個網格單獨儲存和更新變換資訊，而且可能檢查這些獨立網格間的碰撞。是以，如果沒有功能性的原因來設定單獨網格的話，你應該考慮在把它們引入UE4之前在DCC工具中選擇合并它們。
關于合并網格反對的說法是：一個單獨的網格可能不能被部分剔除，是以如果它的任何一部分是可見的，整個網格都會渲染。由于這個原因，可能把你的整個關卡都合并成一個單獨網格可能不是一個好主意，但是讓每一個三角形都成為一個單獨網格同樣也不是最理想的，是以在兩種極端中取得平衡至關重要。
ViewMode檢查
當三角面密度太高（高到三角面小于2*2像素 往往發生在遠處物體上） 很容易出現問題。
分别檢視三角面、頂點、燈光數量、陰影設定、Actor數量
LOD 關閉Shadew 、燈光螢幕面積
頂點太多
點動畫的Shader處理過于複雜
Tessellation 過于複雜
多重UV、過多的SG
檢視Staticmesh Editor裡點和面數的差别是否大
點沒有合并、場景GPU粒子模拟數量過多
材質複雜度
Quality、Switch、Sin、 Pow、 Cos、Divide、Noise 這些節點很耗費資源
減少材質Shader的指令的數量。減少Texture Sample的數量：把經常使用到同一個物體上的圖案合在一張貼圖上；去掉對品質影響很小的貼圖，比如Specular、AO等。盡量使用QualitySwitch，Sin, Pow, Cos, Divide, Noise節點。多向量的計算量總是大于單向量的計算量。
遮擋的culling計算
使用預算可見性剔除遮擋的對象。
延遲燈光
當使用lightingfunction、IE、接受投影、區域光、複雜shadingmodes的時候會變得更昂貴。反射SSR如果有問題，請關掉它。另外後期AO也很耗費資源。
參考文檔：https://docs.unrealengine.com/en-us/Engine/Performance