關於Addressable打包大小的疑問

1）關於Addressable打包大小的疑問
2）華爲機型上人物模型鋸齒嚴重問題
3）Unity 2019圖片壓縮格式選擇
4）Splash用到的紋理常駐內存
5）新版TileMap的重疊面渲染問題

---

Addressable

Q：如何獲得Addressable打出的AssetBundle的文件大小？Addressable是經過把各個資源設置到各個Group中，而Group在設置這些資源時，能夠打到一個AssetBundle仍是要分開打呢？後續實際打包AssetBundle，至關因而黑盒不透明的，但實際應該有這個需求，對於打出來的Bundle過大或者太小都不合適。我嘗試基於它的AnalyzeRule，寫自定義的檢查類，卻沒有發現跟AssetBundle有關的API。你們知道是爲何嗎？或者能知道它的Catalog相關的API也能夠。

A：能夠寫一個CustomBuildMode繼承BuildScriptPackedMode，重寫裏面的Name和DoBuild，這樣每次打包均可以看到每一個組生成的Bundle的大小，具體代碼以下：

寫完代碼後，建立一個CustomBuildMode.asset，並加入到AddressableSettings的Build And Play Mode裏面，而後就能夠進行Build並看到Bundle的大小了。

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

---

Rendering

Q：咱們的遊戲在華爲機型上的模型貼圖都很模糊，鋸齒很是嚴重，但在其它機型上就沒有這個問題。咱們在系統設置中關閉了智能分辨率，效果就好不少。你們有遇到過相似的問題嗎？怎麼解決呢？我查看華爲的官方論壇，發現這個問題彷佛是個通病。

A：1.華爲機型開啓智能分辨率，會致使遊戲運行時分辨率較低，從而致使模型貼圖都較爲模糊。在遊戲一啓動的時候讀取設備的物理分辨率，執行Screen.SetResolution強制設置分辨率就可以正常顯示。

2.如何正確地獲取設備物理分辨率？在下降分辨率以後， 經過Android API獲取到的設備分辨率都是下降以後的分辨率值。

3.嘗試以後，發現了getRealMetrics，調用這個接口獲取分辨率（下降以後的分辨率值），再經過density值判斷，若爲2，即這是被下降分辨率的值。

因此最後處理方式爲：遊戲一啓動判斷是華爲的機型設備， 經過getRealMetrics獲取屏幕分辨率，再經過density值判斷是否被智能下降了，若是值爲2，將獲取到分辨率值擴大1.5倍（基本上就是真實分辨率），而後用SetResolution設置。

用這個方法在華爲設備上測試均正常顯示（目前還沒發現顯示有異常）。

感謝極致遊戲@UWA問答社區提供了回答

---

Texture

Q：向你們請教一下關於圖片壓縮格式選擇問題。我看了以前的博客，安卓選擇的是ETC2，蘋果選擇的是PVRTC。如今項目升級到了Unity 2019.2.21f1後，多了不少格式。

請教一下下面幾個問題，Unity版本是2019.2.21f1：
1. 新版本Unity 2019 Format中安卓和蘋果的格式，該怎麼選擇？
2. 安卓如今可使用ASTC格式了嗎？市場份額是多少？
3. Resize Algorthm和Override ETC2 fallback分別表明什麼意思？以及怎麼選擇？
4. HDR、6X6和10X10，該怎麼選擇好呢？
麻煩科普下，謝謝！

A1：第一個問題，我的以爲iOS選ASTC，Android選ETC2比較好。
第三和第四個問題，我建議能夠看看官方文檔： Texture的文檔，看完這個你基本上就可以明白了。而後根據項目需求，相信可以有個比較好的選擇。
感謝李星@UWA問答社區提供了回答

A2：如今Texture新上線的項目已經開始普及ASTC的使用了，因此全面選擇ASTC，2019能夠默認import的時候選擇ASTC，尤爲是對光照貼圖和法線有很好的效果。Unity如今默認是6x6，也能夠根據項目選擇其它大小。
感謝鄭驍@UWA問答社區提供了回答

A3：如今立項的項目，iOS和安卓都應該選擇ASTC了，由於連模擬器都已經支持ASTC，咱們的項目因爲須要作PBR效果，ETC2在壓縮上的失真仍是會比較嚴重的。若是實在須要兼容原來的機器（不支持ASTC)，能夠多編譯一份ETC2的資源放到服務器上，判斷機型後再下載就好了，畢竟這部分機器不多。我本身的項目是這麼作的，後臺監控到須要下載ETC2資源的玩家也是少之又少。
感謝簡單就好@UWA問答社區提供了回答

A4：若是版本包不發東南亞、中東、非洲和南美，那基本上全均可以用ASTC了；若是要發以上舊機型多的地區，建議用Unity默認的方案（pvrtc @ ios & etc @ android）。
感謝鄭昊@UWA問答社區提供了回答

---

Memory

Q：Splash用到的紋理會一直常駐內存，應該怎麼處理？

A1：測試後發如今Unity 2017.4.33和Unity 2018.4.12中都有這個問題，並且切換場景後，仍舊不會被卸載。

能夠經過以下的方式解決這個問題：初始場景中，在腳本中引用Splash中用到的Sprite，而後強制Unload這些Sprite，能夠去除這些紋理的佔用，大體方式以下圖：

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

A2：還有個方案：不用Unity提供的遊戲內閃屏，改用平臺原生方式實現。

iOS上用Storyboard方式：

安卓上改一下Java代碼，本身放個View擋在前面。
感謝littlesome@UWA問答社區提供了回答

---

Rendering

Q：爲了讓新版的TileMap受到光照影響，替換TileMap爲LitShader，而且作了如下操做：
1. TileMap的mode爲Chunk（塊渲染）。
注：Individual模式下不存在該問題，由於每一個地塊都是獨立渲染的，可是Draw Call很高。
2. 打了一個平行光和聚光燈。

出現了問題，平行光下全部的Tile渲染正常，聚光燈渲染範圍則重疊面，渲染不正常（不一樣於zfighting），這是爲何呢？

如下爲Shader截圖：

正常渲染，僅方向光：

不正常渲染：

A：Chunk模式下作了一下測試，大概結論是在聚光燈的狀況下，重疊的部分有三個顏色疊加（一個Base Pass，兩個Add Pass）；沒有重疊的部分有兩個顏色疊加（一個Base Pass，一個Add Pass）。其中的Base Pass是由強度爲0的平行光及環境光等組成，Add Pass是聚光燈。重疊部分多了一個Add Pass的顏色，因此看起來就會「不和諧」。

先來講一下爲何會有重疊部分。假設一張128x128的紋理，按照默認100Pixels Per Unit的設置來算，這個紋理的長度爲1.28x1.28，可是TileMap的一個方格子是1x1，因此把這個紋理往格子裏放，兩邊就各多了0.14，這樣平鋪的時候就會有重疊部分了。

從上圖能夠看到，越往聚光燈強度高的地方，重疊的顏色看起來越「異常」，由於恰好多出來一份聚光燈的顏色貢獻。

上圖爲第一個Base Pass，Keyword爲平行光和球諧環境光，Blend模式爲SrcAlpha OneMinusSrcAlpha，這個紋理的Alpha爲1。這裏的繪製效果至關於Blend模式爲One Zero，後畫的顏色會徹底覆蓋先畫的顏色。所以當只有一個平行光的時候，只有這一個Pass，顏色很是和諧。

上圖爲第二個Add Pass，Keyword爲探照燈，Blend模式爲SrcAlpha One，效果至關於Blend模式爲One One，重疊的部分會把顏色往Color Buffer裏面疊加兩次。

以上是Chunk模式，對於Individual模式，發現了和Chunk模式不太同樣的地方，渲染效果以下：

從上面的圖能夠看到，豎直方向上沒有不和諧。仔細看了一下FrameDebugger，發現渲染的順序和想象的不同。

前四個渲染分別是1個Base，1個Base，1個Add，1個Add。第五個Draw Call的時候，爲 Base Pass，Blend模式變成了One Zero，因而豎直方向上重疊的部分上以前的顏色被拋棄了。因此豎直方向最終效果並無不和諧，而水平方向仍舊是重疊的部分多加了一次。
感謝Xuan@UWA問答社區提供了回答

---

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

官網：www.uwa4d.com
官方技術博客：blog.uwa4d.com
官方問答社區：answer.uwa4d.com
UWA學堂：edu.uwa4d.com 官方技術QQ羣：793972859（原羣已滿員）