知乎鏈接（部分內(nèi)容沒(méi)有更新過(guò)來(lái)）：https://zhuanlan.zhihu.com/p/28042244
0. 前言
項(xiàng)目第一次對(duì)外技術(shù)測(cè)試落下帷幕，終于有時(shí)間來(lái)填大世界動(dòng)態(tài)加載這樣一個(gè)大坑。
從去年11月份開(kāi)始，在需求改變、制作方案更改等各種影響下，斷斷續(xù)續(xù)地制作維護(hù)這個(gè)功能，估算下來(lái)花費(fèi)在它上面的有效時(shí)間也得有1個(gè)月左右。目前我們游戲大世界的制作進(jìn)入鋪量階段，已經(jīng)制作好的功能也經(jīng)過(guò)了第一次技術(shù)測(cè)試的驗(yàn)證，靜下心來(lái)寫(xiě)這篇《Unity手游開(kāi)發(fā)札記——2.5D大世界動(dòng)態(tài)加載實(shí)戰(zhàn)》。
需要說(shuō)明的是：一方面任何技術(shù)方案都有其適用范圍，相對(duì)應(yīng)的也就是它們有著自身的局限性，因此這篇文章肯定不是一顆萬(wàn)能的“銀彈”；另外一方面，在實(shí)際工程中，實(shí)現(xiàn)一段代碼、一個(gè)技術(shù)功能點(diǎn)往往是最為簡(jiǎn)單的那步，設(shè)計(jì)適合團(tuán)隊(duì)工作的工作流程，讓功能可以快速高效的產(chǎn)出結(jié)果，并且便于維護(hù)，才是工作量更大的部分。因此，正在閱讀這篇文章的你，不必抱著多大的希翼可以通過(guò)學(xué)習(xí)它實(shí)現(xiàn)你們自己項(xiàng)目的大世界動(dòng)態(tài)加載架構(gòu)，它是一篇“實(shí)戰(zhàn)記錄”——意味著這里的經(jīng)驗(yàn)經(jīng)歷過(guò)一個(gè)真實(shí)項(xiàng)目的洗禮，也意味著它們可能更適用于我們項(xiàng)目而已。
1. 需求分析和技術(shù)調(diào)研
一切都在變化，沒(méi)有東西會(huì)消失?！獖W維德：《變形記》
1.1 需求分析
“需求一直都在變化，沒(méi)有需求會(huì)消失。。。”回頭來(lái)看我們游戲整個(gè)大世界的制作方案的確定過(guò)程，我要把改編自?shī)W維德名言的這句話(huà)送給我們團(tuán)隊(duì)的策劃和美術(shù)同學(xué)，這里飽含了一個(gè)程序的吐(fen)槽(hen)。我們項(xiàng)目的需求變更主要體現(xiàn)在大世界制作方案的改變上，從2016年11月份開(kāi)始，經(jīng)歷過(guò)傳統(tǒng)3D制作方案、基于六邊形的風(fēng)格化方案、比例縮小版寫(xiě)實(shí)風(fēng)格，最后到基于Terrain的沙盤(pán)風(fēng)格。每次變更都意味著美術(shù)制作流程的變化，隨之而來(lái)的就是程序需要開(kāi)發(fā)的工具集調(diào)整。
回到項(xiàng)目立項(xiàng)初期討論的時(shí)候，當(dāng)時(shí)我們就確定了大世界的方向。其實(shí)從程序的角度能夠預(yù)估這其中的技術(shù)難度，畢竟團(tuán)隊(duì)中從策劃到程序再到美術(shù)誰(shuí)都沒(méi)做過(guò)完整的大世界項(xiàng)目。帶著初創(chuàng)團(tuán)隊(duì)初生牛犢不怕虎的勁，再加上策劃同學(xué)拍著胸脯說(shuō)“實(shí)在不行我們就用2D地圖也能接受”的允諾，就往這個(gè)方向來(lái)努力。
第一個(gè)版本美術(shù)預(yù)研的大世界效果出來(lái)之后，糾結(jié)在視角使用3D還是2.5D——2.5D的大世界制作成本和技術(shù)難度會(huì)比較低，但是從當(dāng)時(shí)的設(shè)計(jì)來(lái)看，3D的體驗(yàn)會(huì)更好，而且看得越遠(yuǎn)越好……因此最初的技術(shù)預(yù)研方向也是在往自由3D視角的目標(biāo)來(lái)做。
1.2 Unity插件調(diào)研
從程序角度，無(wú)論什么視角，針對(duì)Unity引擎做初步的技術(shù)調(diào)研是最基礎(chǔ)的工作。這時(shí)候有那么一點(diǎn)懷念之前自己掌握引擎代碼的日子，即使沒(méi)有引擎組的支持，自己在引擎C++底層來(lái)做是方法明確而且效率更高的方式。好在Unity也有自身的優(yōu)勢(shì)——Asset Store。搜索加詢(xún)問(wèn)，最后找到看著還比較靠譜的兩個(gè)插件—— SECTR COMPLETE 和 World Streamer。
World Streamer這個(gè)我沒(méi)有非常仔細(xì)去看實(shí)現(xiàn)細(xì)節(jié)，整體的思路是按照位置拆分成按照Scene組織的格子（Grid），然后根據(jù)距離做逐步加載，因?yàn)橐獏^(qū)分地表、特物體和細(xì)節(jié)物體等不同粒度，提供了分層拆分的功能。提供一篇找到的博客供需要的同學(xué)參考：《Unity 場(chǎng)景分頁(yè)插件 World Streamer 支持無(wú)限大地圖的解決方案》。
SECTR COMPLETE是我購(gòu)買(mǎi)并學(xué)習(xí)了一段時(shí)間的一個(gè)插件，原因之一是這個(gè)插件是被Unity官方推薦過(guò)的，而且FireWatch游戲就是用的這個(gè)插件，可以參考GDC的演講Making the World of Firewatch。這個(gè)COMPLETE是一個(gè)售價(jià)100美元的插件集合，它包括CORE、STREAM、VIS和AUDIO等幾個(gè)部分。VIS做動(dòng)態(tài)的遮擋剔除，動(dòng)態(tài)的大世界主要是STREAM部分。
SECTR STREAM通過(guò)自動(dòng)或者手動(dòng)創(chuàng)建Sector的方式，用包圍盒來(lái)決定場(chǎng)景中的哪些物體被放置到哪一個(gè)Sector中，然后將這些Sector導(dǎo)出為名稱(chēng)對(duì)應(yīng)的分塊場(chǎng)景，加載的時(shí)候在攝像機(jī)上添加一個(gè)Loader，通過(guò)Loader與留在場(chǎng)景中的Sector碰撞盒進(jìn)行交互來(lái)判斷哪些Sector對(duì)應(yīng)的場(chǎng)景組件需要被加載。Loader的類(lèi)型不同加載方式也不同，比如包括Neighbor Loader、Region Loader、Trigger Loader甚至DIY Loader等。
由于最終我們并沒(méi)有使用這兩個(gè)插件，因此在此不進(jìn)行更詳細(xì)的描述，有興趣的朋友可以自己買(mǎi)來(lái)玩一下。
1.3 UWA技術(shù)分享
在2016年11月份的時(shí)候，UWA組織了一場(chǎng)在上海的分享，其中有一個(gè)就是張強(qiáng)的《大規(guī)模場(chǎng)景的資源拆分和動(dòng)態(tài)加載》，很興奮地去聽(tīng)了一下，主要是2.5D視角下基于Terrian的實(shí)現(xiàn)方案，因?yàn)楫?dāng)時(shí)我們的需求方案還是傾向于3D自由視角，所以聽(tīng)的時(shí)候感覺(jué)幫助沒(méi)有那么大。當(dāng)時(shí)在回來(lái)之后的博客筆記里說(shuō)——
“我個(gè)人覺(jué)得這部分的一個(gè)問(wèn)題是整個(gè)工程是基于一個(gè)Demo性質(zhì)的實(shí)現(xiàn)，而非正式的項(xiàng)目，因?yàn)闀r(shí)間關(guān)系沒(méi)有在后面進(jìn)行深入的交流，因此也不清楚目前的實(shí)現(xiàn)是否在正式的項(xiàng)目中應(yīng)用了。”
在現(xiàn)在來(lái)看，其實(shí)張強(qiáng)的分享內(nèi)容中有很多是我在后面設(shè)計(jì)和實(shí)現(xiàn)的過(guò)程中沒(méi)有去考慮的部分，比如資源打包策略的制定等，這些問(wèn)題都是在實(shí)際項(xiàng)目中需要去注意的內(nèi)容。而當(dāng)時(shí)我想了解但這個(gè)分享不包含的內(nèi)容是大世界的制作和維護(hù)流程的部分，鑒于主題是《大規(guī)模場(chǎng)景的資源拆分和動(dòng)態(tài)加載》，其實(shí)針對(duì)這一主題已經(jīng)很有實(shí)用性了。這里也借這篇文章的機(jī)會(huì)，給UWA的張強(qiáng)同學(xué)做一個(gè)小小的道歉，當(dāng)時(shí)的評(píng)價(jià)過(guò)于草率，非常抱歉。
如果想要了解這次分享的同學(xué)可以去UWA官網(wǎng)搜索，這里給一個(gè)我自己備份的PPT下載地址。
1.4 調(diào)研結(jié)果
通過(guò)對(duì)這兩個(gè)插件和UWA分享沙龍的學(xué)習(xí)，基本確定了在Unity中制作動(dòng)態(tài)大世界的基本思路：美術(shù)制作完整場(chǎng)景 -> 自動(dòng)/手動(dòng)拆分場(chǎng)景 -> 運(yùn)行時(shí)根據(jù)規(guī)則自動(dòng)加載角色周?chē)牟糠帧?/p>
與此同時(shí)，也了解到幾個(gè)需要去注意的技術(shù)點(diǎn)：
- 光照貼圖，整個(gè)大世界使用一張Lightmap顯然不合適，SECTR STREM是支持自動(dòng)拆分的，也有一些插件支持光照貼圖的拆分，這個(gè)貌似不用太擔(dān)心；
- 尋路信息，Unity 5.6之前的版本是不支持動(dòng)態(tài)的Nav Mesh的，只能跟隨場(chǎng)景加載/卸載。既然沒(méi)有辦法更改，暫時(shí)看起來(lái)也沒(méi)有擔(dān)心的必要；
- 光照探針，這個(gè)也是不支持動(dòng)態(tài)加載的，但是初步看起來(lái)手游項(xiàng)目用這個(gè)的可能性不太大，暫時(shí)不去擔(dān)心。
2. Demo實(shí)現(xiàn)
在進(jìn)行一系列的技術(shù)調(diào)研之后，也迎來(lái)了一大波的需求調(diào)整。通過(guò)美術(shù)工作量、項(xiàng)目時(shí)間限制和技術(shù)難度評(píng)估的綜合考量之后，我們終于妥協(xié)為了2.5D視角，但是鏡頭高度會(huì)相對(duì)普通的2.5D要高不少。2.5D視角的確定讓整個(gè)功能實(shí)現(xiàn)的技術(shù)難度降低了很大一部分，也確定了自己來(lái)開(kāi)發(fā)動(dòng)態(tài)加載核心功能的技術(shù)方向。經(jīng)歷一些糾結(jié)和試驗(yàn)之后，最終選擇最為通用的基于九宮格的動(dòng)態(tài)加載方案，主要原因包括：
- 現(xiàn)成的插件雖然功能強(qiáng)大但是有各種問(wèn)題，比如SECTR STREM需要對(duì)每一個(gè)Sector創(chuàng)建一個(gè)GameObject和對(duì)應(yīng)的碰撞盒，在手游上擔(dān)心有比較大的消耗；拆分過(guò)程雖然很靈活但是需要美術(shù)進(jìn)行較多的操作，當(dāng)拆分完畢之后，如果想再進(jìn)行編輯，需要再做一遍完整的拆分過(guò)程才行;
- 九宮格的方案技術(shù)難度比較低，需要定制的內(nèi)容也相對(duì)較少，可以按照我們自己的美術(shù)制作流程來(lái)進(jìn)行定制，做到最大程度上的自動(dòng)化；
- 最后，自己造輪子不也是程序員的樂(lè)趣之一，不是么？（手動(dòng)微笑）
九宮格的方案其實(shí)很簡(jiǎn)單也很好理解，將完整的大世界按照固定大小拆分成小的Chunk，然后運(yùn)行時(shí)根據(jù)角色位置和約定好的Chunk尺寸判斷角色所在的Chunk和周?chē)藟K的索引，加載對(duì)應(yīng)的Chunk文件即可。當(dāng)角色移動(dòng)的時(shí)候，判斷是否需要加載新的Chunk和卸載老的Chunk文件。在這個(gè)階段美術(shù)還在做效果預(yù)研，所以自己先制作一個(gè)Demo來(lái)模擬整個(gè)功能。首先還是先設(shè)想了一下整個(gè)大世界的制作流程，大致如下：
- 美術(shù)完成整個(gè)大世界場(chǎng)景的制作；
- 使用自動(dòng)拆分工具，根據(jù)設(shè)置好的分塊大小，將場(chǎng)景中的每一個(gè)物體根據(jù)位置坐標(biāo)拆分到對(duì)應(yīng)的Chunk中；
- 將Chunk自動(dòng)保存成規(guī)定路徑下對(duì)應(yīng)名稱(chēng)的場(chǎng)景文件（.scene)，刪除拆分過(guò)的Chunk文件，剩下的作為BaseWorld.scene文件；
- 運(yùn)行時(shí)首先加載BaseWorld，然后在角色身上綁定一個(gè)DynamicLoader，根據(jù)角色位置自動(dòng)按照Additive的方式加載周?chē)艍KChunk對(duì)應(yīng)的場(chǎng)景。
在這個(gè)工作流程下，美術(shù)制作的永遠(yuǎn)都是完整的大世界場(chǎng)景，約定好分塊大小，只需要使用自動(dòng)拆分工具就可以更新拆分后的場(chǎng)景文件。這里關(guān)于尋路信息和光照貼圖信息的處理如下：
- 美術(shù)烘焙場(chǎng)景的單位為一個(gè)單獨(dú)Chunk的場(chǎng)景文件，即在確定本塊場(chǎng)景不修改之后再進(jìn)行烘焙工作，如果還需要修改，就需要重新烘焙，烘焙過(guò)的場(chǎng)景加入到自動(dòng)導(dǎo)出工具的覆蓋黑名單中，完整重新導(dǎo)出時(shí)不再進(jìn)行覆蓋；
- Navmesh和一些跨Chunk的全局物體（比如大面積的水域）暫時(shí)放置在BaseWorld中，運(yùn)行時(shí)BaseWorld.scene為激活的場(chǎng)景；
- 所有的光照、霧效果等信息一律放置在BaseWorld.scene中。
按照這個(gè)工作流程，需要制作的工具包括場(chǎng)景自動(dòng)拆分功能和自動(dòng)加載組件兩個(gè)部分。
2.1 場(chǎng)景自動(dòng)拆分實(shí)現(xiàn)
場(chǎng)景自動(dòng)拆分的功能比較簡(jiǎn)單，最終也僅僅實(shí)現(xiàn)了如下截圖中的幾個(gè)功能，最為核心的也就是“自動(dòng)拆分場(chǎng)景”和“導(dǎo)出拆分后的物體”兩個(gè)了。
代碼也很簡(jiǎn)單，首先遍歷所有需要處理的GameObject，我們只需要處理包含MeshRender組件和Terrain組件的物體即可。這里給美術(shù)添加了一個(gè)限制，有MeshRender的GameObject的孩子節(jié)點(diǎn)不再進(jìn)行拆分，因?yàn)闉榱吮３衷械膶哟谓Y(jié)構(gòu)，如果一個(gè)GameObject的孩子被分配到了不同Chunk，那個(gè)這個(gè)作為父節(jié)點(diǎn)的GameObject會(huì)被完整拷貝到多個(gè)Chunk中。那么，如果父節(jié)點(diǎn)包含了比如MeshRender的組件，就會(huì)導(dǎo)致較多的渲染消耗，也并不合理，因此只要包含MeshRender這樣的組件就會(huì)連著其孩子節(jié)點(diǎn)完整地放置到一個(gè)Chunk中。
// 首先使用遍歷出所有需要處理的GameObject
GameObject[] roots = EditorSceneManager.GetActiveScene().GetRootGameObjects();
List<GameObject> objsToProcess = new List<GameObject>();
foreach (GameObject root in roots)
{
TraverseHierarchy(root.transform, new ActionTransform((Transform obj) =>
{
//如果有MeshRender或者Terrain組件，并且是靜態(tài)物體，則認(rèn)為是一個(gè)要處理的葉子節(jié)點(diǎn)，不再處理其孩子節(jié)點(diǎn)了
GameObject tempObj = obj.gameObject;
if (tempObj.activeSelf == false)
{
return false;
}
if ((tempObj.GetComponent<MeshRenderer>() || tempObj.GetComponent<Terrain>()) && (!onlyStatic || (onlyStatic && tempObj.isStatic)))
{
objsToProcess.Add(tempObj);
return false;
}
else
{
return true;
}
}), false);
}
找到所有需要拆分的物體之后，直接按照位置進(jìn)行拆分即可。
// 逐個(gè)處理可能需要移動(dòng)的GameObject
for (int i = 0; i < objsToProcess.Count; ++i)
{
EditorUtility.DisplayProgressBar(progressTitle, "Processing " + objsToProcess[i].name, (float)i / (float)objsToProcess.Count);
ClassifyGameObject(objsToProcess[i], width, height);
}
/// <summary>
/// 對(duì)一個(gè)GameObject按照位置進(jìn)行分類(lèi)，放置到對(duì)應(yīng)的根節(jié)點(diǎn)下面。
/// </summary>
/// <param name="obj"></param>
static void ClassifyGameObject(GameObject obj, float width, float height)
{
Vector3 pos = obj.transform.position;
// chunk的索引
int targetChunkX = (int)(pos.x / width) + 1;
int targetChunkZ = (int)(pos.z / height) + 1;
string chunkName = ChunkRootNamePrefix + string.Format("{0}_{1}", targetChunkX, targetChunkZ);
GameObject chunkRoot = GameObject.Find(chunkName) ;
if (chunkRoot == null)
{
chunkRoot = new GameObject(chunkName);
}
//復(fù)制層次關(guān)系到Chunk的節(jié)點(diǎn)下面
GameObject tempObj = obj;
List<GameObject> objs2Copy = new List<GameObject>();
while(tempObj.transform.parent)
{
objs2Copy.Add(tempObj.transform.parent.gameObject);
tempObj = tempObj.transform.parent.gameObject;
}
tempObj = chunkRoot;
for (int i = objs2Copy.Count - 1; i > -1; --i)
{
GameObject targetObj = objs2Copy[i];
// 對(duì)于符合Chunk命名規(guī)則的父節(jié)點(diǎn)不進(jìn)行拷貝過(guò)程。
if (targetObj.name.StartsWith(ChunkRootNamePrefix))
{
continue;
}
Transform parent = tempObj.transform.FindChild(targetObj.name);
if (parent == null)
{
parent = new GameObject(targetObj.name).transform;
CopyComponents(targetObj, parent.gameObject);
parent.parent = tempObj.transform;
targetObj = parent.gameObject;
}
tempObj = parent.gameObject;
}
Transform tempParent = obj.transform.parent;
obj.transform.parent = tempObj.transform;
// 移動(dòng)完畢之后發(fā)現(xiàn)父節(jié)點(diǎn)沒(méi)有孩子節(jié)點(diǎn)的情況下，向上遍歷將無(wú)用節(jié)點(diǎn)刪除。
while (tempParent != null && tempParent.childCount == 0)
{
Transform temp = tempParent.parent;
EngineUtils.Destroy(tempParent.gameObject);
tempParent = temp;
}
}
拆分完畢之后的場(chǎng)景如下圖所示。這一步需要美術(shù)進(jìn)行一個(gè)大致的檢查，保證拆分結(jié)果的正確性。
然后將拆分后的組件保存到對(duì)應(yīng)的Scene文件中，這里為了避免遺漏拷貝場(chǎng)景參數(shù)，采用了比較trick的方式——生成每一個(gè)Chunk文件時(shí)，將完整場(chǎng)景文件進(jìn)行一次拷貝，然后刪除掉不需要的GameObject，即比如要生成_worldchunk6_8.scene，將整個(gè)場(chǎng)景文件完整拷貝，然后刪除掉除了_worldchunk6_8這個(gè)GameObject之外的所有物件。這樣就做到了所有場(chǎng)景參數(shù)的一致性，但是代價(jià)是花費(fèi)的時(shí)間稍微久一點(diǎn)。
這樣做的意義在于，比如Ambient Source相關(guān)的參數(shù)會(huì)影響烘焙結(jié)果，如果稍微有些不同，會(huì)導(dǎo)致最終烘焙出來(lái)的Chunk之間存在明顯的接縫問(wèn)題。
static void ExportChunksToScenes()
{
EditorSceneManager.SaveCurrentModifiedScenesIfUserWantsTo();
GameObject[] roots = EditorSceneManager.GetActiveScene().GetRootGameObjects();
List<string> rootsNamesToExport = new List<string>();
foreach (GameObject root in roots)
{
if (root.name.StartsWith(ChunkRootNamePrefix))
{
rootsNamesToExport.Add(root.name);
}
}
if (rootsNamesToExport.Count == 0)
{
EditorUtility.DisplayDialog("Export Error", "不存在符合導(dǎo)出要求的分組，請(qǐng)先使用自動(dòng)拆分功能！", "確定");
return;
}
if (!EditorUtility.DisplayDialog("Info", "導(dǎo)出場(chǎng)景將會(huì)刪除之前已經(jīng)導(dǎo)出過(guò)的場(chǎng)景Chunk目錄，是否繼續(xù)?", "繼續(xù)", "取消"))
{
return;
}
string sceneDir;
string sceneName;
string exportDir = MakeExportFolder("Chunks", true, out sceneDir, out sceneName);
if (string.IsNullOrEmpty(exportDir))
{
EditorUtility.DisplayDialog("Export Error", "Could not create Chunks folder. Aborting Export.", "Ok");
return;
}
string progressTitle = "導(dǎo)出拆分后的場(chǎng)景";
EditorUtility.DisplayProgressBar(progressTitle, "Preparing", 0);
string originalScenePath = CurrentScene();
int counter = -1;
foreach (string rootName in rootsNamesToExport)
{
counter += 1;
EditorUtility.DisplayProgressBar(progressTitle, "Processing " + rootName, (float)counter / (float)rootsNamesToExport.Count);
string chunkScenePath = exportDir + "/" + rootName + ".unity";
AssetDatabase.CopyAsset(originalScenePath, chunkScenePath);
EditorSceneManager.OpenScene(chunkScenePath, OpenSceneMode.Single);
GameObject[] tempRoots = EditorSceneManager.GetActiveScene().GetRootGameObjects();
foreach (GameObject r in tempRoots)
{
if (r.name != rootName)
{
EngineUtils.Destroy(r);
}
}
EditorSceneManager.SaveScene(EditorSceneManager.GetActiveScene());
AssetDatabase.Refresh();
}
// 拷貝出一個(gè)刪除了Chunk物體的Base場(chǎng)景
string baseScenePath = sceneDir + "/" + "baseworld.unity";
AssetDatabase.DeleteAsset(baseScenePath);
AssetDatabase.CopyAsset(originalScenePath, baseScenePath);
EditorSceneManager.OpenScene(baseScenePath, OpenSceneMode.Single);
GameObject[] chunkRoots = EditorSceneManager.GetActiveScene().GetRootGameObjects();
foreach (GameObject r in chunkRoots)
{
if (rootsNamesToExport.Contains(r.name))
{
EngineUtils.Destroy(r);
}
}
EditorSceneManager.SaveScene(EditorSceneManager.GetActiveScene());
AssetDatabase.Refresh();
// Cleanup
EditorUtility.ClearProgressBar();
}
拆分后的Chunk場(chǎng)景列表如下：
2.2 動(dòng)態(tài)加載組件
動(dòng)態(tài)加載的過(guò)程也并不復(fù)雜，因?yàn)樯婕暗接螒騼?nèi)的代碼，這里就不放源碼了，整個(gè)算下也也就不到500行，邏輯也很簡(jiǎn)單。綁定一個(gè)Transform，每幀update檢查T(mén)ransform的位置所對(duì)應(yīng)的Chunk的索引是否有變化，如果有則計(jì)算出需要卸載的Chunk和需要加載的Chunk執(zhí)行卸載和加載操作。
在Demo階段，選擇使用Scene來(lái)作為Chunk的存儲(chǔ)單元的原因主要有：
- 看到的兩款插件都是基于Scene來(lái)做的，而且Unity從5.0開(kāi)始就原生支持Multi-Scenes的場(chǎng)景加載方式，因此預(yù)想問(wèn)題應(yīng)該不大；
- 考慮到美術(shù)進(jìn)行烘焙的最小單元是Scene，使用Scene作為最小單元可以“偷懶”不用去手動(dòng)管理每一個(gè)Chunk的Lightmap數(shù)據(jù)，對(duì)于多個(gè)Scene同時(shí)進(jìn)行烘焙的方案也是進(jìn)行過(guò)實(shí)驗(yàn)，證明具有可行性的。
這樣，我就基于設(shè)想中的美術(shù)制作流程實(shí)現(xiàn)了第一版本的動(dòng)態(tài)加載Demo。
2.3 問(wèn)題總結(jié)
除了一些代碼實(shí)現(xiàn)上的bug之外，這里值得記錄的幾個(gè)問(wèn)題有：
1) Static Batching導(dǎo)致的頓卡
在電腦上運(yùn)行的時(shí)候已經(jīng)可以感受到明顯的卡頓，打開(kāi)Profiler看了下發(fā)現(xiàn)是由于Static Batching導(dǎo)致的：
解決方法很簡(jiǎn)單，在測(cè)試項(xiàng)目中關(guān)閉了工程的Static Batching，而在正式工程中，場(chǎng)景組件不再勾選Static Batching選項(xiàng)，就可以避免Chunk的場(chǎng)景加載時(shí)這段CPU消耗的峰值。當(dāng)然代價(jià)也是無(wú)法進(jìn)行batching，draw call的消耗比較高。
2) NavMesh分塊測(cè)試
因?yàn)椴凰佬?，所以特意做了一下NavMesh分場(chǎng)景bake之后加載的效果，果然是不行的——在其中一塊NavMesh上無(wú)法移動(dòng)到另外一個(gè)Chunk的NavMesh上：
3) 場(chǎng)景物件導(dǎo)入到Unity的時(shí)候中心點(diǎn)需要在原點(diǎn)
這個(gè)比較好理解，按照位置把物體劃分到Chunk的時(shí)候是按照世界坐標(biāo)來(lái)劃分的，如果物件的中心點(diǎn)位置并不在中心點(diǎn)的話(huà)，可能會(huì)造成偏差，這也是自動(dòng)拆分工具執(zhí)行完畢之后需要美術(shù)進(jìn)行檢查的一部分工作之一。解決方法一方面是要告知美術(shù)場(chǎng)景物件導(dǎo)入到Unity的時(shí)候中心點(diǎn)需要在原點(diǎn)這個(gè)規(guī)則，另外一方面是在代碼中使用包圍盒的中心點(diǎn)而非世界坐標(biāo)的位置來(lái)作為劃分區(qū)域，這樣可能錯(cuò)誤的概率更小一點(diǎn)。當(dāng)然，如果物件的形狀太過(guò)奇怪，包圍盒的方式也可能會(huì)有問(wèn)題。
4) 所有場(chǎng)景的Lightmap模式必須一致
在測(cè)試應(yīng)用烘焙效果的問(wèn)題的時(shí)候，出現(xiàn)過(guò)Lightmap失效的情況，檢查后發(fā)現(xiàn)是因?yàn)椴糠謭?chǎng)景使用了默認(rèn)的Directional模式，部分場(chǎng)景使用了Non-Directional的模式導(dǎo)致的。
在Demo完成之后，進(jìn)行打包和手機(jī)上的簡(jiǎn)單測(cè)試，基本滿(mǎn)足了設(shè)想的要求。這段時(shí)間場(chǎng)景美術(shù)也進(jìn)入了美術(shù)效果和制作方案的頻繁更改階段，這塊工作也就擱置了很長(zhǎng)一段時(shí)間。
3. 正式版本實(shí)現(xiàn)
最初的Demo版本沒(méi)有去考慮的一個(gè)內(nèi)容是像地表這樣的大塊Mesh是如何拆分的，原因也主要是當(dāng)時(shí)美術(shù)的制作方案是按照六邊形作為一個(gè)單元，每一個(gè)單元都不會(huì)很大，自然可以正確地被分割到不同的Chunk中。而后面改為T(mén)4M刷地表貼圖來(lái)表現(xiàn)更多細(xì)節(jié)的制作方案之后，就有了可能需要讓美術(shù)手動(dòng)拆分或者程序來(lái)做Mesh分割的需求。想來(lái)也不是很難，按照頂點(diǎn)的位置來(lái)做判斷，確定要分割的邊界之后把這些邊界上的頂點(diǎn)復(fù)制多份分別放到對(duì)應(yīng)的Chunk下似乎也就可以了。但當(dāng)這塊預(yù)研工作剛剛開(kāi)始推進(jìn)的時(shí)候，美術(shù)又改了主意，為了表現(xiàn)地面的高低起伏，想用Terrain的方式來(lái)進(jìn)行地表的制作。
技術(shù)上仍然不算什么難題，Unity有豐富的插件來(lái)做這種事情，而且相比于Unity5之后就不再維護(hù)的T4M，似乎官方的Terrain更好用也更穩(wěn)定一點(diǎn)點(diǎn)。Terrain轉(zhuǎn)Mesh的插件有不少，我們使用的是Terrain To Mesh，后文統(tǒng)一簡(jiǎn)稱(chēng)T2M。經(jīng)過(guò)思考和討論，權(quán)衡一些問(wèn)題之后，最后制定了如下圖所示的工作流程。
我們分幾步來(lái)說(shuō)明一下這個(gè)流程圖的幾個(gè)關(guān)鍵步驟的設(shè)置原因和具體的制作方式。
3.1 Chunk大小的確定
其實(shí)在這個(gè)流程開(kāi)始之前，第一件要做的事情是確定Chunk的大小尺寸。在之前Demo中構(gòu)想的流程里，因?yàn)橐曇?、美術(shù)風(fēng)格都未確定，為了能夠方便地兼容Chunk尺寸更改的情況，所有的組件都是在美術(shù)進(jìn)行了Chunk大小的設(shè)置之后自動(dòng)拆分的。這樣如果中途要更改Chunk大小，其實(shí)是一件工作量不太大的事情，只是烘焙過(guò)程要重新進(jìn)行。而基于Terrain的方案，雖然T2M也有自動(dòng)拆分的功能，但是手游上處于性能和省電的要求，我們規(guī)定——
每一個(gè)地表所能使用的貼圖層數(shù)不能超過(guò)4張，盡量保證3張的時(shí)候也是可看的，低配下程序保留了強(qiáng)制切換為3張的權(quán)利。
于是美術(shù)就要求可以更加靈活地使用和分配這幾層貼圖。由于我們大世界會(huì)有不同的地貌和氣候風(fēng)格，風(fēng)格之間還要有過(guò)度的效果，因此經(jīng)過(guò)商討，美術(shù)可以自由分配貼圖的最小單位為一個(gè)Chunk。這樣就不太好把很大一塊區(qū)域作為一整個(gè)Terrain來(lái)制作，因此我們使用了一個(gè)Chunk就是一個(gè)Terrain的方案，讓美術(shù)可以自由分配這個(gè)Chunk下的四張Layer貼圖的內(nèi)容。（這里和美術(shù)討論的糾結(jié)過(guò)程就不詳細(xì)描述了，這些瑣碎的細(xì)節(jié)可能只有真正使用這種制作方案的人才能有更深的體會(huì)。）
那么，首要的問(wèn)題就是確定Chunk的大小，而這個(gè)一旦確定，制作工作開(kāi)展之后，再修改的代價(jià)就非常大了。好在這時(shí)候鏡頭的參數(shù)早已確定，于是作為靈魂畫(huà)手的我就經(jīng)過(guò)“現(xiàn)場(chǎng)踩點(diǎn)”等精妙操作，畫(huà)了這樣一張圖。。。
考慮到我們的地表還有高低起伏，再加上為了兼容策劃后面一些變動(dòng)的可能，我們最終把一個(gè)Chunk大小定義為70m * 70m。由于我們的美術(shù)風(fēng)格還比較特殊，偏抽象沙盤(pán)的風(fēng)格，因此面數(shù)和Draw Call方面相比于3D的視角或者更加寫(xiě)實(shí)的2.5D具有更多的可壓空間，這種比較遠(yuǎn)的視野范圍在性能方面目前還可以接受。
3.2 為美術(shù)自動(dòng)生成Chunk
這個(gè)時(shí)候的工作推進(jìn)其實(shí)已經(jīng)比較順利了，因?yàn)檎麄€(gè)大世界的功能需求已經(jīng)確定，尺寸也不會(huì)很大，估計(jì)在1000m * 1000m左右的大小。Terrain在Unity中的拷貝也有點(diǎn)煩，因?yàn)樯婕暗絋errainData的拷貝，而且這貨會(huì)默認(rèn)創(chuàng)建在Assets的根目錄下，讓美術(shù)去手動(dòng)創(chuàng)建100多個(gè)Terrain對(duì)象，人力消耗暫且不說(shuō)，光是想想位置擺放精準(zhǔn)度、參數(shù)設(shè)定、資源命名和存放等問(wèn)題，就覺(jué)得可能有很多屁股要擦。。。
于是半個(gè)小時(shí)，寫(xiě)一段簡(jiǎn)單代碼，來(lái)自動(dòng)創(chuàng)建：
private static void onInitTerrain(int xNum, int yNum, float xWidth, float yWidth)
{
string folderPath = "Assets/Res/Environments/Worlds/Terrains/";
if (!System.IO.Directory.Exists(folderPath))
{
// Create new folder. Use substring b/c Unity dislikes the trailing /
AssetDatabase.CreateFolder("Assets/Res/Environments/Worlds", "Terrains");
}
GameObject parent = new GameObject("WorldTerrains");
parent.transform.position = new Vector3(0, 0, 0);
for (int x = 1; x <= xNum; x++)
{
for (int y = 1; y <= yNum; y++)
{
TerrainData terrainData = new TerrainData();
string name = "WorldTerrain" + x + "_" + y;
terrainData.size = new Vector3(xWidth/16f, 600, yWidth / 16f);
terrainData.baseMapResolution = 1024;
terrainData.heightmapResolution = 513;
terrainData.SetDetailResolution(1024, 16);
// 可以在此設(shè)置默認(rèn)貼圖
//SplatPrototype[] terrainTexture = new SplatPrototype[3];
//terrainTexture[0] = new SplatPrototype();
//terrainTexture[0].texture = (Texture2D)Resources.Load("Res/Environments/Worlds/World/terrain/caodi/world_taohuayuan_land_01.fbm/4");
//terrainTexture[1] = new SplatPrototype();
//terrainTexture[1].texture = (Texture2D)Resources.Load("Res/Environments/Worlds/World/terrain/caodi/world_taohuayuan_land_01.fbm/4");
//terrainTexture[2] = new SplatPrototype();
//terrainTexture[2].texture = (Texture2D)Resources.Load("Res/Environments/Worlds/World/terrain/caodi/world_taohuayuan_land_01.fbm/4");
//terrainData.splatPrototypes = terrainTexture;
terrainData.name = name;
GameObject terrain = (GameObject)Terrain.CreateTerrainGameObject(terrainData);
terrain.name = name;
terrain.transform.parent = parent.transform;
terrain.transform.position = new Vector3(xWidth * (x - 1), 0, yWidth * (y - 1));
AssetDatabase.CreateAsset(terrainData, folderPath + name + ".asset");
}
}
}
我只能說(shuō)，雖然那天白天就制作方案各種討論糾結(jié)，但是寫(xiě)完這段代碼之后，美術(shù)更加愛(ài)我了呢~~（可惜我們美術(shù)中沒(méi)有妹子=_=）
3.3 場(chǎng)景細(xì)化和修改
在這個(gè)工作流程中，我專(zhuān)門(mén)用淺綠色部分畫(huà)出了一次性的部分，即地形生成之后，會(huì)進(jìn)行整個(gè)大世界的地形和白模制作。一旦用自動(dòng)拆分工具拆分出Chunk文件，這一過(guò)程在之后將不再重復(fù)進(jìn)行。一方面因?yàn)檫@一過(guò)程代價(jià)很大，另外一方面后面基于Chunk和Multi-Scenes的方式也可以對(duì)地形等進(jìn)行比較方便的修改。
美術(shù)最早想在T2M轉(zhuǎn)換之后的mesh上應(yīng)用T4M來(lái)進(jìn)行地表的修改，這個(gè)方案被我否決了。因?yàn)槭紫葍煞N插件的Shader是不同的，需要時(shí)間整合（雖然到寫(xiě)這篇文章時(shí)，我們的同事已經(jīng)進(jìn)行了部分整合），其次如果再引入T4M的結(jié)點(diǎn)，使得這個(gè)工作流變得太過(guò)復(fù)雜——雖然看上去似乎靈活了，轉(zhuǎn)為Mesh之后仍然可以修改地表貼圖，但這個(gè)修改對(duì)于Terrain層是不可逆的，如果需要再在Terrain上進(jìn)行修改的時(shí)候，那些在T4M節(jié)點(diǎn)做的修改就會(huì)被沖掉。
因此，在這套工作流程中，美術(shù)進(jìn)行頻繁修改、細(xì)化、迭代的對(duì)象，是基于Terrain的地表和場(chǎng)景組件，轉(zhuǎn)換后的Mesh地表不會(huì)進(jìn)行大的改動(dòng)以保證其修改源的唯一性。
為了處理同時(shí)編輯多個(gè)Terrain的問(wèn)題，比如要保證地表的連續(xù)性、貼圖細(xì)節(jié)的連續(xù)性，我們引入了Multiple Terrain Brush這個(gè)插件到工作流程中，結(jié)合Unity原生的Multi-Scenes同時(shí)編輯的功能，可以很好地處理多個(gè)Chunk需要同時(shí)編輯的需求。同時(shí)提醒一下，注意控制相鄰Chunk相同貼圖的Tilling參數(shù)的一致性，來(lái)避免一些邊界接縫問(wèn)題。
基于Demo制作的工具，在正式的制作流程中雖然引入了T2M插件，但是之前的功能在進(jìn)行較小的修改之后也都可以正常使用。而正式的版本花費(fèi)精力最多的部分還是在流程的梳理和討論，確定每一步驟的編輯對(duì)象和產(chǎn)出結(jié)果，并驗(yàn)證整個(gè)工作流的證確性。當(dāng)然，正確性得到保證之后，性能上的優(yōu)化也就被推到最前面了。
4. 修改Chunk的存儲(chǔ)方式
在實(shí)現(xiàn)完成正式版本的工作流之后，使用正式的美術(shù)資源在設(shè)備上運(yùn)行之后發(fā)現(xiàn)了一個(gè)比較嚴(yán)重的問(wèn)題——在移動(dòng)設(shè)備上，加載Chunk的過(guò)程中，會(huì)有比較明顯的頓卡感。
通過(guò)Profiler工具進(jìn)行排查，首先看到的問(wèn)題之一是Shader.Parse()函數(shù)的消耗，在每一個(gè)Chunk的加載時(shí)占用到了200ms以上的時(shí)間，檢查了一下是由于美術(shù)在部分組件上錯(cuò)誤使用了Diffuse等系統(tǒng)材質(zhì)，并且每一個(gè)Chunk場(chǎng)景中都保留了默認(rèn)的天空盒，以及在FBX上的Default-Material中引用了Standard Shader，這些都導(dǎo)致在設(shè)備上有Shader編譯的過(guò)程花費(fèi)較多的時(shí)間。在解決完這一問(wèn)題之后，發(fā)現(xiàn)依然有頓卡的問(wèn)題，尤其當(dāng)角色在Chunk邊界來(lái)回行走的時(shí)候，由于初期沒(méi)有做緩存，幀率的降低非常明顯。下圖是在設(shè)備上截取的頓卡點(diǎn)的時(shí)間消耗數(shù)據(jù)。
經(jīng)過(guò)一些思考和方案對(duì)比，我作出了將Chunk的存儲(chǔ)方式由Scene修改為Prefab的決定，原因主要有兩個(gè)：
- 之前相信插件使用Scene的方式來(lái)做加載，應(yīng)該是有比較好效果的，然而調(diào)研的兩個(gè)插件雖然都支持mobile，但貌似并沒(méi)有找到實(shí)際在移動(dòng)設(shè)備上發(fā)布的項(xiàng)目，再加上詢(xún)問(wèn)了一些在手游做了場(chǎng)景動(dòng)態(tài)加載的項(xiàng)目，都是使用了Prefab的方案，因此覺(jué)得Prefab的方案在手游上的坑應(yīng)該更少一些；
- Scene的加載、卸載過(guò)程不如Prefab具有可控性，針對(duì)Scene對(duì)象做緩存也沒(méi)有Prefab方便。
這其實(shí)是工作量還比較最大的一次改動(dòng)了，主要原因是需要針對(duì)Lightmap進(jìn)行存儲(chǔ)。這里使用的也是Unity中動(dòng)態(tài)更改光照貼圖設(shè)置的做法，即在每一個(gè)進(jìn)行了烘焙的GameObject上添加一個(gè)Component用于存儲(chǔ)它的lightmapIndex和lightmapScaleOffset，核心的代碼參考：《Unity5.x場(chǎng)景優(yōu)化之動(dòng)態(tài)設(shè)置光照貼圖lightmap》。具體實(shí)現(xiàn)細(xì)節(jié)就不說(shuō)了，直接可以參考文章中的源碼，這里只說(shuō)明下將這一方案用于動(dòng)態(tài)加載大世界的時(shí)候需要進(jìn)行的修改和遇到的問(wèn)題。
4.1 全局光照貼圖索引的建立
在通常的動(dòng)態(tài)切換場(chǎng)景光照貼圖的實(shí)現(xiàn)方案中，只需要在更換的瞬間遍歷所有的需要更改貼圖的組件進(jìn)行更改即可，光照貼圖的索引在一套光照貼圖內(nèi)也是不變的。但是動(dòng)態(tài)加載Prefab的時(shí)候就有一個(gè)很?chē)?yán)重的問(wèn)題。
美術(shù)是按照單獨(dú)的場(chǎng)景進(jìn)行烘焙的，在每個(gè)場(chǎng)景內(nèi)都有索引從0開(kāi)始的Lightmap貼圖，而如果想要每一個(gè)Prefab的烘焙信息都是正確的，在運(yùn)行時(shí)需要所有Lightmap貼圖的索引具有唯一性，即需要提前為它們分配一個(gè)整個(gè)大世界場(chǎng)景的全局索引。
我選擇使用一個(gè)ScriptableObject對(duì)象來(lái)做這件事情，把它納入到自動(dòng)保存光照信息功能中。
[CreateAssetMenu(fileName = "WorldLightmapProfile.asset", menuName = "Custom/DynamicLightMapProfile")]
public class DynamicWorldLightmapProfile : ScriptableObject
{
public List<string> GlobalLightmaps;
/// <summary>
/// 尋找第一個(gè)為空的位置索引，作為全局光照貼圖的索引值
/// </summary>
public int AddGloblaLightmap(string lightmapPath)
{
if (GlobalLightmaps.Contains(lightmapPath))
{
return -1;
}
else
{
for (int i = 0; i < GlobalLightmaps.Count; ++i)
{
if (GlobalLightmaps[i] == "")
{
GlobalLightmaps[i] = lightmapPath;
return i;
}
}
GlobalLightmaps.Add(lightmapPath);
return GlobalLightmaps.Count - 1;
}
}
public int GetGlobalIndex(string linghtmapPath, bool autoAdd=false)
{
int idx = GlobalLightmaps.IndexOf(linghtmapPath);
if (idx > -1)
{
return idx;
}
else if (autoAdd)
{
return AddGloblaLightmap(linghtmapPath);
}
else
{
return -1;
}
}
}
/// <summary>
/// 方便管理大世界對(duì)應(yīng)的光照貼圖全局索引文件的輔助類(lèi)
///
/// </summary>
public class DynamicWorldLMProfileHelper
{
// 存儲(chǔ)全局的光照索引文件路徑
// Todo 這樣設(shè)置會(huì)導(dǎo)致全局只能使用這一份，目前還不打算兼容多個(gè)動(dòng)態(tài)場(chǎng)景，暫時(shí)先這樣。。。
private static string _worldLightmapProfile = "Assets/Res/Environments/Worlds/WorldLightmapProfile.asset";
private static DynamicWorldLightmapProfile _profile = null;
public static DynamicWorldLightmapProfile getProfile()
{
if (_profile == null)
{
DynamicWorldLightmapProfile profile = AssetDatabase.LoadAssetAtPath(_worldLightmapProfile, typeof(DynamicWorldLightmapProfile)) as DynamicWorldLightmapProfile;
if (profile == null)
{
Debug.LogWarning("沒(méi)有默認(rèn)的大世界lightmap信息的配置文件，自動(dòng)創(chuàng)建!");
profile = ScriptableObject.CreateInstance<DynamicWorldLightmapProfile>();
AssetDatabase.CreateAsset(profile, _worldLightmapProfile);
AssetDatabase.SaveAssets();
}
_profile = profile;
}
return _profile;
}
public static void ClearProfile()
{
_profile = null;
}
public static void SaveProfile()
{
if (_profile)
{
EditorUtility.SetDirty(_profile);
AssetDatabase.SaveAssets();
}
}
}
這個(gè)ScriptableObject對(duì)象中只有一個(gè)數(shù)組，下標(biāo)即全局的光照貼圖索引，值為光照貼圖的路徑。選擇exr文件的完整路徑是為了兼容Lightmap共用或者一個(gè)場(chǎng)景中存在多張lightmap的情況。（目前推薦美術(shù)一個(gè)Chunk場(chǎng)景只使用一張Lightmap，因此這種情況并不多見(jiàn)，但程序結(jié)構(gòu)上是完整支持的。）一個(gè)簡(jiǎn)單的示例截圖如下：
在每一個(gè)Chunk對(duì)應(yīng)的Prefab文件中，只有一個(gè)用于控制光照貼圖加載和刪除的ChunkLightMapSetting對(duì)象，它里面除了存儲(chǔ)直接的光照貼圖文件之外，還存儲(chǔ)了局部光照貼圖索引和全局光照貼圖索引的對(duì)應(yīng)關(guān)系。
public Texture2D[] lightmapLight, lightmapDir;
public LightmapsMode mode;
public int[] globalIndex; // 存儲(chǔ)局部光照貼圖索引和全局光照貼圖索引的對(duì)應(yīng)關(guān)系
在每一個(gè)帶有烘焙信息的GameObject身上的RendererLightMapSetting組件中存儲(chǔ)的lightmapIndex，是全局的光照信息。這樣只需要在ChunkLightMapSetting加載和銷(xiāo)毀的時(shí)候重新設(shè)置當(dāng)前LightmapSettings的屬性即可。注意由于其lightmaps屬性為一個(gè)數(shù)組，因此需要將其擴(kuò)展到當(dāng)前存在的全局索引的最大值，運(yùn)行時(shí)這個(gè)數(shù)組中間會(huì)有很多貼圖是空著的。
// 擴(kuò)充lightmap的數(shù)量到最大索引值
int maxLength = Mathf.Max(globalIndex) + 1;
if (LightmapSettings.lightmaps.Length < maxLength)
{
lightmaps = new LightmapData[maxLength];
for (int i = 0; i < maxLength; ++i)
{
lightmaps[i] = (i < LightmapSettings.lightmaps.Length && LightmapSettings.lightmaps[i] != null) ? LightmapSettings.lightmaps[i] : new LightmapData();
}
}
else
{
lightmaps = LightmapSettings.lightmaps;
}
4.2 LightmapSettings設(shè)置的幾個(gè)小坑
在使用LightmapSettings的時(shí)候感覺(jué)有幾個(gè)跟預(yù)期不太一樣的小坑。
-
LightmapSettings的lightmaps屬性直接賦值是無(wú)效的，必須
new一個(gè)新的對(duì)象數(shù)組或者將其賦值給一個(gè)臨時(shí)數(shù)組對(duì)象，修改完畢之后再賦值回去才可以。不知道是我使用的姿勢(shì)不對(duì)還是什么原因，另外個(gè)人覺(jué)得這里會(huì)有內(nèi)存分配的問(wèn)題，但是目前也沒(méi)有找到更好的解決方法。 - 當(dāng)?shù)谝粡坙ightmap為空的時(shí)候，整個(gè)場(chǎng)景會(huì)變暗很多。這個(gè)問(wèn)題一開(kāi)始遇到的時(shí)候以為是Lightmap加載的一個(gè)bug，反復(fù)觀(guān)察了一會(huì)才發(fā)現(xiàn)當(dāng)index為0的那個(gè)Prefab被卸載了之后，整個(gè)場(chǎng)景都變暗了。這個(gè)目前依然不知道原因，我們的做法是如果第0張為空的話(huà)，則選擇一張已經(jīng)存在的Lightmap貼圖賦值給它，注意這個(gè)處理要在任何一個(gè)Prefab加載或者卸載時(shí)進(jìn)行。
4.3 改進(jìn)后的工作流程
使用Prefab代替Scene來(lái)存儲(chǔ)Chunk，不但需要把之前已經(jīng)制作好的Scene轉(zhuǎn)換為Prefab，而且對(duì)于整個(gè)工作流也增加了一點(diǎn)工作量。改進(jìn)之后的工作流程如下：
對(duì)于美術(shù)來(lái)說(shuō)影響不大，只是多了一個(gè)要?jiǎng)?chuàng)建Prefab和修改之后應(yīng)用到Prefab上的過(guò)程。這個(gè)修改同時(shí)帶來(lái)的一個(gè)好處是在場(chǎng)景中可以同時(shí)存在最后使用的prefab和之前的Terrain、光照等數(shù)據(jù)了，避免了需要?jiǎng)h除再次修改不方便，或者隱藏掉導(dǎo)致打包的時(shí)候帶入包體等問(wèn)題。一個(gè)Chunk場(chǎng)景的結(jié)構(gòu)大致如下圖所示：
圖中紅框內(nèi)的是最后要保存的prefab數(shù)據(jù)，其他部分可以用于烘焙和修改用，保存在Scene中。需要說(shuō)明的是，我們的資源打包采用了拆分美術(shù)工作目錄和游戲運(yùn)行目錄的方式，美術(shù)的工作目錄為Assets/Res，游戲運(yùn)行目錄為Assets/BundleResource的方式，Res中存放所有的美術(shù)資源，但是Prefab、Scene等需要被游戲直接使用的文件存儲(chǔ)在BundleResource目錄下，打包時(shí)是根據(jù)BundleResource目錄下的所有文件，檢索出其引用到的文件進(jìn)行AssetBundle打包。在這種結(jié)構(gòu)下，Chunk拆分后的Scene文件存放在Res目錄下，Terrain數(shù)據(jù)也存放在Res目錄下，只有最后使用的Prefab文件存儲(chǔ)在BundleResource目錄下。
經(jīng)過(guò)修改為Prefab的迭代，其實(shí)使得整個(gè)工作流程更加合理。付出的一個(gè)小代價(jià)是美術(shù)在保存光照信息之后，在編輯模式下無(wú)法正常預(yù)覽烘焙的效果，需要運(yùn)行游戲來(lái)預(yù)覽。但這也可以通過(guò)添加ExecuteInEditor相關(guān)的邏輯來(lái)實(shí)現(xiàn)。（感謝錢(qián)康來(lái)同學(xué)提供這個(gè)思路~）
5. Chunk緩存
使用Prefab代替Scene之后，加載Chunk頓卡的問(wèn)題得到了一定程度上的緩解，但是仍然存在一點(diǎn)頓卡的感覺(jué)。臨近測(cè)試，這里只做了一個(gè)簡(jiǎn)單的優(yōu)化就是使用最近使用的Cache來(lái)緩存加載過(guò)的場(chǎng)景文件。思路非常簡(jiǎn)單，這里直接給出我們實(shí)現(xiàn)的LRUCache的代碼。
public class LRUCache<TKey,TValue>
{
public delegate void CacheOperation(TValue obj);
const int DEFAULT_CAPACITY = 255;
int _capacity;
IDictionary<TKey, TValue> _dictionary;
LinkedList<TKey> _linkedList;
private CacheOperation _putInOper = null; //當(dāng)放入cache中的時(shí)候要做的處理
private CacheOperation _takeOutOper = null; //當(dāng)從cache中取出來(lái)的時(shí)候要做的處理
private CacheOperation _discardOper = null; //當(dāng)由于容量有限要從cache中丟棄的時(shí)候要做的處理
public LRUCache() : this(DEFAULT_CAPACITY) { }
public LRUCache(int capacity)
{
_capacity = capacity > 0 ? capacity : DEFAULT_CAPACITY;
_dictionary = new Dictionary<TKey, TValue>(_capacity);
_linkedList = new LinkedList<TKey>();
}
public void Set(TKey key, TValue value)
{
_dictionary[key] = value;
_linkedList.Remove(key);
_linkedList.AddFirst(key);
if (_putInOper != null)
{
_putInOper(value);
}
if (_linkedList.Count > _capacity)
{
TKey lastKey = _linkedList.Last.Value;
if (_discardOper != null)
{
_discardOper(_dictionary[lastKey]);
}
_dictionary.Remove(lastKey);
_linkedList.RemoveLast();
}
}
public bool TryGet(TKey key, out TValue value)
{
bool b = _dictionary.TryGetValue(key, out value);
if (b)
{
LinkedListNode<TKey> tempNode = _linkedList.Find(key);
_linkedList.Remove(tempNode);
_dictionary.Remove(key);
if (_takeOutOper != null)
{
_takeOutOper(value);
}
}
return b;
}
/// <summary>
/// 設(shè)置針對(duì)緩存對(duì)象存取或者丟棄時(shí)的處理函數(shù)
/// </summary>
/// <param name="putin">放入時(shí)的處理函數(shù)</param>
/// <param name="takeout">取出時(shí)的處理函數(shù)</param>
/// <param name="destroy">丟棄時(shí)的處理函數(shù)</param>
public void SetOperation(CacheOperation putin, CacheOperation takeout, CacheOperation discard)
{
_putInOper = putin;
_takeOutOper = takeout;
_discardOper = discard;
}
public bool ContainsKey(TKey key)
{
return _dictionary.ContainsKey(key);
}
public int Count
{
get
{
return _dictionary.Count;
}
}
public int Capacity
{
get
{
return _capacity;
}
set
{
if (value > 0 && _capacity != value)
{
_capacity = value;
while (_linkedList.Count > _capacity)
{
TKey keyToRemove = _linkedList.Last.Value;
if (_dictionary.ContainsKey(keyToRemove))
{
if (_discardOper != null)
{
_discardOper(_dictionary[keyToRemove]);
}
_dictionary.Remove(keyToRemove);
}
_linkedList.RemoveLast();
}
}
}
}
public void ClearCache()
{
if (_discardOper != null)
{
foreach (TKey key in _dictionary.Keys)
{
_discardOper(_dictionary[key]);
}
}
_linkedList.Clear();
_dictionary.Clear();
}
public ICollection<TKey> Keys
{
get
{
return _dictionary.Keys;
}
}
public ICollection<TValue> Values
{
get
{
return _dictionary.Values;
}
}
}
運(yùn)行的時(shí)候開(kāi)辟了一個(gè)大小為5的緩存，因?yàn)榭紤]到會(huì)多占用額外內(nèi)存，并且對(duì)于九宮格的方案來(lái)說(shuō)，最壞情況下一次加載和卸載的chunk數(shù)量也就是5個(gè)。
private LRUCache<string, LoaderObjectPair> ChunkLRUCache = new LRUCache<string, LoaderObjectPair>(5);
6. 總結(jié)
我們不是第一個(gè)在手機(jī)上實(shí)現(xiàn)九宮格的項(xiàng)目，也肯定不是做得最好的那個(gè)。我花了大約兩天時(shí)間完成這篇總結(jié)，除了給一些正在做這個(gè)功能或者想做這個(gè)功能的朋友一些經(jīng)驗(yàn)上分享之外，也是對(duì)自己之前很長(zhǎng)一段時(shí)間斷斷續(xù)續(xù)在做的工作的一個(gè)總結(jié)。雖然它包含了很多細(xì)節(jié)，但是因?yàn)闀r(shí)間跨度實(shí)在有點(diǎn)久，一些討論和思考過(guò)的細(xì)節(jié)已經(jīng)遺失在了記憶中。
前面其實(shí)已經(jīng)說(shuō)了，九宮格的方案原理上非常簡(jiǎn)單，可能在需求明確的情況下，算上周邊工具，開(kāi)發(fā)的代碼量也不過(guò)幾千行，加上調(diào)試時(shí)間也可能最多2周也能夠搞定。但是在整個(gè)工作流程的構(gòu)建上，需要和策劃需求對(duì)接，和美術(shù)制作方法匹配，要考慮的問(wèn)題就多了很多，再加上可能不斷變化的需求，才有了這跨度有半年之久的工作內(nèi)容。
我想借用兩個(gè)工業(yè)界的概念來(lái)表達(dá)我在整理這篇文章時(shí)的感受——“實(shí)驗(yàn)室技術(shù)”和“工廠(chǎng)技術(shù)”。制作Demo實(shí)現(xiàn)的過(guò)程和之前學(xué)習(xí)的兩個(gè)Unity插件的內(nèi)容比較像是“實(shí)驗(yàn)室技術(shù)”，它只需要關(guān)注核心的技術(shù)實(shí)現(xiàn)，提供盡量通用的解決方案，可以做得很快很漂亮；而最終落實(shí)到項(xiàng)目中，要整個(gè)團(tuán)隊(duì)可以一起應(yīng)用起整個(gè)制作流程，這里有很多妥協(xié)，有很多一點(diǎn)也不優(yōu)美的“臨時(shí)解決方案”，要兼顧更多細(xì)節(jié)，甚至要考慮工具使用者的感受。后者的過(guò)程既無(wú)法寫(xiě)論文又不易做分享，甚至有些至關(guān)重要的細(xì)節(jié)只存在于已經(jīng)熟練應(yīng)用這一流程的每一個(gè)團(tuán)隊(duì)成員腦海中。就像富士康公司的流水線(xiàn)，看上去每一個(gè)步驟都沒(méi)有什么技術(shù)門(mén)檻，但是外人模仿的時(shí)候卻又發(fā)現(xiàn)有各種各樣的困難，達(dá)不到同樣的效果，又或者效率低下。在游戲開(kāi)發(fā)中，這兩項(xiàng)技術(shù)相輔相成，缺一不可，“實(shí)驗(yàn)室技術(shù)”負(fù)責(zé)提供詩(shī)和遠(yuǎn)方的大方向，“工廠(chǎng)技術(shù)”負(fù)責(zé)腳踏實(shí)地地把技術(shù)應(yīng)用到團(tuán)隊(duì)生產(chǎn)中。而我，作為一個(gè)一線(xiàn)開(kāi)發(fā)人員，可能接觸和思考更多的是后者，因此這篇文章涉及到的高大上的“實(shí)驗(yàn)室技術(shù)”很少，更多的是期望把那些開(kāi)發(fā)中瑣碎的“工廠(chǎng)技術(shù)”的經(jīng)驗(yàn)盡可能地記錄下來(lái)，分享出去。
至于未來(lái)的工作，大世界動(dòng)態(tài)加載這塊還有很多問(wèn)題要解決，比如第一次加載Chunk時(shí)的頓卡，為了降低DrawCall是否需要在加載時(shí)進(jìn)行一次合批過(guò)程（目前我們大世界場(chǎng)景的DrawCall在100~150左右）等等。這些問(wèn)題等到解決后會(huì)再補(bǔ)充一篇后續(xù)的文章進(jìn)行記錄和分享。
最后，感謝花時(shí)間閱讀到這里的朋友，希望你可以從這篇文章中有所收獲，也希望有經(jīng)驗(yàn)的朋友給一些改進(jìn)的建議和分享~感謝！
2017年7月 于杭州濱江海外高層次人才創(chuàng)業(yè)基地
