如何設計渲染等級？

最新 04-29

這是第108篇UWA技術知識分享的推送。今天我們繼續為大家精選了若干和開發、優化相關的問題，建議閱讀時間15分鐘，認真讀完必有收穫。

渲染

Q：現思考如何設計項目中的渲染等級，求有經驗的大佬指個方向，例如ShaderLOD，還有其他什麼思路嗎？謝謝！

A：整理了一下我們遊戲中效果分級的內容，供參考：

感謝賈偉昊@UWA問答社區提供了回答，歡迎大家轉至社區進行進一步交流：

https://answer.uwa4d.com/question/5acc208b425802635474fc7d

渲染

Q：我用2017.2.0渲染一張地圖，為什麼在小米4上Camera.Render會有很高的耗時？一個空場景，為什麼Camera.Render耗時這麼高？

UWA：我們做了一個簡單測試來研究一下這個問題，即在場景中只渲染一個Cube。

機型：

（1）華為6Plus

（2）小米4

Profiler截圖如下，藍色框：華為6Plus 紅色框：小米4

由上圖可知，小米4的Camera.Render耗時不穩定，有時候會出現10+ms的峰值。

通過查看Unity Profiler以及和其他設備進行對比，發現了以下兩點是造成小米4上耗時不穩的原因：

1、Culling不穩

下圖為小米4和華為6Plus設備上，Culling操作的耗時比較。藍框為華為6Plus設備，紅框為小米4設備。通過Timeline可以看到是場景SceneNode的計算導致。

2、Drawing不穩

渲染耗時也同樣不穩定，如下圖所示：通過Timeline發現，小米4設備上，主線程的渲染進程會經常等待子線程完成後再進行後續操作，而同樣的App，在華為6Plus上則不會如此表現，如下圖所示。

小米4：

華為6Plus：

因此，對於上述測試做個總結：

（1）Culling中的SceneNode計算操作在小米4設備上經常伴隨更為耗時的CPU開銷；

（2）小米4上更容易表現出主線程渲染等待子線程的情況。

以上兩點是題主問題的主要原因，但至於更深層次的解釋，這個恐怕要聯繫手機研發廠商甚至底層晶元硬體廠商了。但需要說明的是，這僅是一個簡單測試例子的表現情況，複雜場景並不一定同樣適合。但測試和分析方法都是不變的，題主後續如有需求，可自行測試尋找答案即可。

歡迎大家轉至社區進行進一步交流：

https://answer.uwa4d.com/question/5ada00363dba2a108c7e3236

渲染

Q：我們用的Unity 5.5場景帶有2級LOD，我們使用Lightmap渲染場景，結果次級的LOD模型渲染出來的陰影面是純黑的，這個該怎麼辦呢？煩請大神指點！

UWA：Untiy官方在5.5版本里其實是不支持LOD的Lightmap的，即便是到了2017.4版本里，官方文檔也是讓你去使用Light Probes：

https://docs.unity3d.com/Manual/LODForBakedGI.html

當然它也說到：

「When you use the Progressive Lightmapper, there is no need to place Light Probes around the LOD Group to generate baked indirect lighting. However, to make Realtime GI affect the Renderers in the LOD Group, you must include the Light Probes.」

我們也是在用Unity 5.5版本，沒有試過Progressive Lightmapper，不知道效果如何。所以第一個解決方案是升級到Unity 5.6或者Unity 2017嘗試下Progressive Lightmapper。

如果想在Unity 5.5的下面做，我們是使用手動拷貝烘焙後的scale和offset的方式來實現，就是在運行時將原始模型的光照題圖信息完整地拷貝給LOD低層級的模型。但是這有一個非常強的限制：要保證兩個模型的UV2是完全可以對應上的，否則UV2可能會出現一些錯亂。使用Simpylgon這樣的中間件可以做到盡量保持UV2不變。

這樣做有兩個問題：

如果是減少了很多面的模型，比如刪除掉了一個組件，結果組件露出來的面因為之前是被遮擋的，會是黑色的。不過大部分情況下減面很多的LOD模型也會距離很遠，這種通常可以接受；

運行時設置光照信息的材質不能進行靜態合批，否則在設備上會有問題。

另外還有一個就是因為是運行時修改的，所以在編輯器模式下如果不讓設置組件可以運行的話，會有預覽效果不對的問題，運行狀態下可以保證正確。

原始LOD0烘焙效果：