1）URP下與Built-in的Light Color不一致
2）開啓MSAA的RenderTarget會對沒開啓MSAA的RenderTarget造成影響
3）角色Mesh合併的優點與缺點
4）NGUI渲染層級的原理
5）Unity上App圖標安裝到設備上圖標模糊，設置上的注意點
這是第234篇UWA技術知識分享的推送。今天我們繼續爲大家精選了若干和開發、優化相關的問題，建議閱讀時間10分鐘，認真讀完必有收穫。
UWA 問答社區：answer.uwa4d.com
UWA QQ羣2：793972859（原羣已滿員）
Rendering
Q：發現Light的Intensity在不爲1的情況下，光照的顏色在URP下滑Built-in管線下不一致。附件裏有2個工程，使用Unity 2019.4.11f1，分別是URP和Built-in管線的（都是線性空間）。（附件可戳原問答下載）
再現方法：
1. 打開2邊工程的Scene1，這個場景的方向光Intensity值設置爲1。觀察2個工程裏球的光照顏色，是一致的，通過FrameDebugger也可以確認這一點。
2. 打開2邊工程的Scene2，這個場景的方向光Intensity值設置爲0.65。觀察2個工程裏球的光照顏色，Built-in管線的更暗，通過FrameDebugger也可以看到Built-in管線的工程光照顏色數值小一點。
URP顏色：
Built-in顏色：
URP FrameDebugger：
Built-in FrameDebugger：
A：用樓主Demo裏面的Light的顏色做了一下計算，在Light設置項裏面，Light Color爲（0，202，255），202.0/255 = 0.792。
SRP：
Green通道：
Mathf.GammaToLinearSpace(0.792) * 0.65=0.5906189 * 0.65= 0.383902285Blue通道：
Mathf.GammaToLinearSpace(1) * 0.65=1 * 0.65=0.65Built-in：
Green通道：
Mathf.GammaToLinearSpace(0.792*0.65)=0.2280943Blue通道：
Mathf.GammaToLinearSpace(0.65)=0.3800563應該是下面兩段數值的計算區別：
GammaToLinearSpace(m_ColorFilter * m_Intensity);
GammaToLinearSpace(m_ColorFilter) * m_Intensity;查詢發現是由於GraphicsSettings.lightsUseLinearIntensity這個數值不一樣導致的。在SRP裏面這個數值是True，在Built-in裏面是False。
感謝Xuan@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5fed681710a17c6c2b09d7db
Rendering
Q：在同一幀中，我有用於渲染的RenderTarget開啓了MSAA，和用於熱扭曲效果的扭曲Buff，是一張沒有開啓MSAA的RenderTarget，在後處理中這張扭曲Buff會用來偏移UV，以實現扭曲效果。在PC上和iOS上一切正常，但是在Android真機上出現異常。在高通GPU上，這張扭曲Buff會導致屏幕出現網格狀的現象，在Mali GPU上會出現各種細碎的小黑方塊，應該是一個未知原因導致扭曲Buff上的數據被處理成我不期望的狀態。
如果我把其他的RenderTarget的MSAA關閉，這種現象就會消失，也就說開啓MSAA的RenderTarget會對沒開啓MSAA的RenderTarget造成影響，且僅僅是在Android真機上出現，不同的GPU表現還不一樣。有遇到類似問題的嗎？求解。
A：該問題已經解決了。我所遇到的問題的最終情況，不是開啓MSAA的RenderTarget會對沒開啓MSAA的RenderTarget造成影響。在開啓MSAA後，主相機的RenderTexture（MSAA）綁定到Shader上，會有類似如下操作：
texture(_Main_Tex, UV + Offset)不知道是Unity的Bug還是其他原因，導致在Android真機上，綁定到Shader上的RenderTexture一定不是經過有效ResolveAA的版本，所以在如上操作的時候就出現異常表現，類似細碎方塊或者網格等等現象，如果Offset是0，不會有異常表現，這些應該和Mobile GPU上的TBR有關係。
那麼我需要在Android真機上傳入一張經過有效ResolveAA的RenderTexture即可。經過驗證，使用如下方式可以解決：
RenderTexture.Blit(Rt_msaa, Rt_no_msaa);這樣我就得到一張經過有效ResolveAA的Rt。
感謝題主yangkang@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5ff28a3f10a17c6c2b09d80d
Rendering
Q：爲了讓身體各部件合併，所有部件都要開啓Readable/Writable屬性，合併也創建新的Mesh來合併，多個部件合併成一個Mesh有什麼好處嗎？
遊戲類型是MMOARPG，比如可以換頭髮、臉、衣服等，資源量很大，如果不合並，走掛點的方式與合併成一個Mesh會怎麼樣呢？
A：第一個問題的好處應該就是方便合批，壞處除了你說的幾點，還有貼圖的合併，這些點都會造成內存的額外開銷。是否應用還是應該看具體的項目類型。
第二個問題其實就是內存換Draw Call，看你們項目這兩塊哪一部分是瓶頸了。另外還需要注意材質，如果各部位材質差別很大也是無法合批的。
感謝範君@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5fe0064510a17c6c2b09d6fe
NGUI
Q：Unity Shader判斷層級關係的唯一標準是否是深度測試？我看NGUI的Shader並沒有ZTest配置並且關閉了深度寫入，那應該是根據渲染的先後順序來控制層級？也就是說sortOrder sortLayerName renderQ camera depth都只是Unity在控制不同組件進入渲染流水線的順序嗎？
A：深度測試在傳統的渲染管線裏，是發生在Fragment Shader之後（不考慮Early Z等優化技術），用來剔除那些被遮擋的像素。本身和Draw Call提交的順序沒有關係。
Unity引擎中，有很多參數能決定渲染順序，也就是Draw Call提交順序。
首先最高優先級的是Camera，引擎中的渲染是由Camera發起的，在Built-in管線中，主要依靠Camera的Depth來決定哪個Camera看到的物體先渲染。最常見的結構，比如Depth=0的相機畫場景，另一個Depth=1的相機畫UI。但是，現在URP裏的相機的Camera Stack也是類似的結構，用來控制Camera的渲染先後順序。
然後是RenderQueue，這個用來決定物體的渲染順序。例如，內置的Opaque和Transparent等等，具體可以看Unity的文檔，這個值就是越小的物體越先畫。同一個RenderQueue裏，不同類型的物體渲染順序也是有一定規則。比如，引擎默認的排序規則下Opaque的物體一般是從前往後渲染，而Transparent的物體爲了保證渲染的正確性，是需要從後往前渲染的。
SortingLayer和OrderInLayer之類的主要用在UGUI Canvas上，能影響UI的渲染順序。
另外，問題中有提到UI的Shader中沒有配置ZTest，關閉ZWrite，這也是正常的，具體開什麼關什麼，是要根據渲染的物體的類型決定的。因爲UI排序一般由UI系統內部的一些參數決定，是和深度無關的。常規的一些透明物體也是會關閉ZWrite，只保留ZTest的。
感謝範君@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5fed6be210a17c6c2b09d7de
Editor
Q：Unity上App圖標安裝到設備上圖標模糊，設置上有什麼特別注意的嗎？
A1：請題主查下Unity的Import Settings，這個是對打在包裏的圖標文件也有作用的，可以將這些圖標的Import Settings中的壓縮去掉。
感謝芭妮妮@UWA問答社區提供了回答
A2：補充一下，也需要注意本身圖標的設置。我們因爲是導出工程，所以使用的圖標資源其實是跟安卓版本一致有多個分辨率版本。
感謝ZeaLotSean@UWA問答社區提供了回答，歡迎大家轉至社區交流：
https://answer.uwa4d.com/question/5ff5225910a17c6c2b09d8f6
圖片來源於網絡
今天的分享就到這裏。當然，生有涯而知無涯。在漫漫的開發週期中，您看到的這些問題也許都只是冰山一角，我們早已在UWA問答網站上準備了更多的技術話題等你一起來探索和分享。歡迎熱愛進步的你加入，也許你的方法恰能解別人的燃眉之急；而他山之“石”，也能攻你之“玉”。
官網：www.uwa4d.com
官方技術博客：blog.uwa4d.com
官方問答社區：answer.uwa4d.com
UWA學堂：edu.uwa4d.com
官方技術QQ羣：793972859（原羣已滿員）