【厚積薄發】如何優化WaitForGPU？

原標題：【厚積薄發】如何優化WaitForGPU？

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

渲染

Q：最近做一個VR的Demo，使用Unity 5.6.3版本開發，發現當近距離觀察模型細節的時候突然就變得特別卡頓，幀率從95FPS降到了45FPS，如下圖：

圖示為正常距離觀察模型沒有問題，幀率正常。

圖示為近處觀察模型時，幀率下降嚴重，VR.WaitForGPU佔比很高。想請教大神，為什麼近距離觀察會導致VR.WaitForGPU這一項升高呢？

UWA：估計是ALU的問題使得GPU壓力過大，其根本原因還是模型上Fragment Shader的指令集過高，從而導致渲染的Pixel數量越大，其GPU開銷就越高，類似於我們在UWA Day 2018上關於Standard Shader的屏占實驗。在低端設備上，屏佔超過20%，其GPU耗時就已經超過20ms。

WaitForGPU過高，說明此時GPU是性能瓶頸。對此，建議題主檢測下自己的情況是否如此。

製作

Q：Unity官方的描述如下：Swap UV channels in your Meshes. Use this option if your diffuse Texture uses UVs from the lightmap. Unity supports up to eight UV channels but not all 3D modeling applications export more than two.

不過我不太理解該描述，我自己嘗試時，無論是否使用了Lightmap，這個選項勾選或不勾感覺模型都沒有什麼變化。請問在什麼情況下需要勾選呢？它交換UV通道的意義是什麼？

UWA：之前的document里的描述：

Swap UV：Use this if lightmapped objects pick up the wrong UV channels. This will swap your primary and secondary UV channels.

現在的描述里有：Use this option if your diffuse Texture uses UVs from the lightmap.

看起來像是Lightmapped模型出現貼圖混亂的時候才用的，，例如從某些建模軟體（例如blender）導入的帶多個uv通道的模型。

渲染

Q：用DrawMeshInstanced這個API來渲染多個物體的時候，應該怎麼給每個物體指定不同的顏色？這個介面的參數裡面有個MaterialPropertyBlock，但卻不是數組，不能指定多個顏色。

UWA：如果不是通過這個介面，而是放置物體在場景里，那麼確實可以給每個物體指定不同顏色屬性的MaterialPropertyBlock來實現。

但如果用這個介面，那麼只能指定一個MaterialPropertyBlock，所以可以嘗試指定一個數組，比如SetFloatArray，然後在Shader里通過數組裡的值來取（或者計算）各自對應的值，作為顏色。

製作

Q：大家熟悉模型合併或角色換裝嗎？當使用兩次合併後，第二次合併後的UV不對，有什麼辦法解決嗎？

比如，我們A(aMat)，B(bMat)，C(cMat)，D(dMat)四個部件：

1） 第一次使用CombineMesh(coms,true,false)合併 A、B、C網格(combineMesh1)並且整合材質 atlasMat。

2) 第二次使用CombineMesh(coms,false,false)合併combineMesh1，D 網格(combineMesh2)並且移動材質到同一個Renderer。

最後ABCD被全部整合到combineMesh2，Renderer的材質變成2個(atlasMat + dMat)。我現在的問題是，dMat的UV顯示不正常，請問會是什麼問題呢？

A：如果Mesh只有一個，多個Material會有問題。

另外，顯示不正常是因為一套UV對應了兩套貼圖。

要麼把D Mesh的UV改到UV1(UV2、UV3、UV4)上，但是需要改dMat的Shader，而且會增加DrawCall。

要麼連同dMat的貼圖一起合併到atlasMat上。

感謝凱奧斯@UWA問答社區提供了回答，歡迎大家轉至社區進行進一步交流。

粒子系統

Q：我用的是Unity 2017.1.3版本，特效人員在粒子系統上使用了trails模塊，然後為了形成拖尾要使用world space，結果在遊戲中發現整個粒子包圍盒計算出了問題，導致剔除操作時出錯。而且是離原點越遠偏差越大，特效在原點就沒偏差。請問有沒有解決的方案？

特效文件已經上傳

UWA：我找了一個採用CullingGroup的方案，你看看是否滿足要求。解決思路是用CullingGroup的可見性來裁剪粒子系統，具體做法如下：

1）在粒子系統的坐標位置放置一個CullingGroup，並設置其好包圍球的半徑；

2）利用CullingGroup的可見性以及onStateChanged事件來更新粒子系統的可見性。

今天的分享就到這裡。當然，生有涯而知無涯。在漫漫的開發周期中，您看到的這些問題也許都只是冰山一角，我們早已在UWA問答網站上準備了更多的技術話題等你一起來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之「石」，也能攻你之「玉」。

本文封面圖來自網路

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！