渲染統計視窗(Rendering Statistics Window)

標籤：

FPS(Timer per frame and FPS)

　　frames per seconds表示引擎處理和渲染一個遊戲幀所花費的時間，該數字主要受到情境中渲染物體數量和GPU效能的影響，FPS數值越高，遊戲情境的動畫顯示會更加平滑和流暢。一般來說，超過30FPS的畫面人眼不會感覺到卡。另外，Unity中的FPS數值僅包括此遊戲Scene裡更新和渲染的幀，編輯器中繪製的Scene和其它監看式視窗的進程不包括在內。

CPU

　　擷取到當前佔用CPU進行計算的時間絕對值，或時間點，如果Unity主進程處於掛斷或休眠狀態時，CPU time 將會保持不變。

render thread

　　GPU渲染線程處理映像所花費的時間，具體數值由GPU效能來決定。

Batches

　　即Batched Draw Calls，是Unity內建的Draw Call Batching技術。

　　CPU每次通知GPU發出一個glDrawElements(OpenGl中的圖元渲染函數)或者DrawIndexedPrimitive(DirectX中的頂點繪製方法)的過程稱為一次Draw Call，一般來說，引擎每對一個物體進行一次Draw Call，就會產生一個Batch，這個Batch裡包含著該物體所有的網格和頂點資料，當渲染另一個相同的物體時，引擎會直接調用Batch裡的資訊，將相關頂點資料直接送到GPU，從而讓渲染過程更加高效，即Batching技術是將所有材質相近的物體進行合并渲染。

　　對於含有多個不同Shader和Material的物體，渲染你的過程比較耗時，因為會產生多個Batches。每次對物體的材質或者貼圖進行修改，都會影響Batches裡資料集的構成。因此，如果情境中有大量材質不同的物體，會很明星的影響到GPU的渲染效率。

　　關於Batches最佳化相關的方案：

　　　　雖然Unity引擎內建Draw Call Batching技術，也可以通過手動的方式合并材質接近的物體。

　　　　盡量不要修改Batches裡物體的Scale，因為這樣會產生新的Batch。

 　　　 為了提升GPU的渲染效率，應當儘可能的在一個物體上使用較少的材質，減少Batches過多的開銷。

　　　　對於情境中不會運動的物體，考慮設定Static屬性，Static聲明的物體會自動進行內部批處理最佳化。

Verts

　　攝像機視野(field of view)內渲染的頂點總數。

Tris

　　攝像機視野(field of view)內渲染的三角面總數。

 　　註：儘可能的合并物體，會很大程度的提高效能。例如，情境一中有1000個不同的物體，每個物體都有10個Tris；情境二中有10個不同的物體，每個物體有1000個Tris。在渲染處理中，情境一種會產生1000個Draw Calls，它的渲染時間明顯比情境二慢。

　　　　Unity不會把模型拆分，這個模型哪怕只有1個頂點需要渲染，unity也會把整個模型渲染出來。

Screen

　　擷取當前Game螢幕的解析度大小

SetPass calls

　　之前講到Batches，比如說情境中有100個GameObject，它們擁有完全一樣的Material，那麼這100個物體很可能會被Unity裡的Batching機制結合成一個Batch。所以用"Batches"來描述Unity的渲染效能是不太合適的，它只能反映出情境中需要批處理物體的數量。那麼可否用"Draw calls"來描述呢？答案同樣是不合適。每一個"Draw calls"是CPU發送給GPU個一個渲染請求，請求中包括渲染對象所有的頂點參數、三角面、索引值、圖元個數等，這個請求並不會佔用過多的消耗，真正消耗渲染資源的是在GPU得到請求指令後，把指令發送給對應物體的Shader，讓Shader讀取指令並通知相應的渲染通道(Pass)進行渲染操作。如情境上有一個GameObject，希望能顯示很酷炫的效果，它的Material上帶有許多特定的Shader。為了實現相應的效果，Shader裡或許會包含很多的Pass，每當GPU即將去運行一個Pass之前，就會產生一個"SetPass call"，因此在描述渲染效能開銷上，"SetPass calls"更有說服力。

Shadow casters

　　表示情境中有多少個可以投射陰影的物體，一般這些物體都作為情境中的光源

Visible skinned meshes

　　渲染皮膚網格的數量

Animations

　　現正播放動畫的數量

渲染統計視窗(Rendering Statistics Window)