開發背景

得益於“元宇宙”概念在前段時間的爆火，各家公司都推出了使用 3D 場景的活動或頻道。

3D 場景相比傳統的 2D 頁面優點是多一個維度，同屏展示的內容可以更多，能完整的展示物體、商品的信息。

相應帶來的缺點是用戶使用方式改變，用戶需要額外的學習成本。另外初期需要的開發量、美術資源和生成3D模型的設備也是增加的成本。

在這樣的背景下，我們團隊接到了食品頻道的一個互動項目的開發需求，希望通過 3D 場景的展示和互動方式，作爲對未來購物的一種嘗試與探索，滿足用戶對未來美好新奇的一個需求。將購物場景化、娛樂化，給用戶帶來美好的購物感受。

前端框架選擇

3D項目相比之前的2D項目改變的主要是客戶端的表現。在希望不依賴app客戶端支持和在儘量多的環境下能運行，我們首先採用的方案是在 Web 端實現 3D 項目。

開發套件

首先我們考慮的是成熟的開發套件，如unity/egret等，但這些開發套件都有一些我們不能繞過的問題，例如：

商業化使用需要收費
需要使用其他語言開發（如 C# ），對團隊學習成本較大
打包輸出的文件大小過大
官方文檔不夠詳細，學習曲線較抖

引擎名稱/對比維度	使用價格(權重50%)	腳本上手(權重30%)	場景搭建(權重20%)	支持模型格式(權重10%)	社區資料豐富程度(權重30%)	支持web端發佈(一票否決)
Unity 3d	3	7	10	8	10	Y
Laya	4	9	7	7	7	Y
Egret	10	8	7	7	6	Y
Cocos2d-js						N
Godot	10	7	7	8	7	Y

由於以上的原因，開發套件裏沒有令團隊很滿意的選擇，我們從其他方向尋找開發工具。

開源渲染庫

另外也比較了 Web 前端使用量較多的兩個 3D 渲染庫：

three.js 提供的組件粒度較小，較基礎，能做很高程度的定製化二次開發，但如果需要開發一個互動項目，需要開發的組件比較多
babylon.js 既提供了粒度小的基礎組件，也封裝了接近開箱即用的組件。並自帶了性能測量工具，提供了方便的debug方法和優化策略

經過團隊內對各個開發套件/渲染庫的試用，最後選擇了 babylon.js 作爲項目的渲染層庫，在其提供的組件上二次開發業務邏輯。

項目場景搭建

渲染分層結構

項目渲染層級總體分爲兩層：3D 場景層和 HUD 層

3D 場景層顧名思義渲染 3D 場景，由人物模型、建築模型和寶箱這些互動模型組成

HUD 層渲染互動按鈕、彈窗、業務需要的商品列表等2D UI 內容

本來 babylonjs 是支持 3D 和 2D 內容混合渲染的，但是如果都使用 babylonjs 渲染，在設置兩種內容需要使用統一的分辨率，而在現在的移動端設備上，能支持像素分辨率（如iPhone 14的像素分辨率爲1170x2532）渲染不卡頓的只佔一小部分。在大部分的設備上，最多隻能支持在邏輯分辨率（如iPhone 14邏輯分辨率爲390x844）下流暢運行，但設置這樣的分辨率會使 2D 層渲染模糊，所以使用分層的方法渲染。

由 babylonjs 渲染 3D 場景層，而 HUD 層則通過 react 框架使用傳統 DOM 方式渲染。

第二個 3D 渲染層

渲染層分爲 3D 場景層和 HUD 層帶來了一個問題，需要在 HUD 層上再渲染 3D 內容時，例如展示 3D 模型，則不得不再增加一層 3D渲染層。而 3D 渲染層不停地在調用渲染方法，以響應用戶操作和播放動畫，這耗費了大量 CPU 和 GPU 的計算資源，還佔用了存儲模型頂點信息和貼圖紋理的內存空間，因此在多個 3D 渲染層共存的情況下，需進行一定的管理以優化性能。我們採用以下策略管理多個 3D 渲染層：

在展示另外的 3D 渲染層時再實例化，並暫停原來 3D 渲染層的渲染
在不需要展示的時候銷燬，恢復原 3D 渲染層的渲染方法調用

以儘量減少資源的佔用，提高項目的渲染性能。

交互組件開發

碰撞檢測

babylonjs 自帶檢測模型間是否碰撞的方法，但使用設計師提供的高精度模型直接去調用碰撞檢測方法的話，計算量會很大，雖然未在測試設備上出現較嚴重的卡頓現象，但是已經使設備發熱。

因此需要使用一個包圍模型的不可見的、精簡面的“空氣牆”模型來做碰撞檢測。在項目初期，這個“空氣牆”模型需要設計師提供，在建模軟件里根據原模型製作低精度包圍模型。在後續迭代開發中，我們團隊開發了“一鍵生成空氣牆”的工具，自動生成低精度模型，減少設計師交付的資源數量，也減少更新模型時出錯的機會。

鏡頭避障

因爲項目用的是第三人稱的鏡頭，鏡頭離開人物模型有一定的距離，在人物走動或用戶控制角度的時候，鏡頭有可能和建築模型或場景模型碰撞，造成“鏡頭穿模”的現象。

babylonjs 自帶的鏡頭沒有避開模型的功能，在產品也沒有處理經驗的時候，我們做了如下兩個方案：

鏡頭外圍用一個不可見模型包圍，跟人物一樣與建築、場景模型做碰撞檢測，使鏡頭不會進入到模型中去。

這種方法的優點是可以使用內置的碰撞檢測方法，不需要額外的開發量。但是缺點也很明顯，用戶對鏡頭和模型的碰撞導致停止沒有預期，總會覺得鏡頭不自然的不受控制。

鏡頭和人物之間用棒狀的模型連接，同樣在棒狀模型上調用與建築、場景模型的碰撞檢測，當棒狀模型的某個位置發生碰撞時，鏡頭將移動到人物與碰撞點之間的位置，避免鏡頭進入模型的同時，也避免模型穿插在人物與鏡頭中間，造成導致用戶找不到人物的問題。

這種方法實現的效果符合一些同樣是第三人稱視角的 3D 遊戲的鏡頭運動邏輯，用戶感受更自然，不會出現失控的現象。而引入的額外開發量也在可控的範圍內。

與設計團隊的資源交接

模型格式

在衆多的 3D 模型格式中，我們選擇了 .gltf 格式。相對於其他模型格式，.gltf 可以減少 3D 格式中與渲染無關的的冗餘數據，從而確保文件體積更小。

目前 3D 素材相對來說都比較大，這對於移動端加載體驗來說，無疑是致命的。因此擁有更小體積的格式，也擁有了更高的優先選擇權重。

除此之外，.gltf 是對近二十年來各種 3D 格式的總結，使用最優的數據結構，從而保證最大的兼容性以及可伸縮性，在擁有大容量的同時，支持更多的拓展，比如支持多貼圖、多動畫等。

所以 .gltf 成爲了我們與視覺約定好的唯一素材格式。

模型輸出流程

本來設計師工作流使用的建模軟件是 C4D ，但是在資源交接的過程中，我們發現了幾個問題：

缺少導出 gltf 文件功能。在某些版本的 C4D 不能導出 gltf 格式的模型；某些版本能導出，但是導出有問題。而又因爲設計師使用的一些渲染器支持問題，不能輕易更新 C4D 版本。
導出模型大小不統一。可能因爲某些版本的 C4D 導出的問題，或是 C4D 裏的一些設置沒能導出到 gltf 文件，設計師幾次導出的模型大小並不統一，例如人物模型比建築模型還要大上好幾倍。
導出材質信息丟失。設計師在建模時，因爲模型可能會在多個渠道使用，例如渲染宣傳圖片，大部分情況會使用第三方的渲染器做渲染，這時候可能模型裏會使用這些渲染器獨有的材質。而這些材質導出到 gltf 文件時，會丟失這些獨有材質的信息。再導入到頁面的場景中時，設計師會發現展示的效果跟他們在建模軟件裏看到的相差甚遠。

在和設計師多次溝通後，我們之間定立了一個導出模型的工作流：

在 C4D 建模完成後，導出 FBX 格式的文件，再導入到對 gltf 支持較好的 blender 軟件中，設計師可以預覽他們的材質在中轉過程中有沒有丟失效果，blender 導出的 gltf 文件中的模型也能保持一致的大小。

預設光影

在默認的渲染設置中，我們把設計側輸出的模型放進場景中，加上光源，也只有明暗的變化，沒有影子，缺少了一些立體感。

在我們嘗試加入影子的過程中，發現性能受到嚴重影響。在查閱了渲染原理後，發現當每在一個平面上增加影子，相當於多渲染一次場景，渲染的壓力成倍增加。

在跟設計側交流後，決定在地板的貼圖紋理上預先加上建築的投影。這種方法對大部分是固定模型的場景能有較好的效果，而人物的陰影可以用靜態圖片跟隨模型移動模擬。

渲染優化

壓縮紋理

在開發期間發現在型號舊一點的iPhone設備上很容易出現閃退的現象，應該是頁面使用的內存超過了上限。

在項目中使用的資源體積最大的是模型 gltf 文件，檢查文件的內容，佔體積很大一部分的是紋理貼圖，解析資源發現很多貼圖的大小是3K（3072x3072的圖片），根據 WebGL 渲染原理，無論貼圖的資源原來是什麼格式，最後在渲染前需要解壓，相當於一張貼圖需要在內存中佔 3072 x 3072 x 3Byte = 27MB，解壓後還需要傳到 GPU，在多張貼圖同時渲染時很可能佔用大量的內存。

經過和設計側的溝通，同意在一些展示距離不可能很近的模型上替換較低分辨率的貼圖。

另外通常 2D 項目中使用的 png/jpg 格式圖片，並不適合 3D 渲染，他們需要經過上述的解壓過程，才能被 GPU 讀取。

在 3D 渲染領域，有其他適合 GPU 讀取的格式，如安卓支持的 ETC ，iOS 支持的 PVRTC，新一代的標準壓縮紋理格式 ASTC ，他們都不需要解壓就可以被 GPU 讀取，可以大大減少中間解壓佔用的內存容量。

在項目中，我們使用 gltf-transform 工具做縮小貼圖分辨率，和轉換格式的工作。

模型減面

模型在 WebGL 中渲染的流程是先用模型的頂點信息確定三角面，再在每個三角面上計算需要展示的顏色。

所以如果能減少模型面的數量，能減少每次渲染的計算量，減少每幀需要的渲染時間。

而如上面所說的，設計師建模的時候，可能面對的需求是輸出渲染圖，而不會對實時渲染做優化，所以在某些地方可能使用了過多的面。

參考團隊內其他同學的優化經驗（說一說 glTF 文件壓縮），使用 gltf-transform 工具對模型進行自動化減面。在和設計測反覆溝通後，我們確定了減面的參數 ratio = 0, error = 0.0001 。

合批渲染

在 3D 渲染中有一個 draw call 的概念，一次 draw call 就是 CPU 向 GPU 下的一次畫圖指令。在一次指令中，CPU 會向 GPU 傳遞需要畫的三角形信息，和三角形上顏色怎麼計算的方法，這個方法用人類明白的語言稱作材質。所以一次 draw call 只能畫相同材質的面。

因爲每次 draw call 有這些準備的動作，所以通常兩次 draw call 會比一次花的時間多。

在模型文件中，相同材質的面，可能不是定義在同一個模型中，這樣 CPU 會把這些面拆分成不同的畫圖指令，令 draw call 數量增加。

有一種對這種情況的優化方法叫合批，可以對這些相同材質的面合併，使他們可以在一次 draw call 中完成繪製。

這工作沒有工具幫助我們處理模型文件，但是在前端加載模型文件時，可以遍歷模型中的網格 mesh ，把使用相同材質的做合併。

需要注意的是帶動畫的網格不能這樣處理，因爲合併後的物體中心會變化，例如兩個自轉的球合併之後會圍繞兩個球的中點公轉。

後續迭代

模型懶加載和分級加載

雖然暫時的項目展示的場景還不是很大，同時加載和渲染對設備的壓力不算很大，但在場景增長到一定程度的時候，需要引入模型的懶加載和分級加載。

懶加載策略：在鏡頭移動到足夠靠近時再加載並插入模型到場景，銷燬離鏡頭足夠遠的模型。
分級加載策略：在鏡頭較遠時，加載較低精度的模型，較近時再切換成精度高的模型。

以上兩個策略都是現在較大型的 3D 遊戲會使用的加載策略，能減少同一屏幕中繪製的面數量，減輕渲染壓力。

分級渲染

現時訪問 3D 項目的設備性能差距非常大，有加上特效也能流暢運行的，也有隻能在設備分辨率下基本運行的。

babylonjs 自帶一個分級渲染的功能，能實時檢測運行幀率決定是否降級，在之後的迭代中，可以增加從像素分辨率加上特效到設備分辨率基本渲染的分級渲染策略。

實時光影

在使用以上的分級渲染策略後，可以在性能較好的設備上加上實時光影的特效，動態替換預烘焙貼圖。

場景搭建工具

在之前的項目開發過程中，設計師和產品、運營都需要通過前端輸出demo才能大概體驗到 3D 場景的效果，決定下一步如何調整。爲解決這個痛點，我們團隊開發了一個 3D 場景的搭建工具，用戶可通過上傳 gltf 文件搭建 3D 場景，實時預覽渲染效果。

並加入了在項目中沉澱的互動組件，快速生成 3D 場景項目。

總結

以上內容基本覆蓋了團隊內開發 3D web 項目的整個流程，在從 0 到 1 的過程中積累了對 3D 模型的控制方法和 3D 渲染原理的理解，並用工程化手段簡化中間的一些渲染優化流程。

在對獨立的模型文件作優化後，對搭建完成的場景還可以作進一步優化，如模型間共用材質的合併，重複模型的實例化。並在與設計側的溝通中，除了用規範控制輸出模型的規格外，還需要能即時地告知渲染效果作出反饋，由此引發出開發場景搭建工具的想法。

3D 互動項目的開發經驗還在不斷累積的階段，在往後的項目開發中將不斷迭代開發工作流及沉澱開發工具，希望能和有相關開發經驗和興趣的同學更多交流。

參考來源:

說一說 glTF 文件壓縮 https://jelly.jd.com/article/61057292df18aa019e8a2967

大型 3D 互動項目開發和優化實踐