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