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