技術分享連載（八十六）

Q1：在手機上測試LoadLevelAsync和LoadLevel的加載速度，同一個場景，LoadLevelAsync要比LoadLevel多花費40%左右的時間，請問這是正常的麼？LoadLevel會有卡頓，導緻Loading進度條不平滑，但是LoadLevelAsync好像又會增加Loading的時間？

我項目中場景動态加載的做法是，是把物件做成Prefab，然後根據主角的位置做動态加載相應的Prefab，用的是Resources.LoadAsync方法。現在加載一些比較大的物件時，在紅米2等低端機上，仍然比較卡，要消耗200ms以上。請問有什麼好的方式，能平滑這個加載過程麼，謝謝！

LoadLevelAsync一般情況下是要比LoadLevel慢的，但是否要慢40%，這個其實是根據每個場景所要加載的不同量而定的，并不是确數。 LoadLevel和LoadLevelAsync其實最本質的差別，是前者一定要在下一幀結束前完成加載操作，是以當加載場景較大時，其随後的單幀開銷就會很大，而後者則沒有這個限制，引擎可以根據目前的使用情況或者ThreadPriority（這個值是是否對LoadLevelAsync有影響，還沒做過具體實驗，但對于LoadAsync确實有影響 ）來自行調控。 但還需要說明一點的是，不是說使用Async，它就一定是絕對平滑，下圖紅框是LoadLevel，綠框是LoadLevelAsync操作。

關于真正“平滑”異步的加載方式，Unity引擎目前還是沒有的。在遇到較為複雜的Prefab（比如大紋理、多AnimationClip等等）時，其加載依然會出現卡頓。如果想要緩解該問題，建議如下： （1）先定位具體是哪個Prefab加載造成的CPU耗時較高； （2）檢視該Prefab中是否含有大量加載耗時開銷（比如大紋理、較多AnimationClip、較多Shader等等）； （3）定位後嘗試将其進行前期預加載，進而緩解該Prefab加載時的局部高開銷。

該問題來自UWA問答社群，如您對該問題仍有疑問，可以轉至社群進行進一步交流。

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

Q2：我使用了IL2CPP後是否還存在Mono記憶體呢？使用IL2CPP後，通過Profiler工具擷取的managedObject（例如： int32[]）是哪種記憶體？

可以簡單地認為，Il2CPP隻是替換掉了Mono的虛拟機實作，是以該配置設定堆記憶體的地方還是會一樣的配置設定（可能會有某些細節的地方不一樣）。 IL2CPP在堆記憶體配置設定方面和Mono 最大的不同主要是Reserved Total 是可以下降的，而 Mono的 Reserved Total 隻會上升不會下降。

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

Q3：場景自動烘焙的導航網格資訊儲存在 NavMesh.asset 中，打開可以可以看到資料如下：

項目需要在伺服器上進行尋路，希望有大牛幫忙解析這個資料，還原成 recast 用的導航網格。Unity版本是 5.5.1，Unity 4.2版本的解析代碼是有的，新版本格式變了。

首先用 NavMesh.CalculateTriangulation 擷取所有的頂點和索引資料，這個是完整的、建構過的NavMesh，包括了多邊形資訊（最大邊數為6邊型的凸多邊形），但是這個資料中所有的多邊形是不共邊的（多邊形的邊是重複資料），是以需要首先合并重複的邊，可以利用 RacastNavigation提供的代碼，基于 rcBuildPolyMesh 增加一個修改版本（比如叫：rcBuildPolyMeshBySeparatePolyTriangle），目的是合并已有的多邊形的重複邊，這一步結束後，就可以借用 RacastNavigation 剩餘的建構流程： 1）建立 NavMesh并使用以上的 PolyMesh 初始化 (dtCreateNavMeshData, dtNavMesh::Init); 2）根據已有的 NavMesh 更新包圍盒； 3）根據現有的 NavMesh 将每一個 Tile 寫入檔案（這之前可以寫入自定義的檔案頭資訊，友善讀取）; 4）伺服器讀取存儲的資料，并用來初始化生成 NavMesh，就可以 findpath 了。（也可以将這個資料導入 RacastNavigation 的 Demo 中檢視可視化情況）。 以上 1-4 是RacastNavigation示例中建構流程的一部分，重點是 rcBuildPolyMeshBySeparatePolyTriangle 這一步合并多邊形即可。這麼做的好處是，導出的 NavMesh，跟 Unity 裡建構的，多邊形資訊是一模一樣的。想要支援 DetailMesh，估計還不行。 另外，伺服器直接用可能還有點問題，如果 Unity 導出的資料很多細長的三角形，那麼RacastNavigation的結果會和 Unity出現很大的差異，需要稍微修改下RacastNavigation的代碼 。 我之前記錄了個不太詳細的描述，僅供參考：http://www.cnblogs.com/yaukey/p/recastnavigation_unity_optimize_visible_result.html

該問題來自UWA問答社群，感謝 Yaukey提供了回答，如您對該問題仍有疑問，可以轉至社群進行進一步交流。

https://answer.uwa4d.com/question/59f93d2aa740da296dd03662

Q4：目前我在用的Unity版本是2017.1.0f3 for MAC，在iOS平台下Bake Environment Reflections的時候丢失HDR資訊，操作步驟如下：

1、當我使用Standalone Platform時，我使用了一張帶有HDR的SkyBox CubeMap貼圖（預設壓縮方式BC6H），通過它生成的ReflectionProbe-0.exr會給物體帶來明顯的一個高光效果，如圖所示：

2、當切換到iOS Platform後，再次用同樣的SkyBox CubeMap貼圖（壓縮方式為PVRTC，或不壓縮RGB24 bit都試過）烘焙ReflectionProbe-0.exr時，發現這個效果消失了，如圖所示：

3、此時，如果我把之前的那張Standalone下面生成ReflectionProbe-0.exr替換過來，可以獲得跟Standalone下一樣的高光效果。把該工程釋出到iPhone 7P上運作，效果與“步驟一”中一緻。 說明ReflectionProbe-0中的HDR資訊得到了保留。但是我注意到，在iOS Platform下面，ReflectionProbe-0的預設壓縮方式是PVRTC或RGB 24 bit，這兩種方式都無法保留HDR資訊。如圖所示：

4、通過對比兩張ReflectionProbe-0.exr貼圖，發現他們的檔案大小是不同的，Standalone下面的貼圖要大一些。如圖所示，請問這是Unity的Bug嗎？

我在此上傳了示例工程：exr_EnvRef_iOS.zip，預設是PC Standalone，需要手動切換一下Platform，切換後重新Generate Lighting。

用題主的工程檔案嘗試了一下，的确是出現同樣問題，并且在Android平台也是一樣。目前看來隻能判斷是Reflection-Probe烘焙時使用了兩套不同的操作。 再提供一個線索，用renderdoc->texture viewer可以檢視像素值：

Standalone（PC）

Android 從上圖可以看到相似區域Standalone比Android的烘焙結果數值要高出許多。 該回複由UWA提供。

我在Unity 5.6下發現效果是一樣的，結論和題主一樣：Mobile平台下Bake出來的Probe是LDR的。他是通過放大亮度來做的，但其實有更簡單的辦法：看高mip就行，首先是PC模式下Bake的。

然後是Android下Bake的：

出現亮度差別的原因是PC上有亮度>1的像素(一般是太陽之類的) 然後在卷積的時候就值大一些；而Android下就相對值低 在mip=0的情況下大家都是0-1看不出(顯示時候截斷了) ，目前的結論就是在移動平台Bake的Probe依然是LDR的，這是有問題的…臨時解決方案就是在Standalone上Bake完複制過來。 感謝錢康來提供了以上解答。

題主補充：有了新的發現，基本上可以确認是Bug了。兩張reflectionProbe-0.exr貼圖的确不一樣！除了尺寸之外，切換到iOS平台後生成的exr丢失了高光部分的HDR資訊。

這兩張圖檔初看沒什麼不一樣的：

調整exposure，令exposure變為-5 （我用的是openexr，也可以用ps直接調整曝光度）：

可以看到上圖有兩個非常明顯的光斑，這個光斑的亮度非常高，是以會在物體上産生非常強的亮度。然而，在iOS Platform下面進行烘焙的時候，Unity把這個資訊給丢失了。但不是所有的exr都會出現這樣的問題。隻有那些具有局部強光源的HDR圖檔才會出現這種情況，例如樓主用的那張，還有這張圖檔： http://gl.ict.usc.edu/Data/HighResProbes/probes/grace-new.exr

原文出處：侑虎科技

本文作者：admin

轉載請與作者聯系，同時請務必标明文章原始出處和原文連結及本聲明。