URP下與Built-in的Light Color不一致

時間 2021-03-26

原文原文鏈接

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也能夠確認這一點。ui

2. 打開2邊工程的Scene2，這個場景的方向光Intensity值設置爲0.65。觀察2個工程裏球的光照顏色，Built-in管線的更暗，經過FrameDebugger也能夠看到Built-in管線的工程光照顏色數值小一點。spa

URP顏色：
code

Built-in顏色：
blog

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.383902285

Blue通道：
Mathf.GammaToLinearSpace(1) 0.65=1 0.65=0.65

Built-in：
Green通道：
Mathf.GammaToLinearSpace(0.792*0.65)=0.2280943

Blue通道：
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問答社區提供了回答

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問答社區提供了回答

Rendering

Q：爲了讓身體各部件合併，全部部件都要開啓Readable/Writable屬性，合併也建立新的Mesh來合併，多個部件合併成一個Mesh有什麼好處嗎？

遊戲類型是MMOARPG，好比能夠換頭髮、臉、衣服等，資源量很大，若是不合並，走掛點的方式與合併成一個Mesh會怎麼樣呢？

A：第一個問題的好處應該就是方便合批，壞處除了你說的幾點，還有貼圖的合併，這些點都會形成內存的額外開銷。是否應用仍是應該看具體的項目類型。
第二個問題其實就是內存換Draw Call，看大家項目這兩塊哪一部分是瓶頸了。另外還須要注意材質，若是各部位材質差異很大也是沒法合批的。

感謝範君@UWA問答社區提供了回答

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問答社區提供了回答