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

開發背景

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

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

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

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

前端框架選擇

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

開發套件

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

• 商業化使用需要收費

• 需要使用其他語言開發（如 C# ），對團隊學習成本較大

• 打包輸出的檔案大小過大

• 官方檔案不夠詳細，學習曲線較抖

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

開源渲染庫

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

?three.js 提供的組件粒度較小，較基礎，能做很高程度的定制化二次開發，但如果需要開發一個互動專案，需要開發的組件比較多

?babylon.js 既提供了粒度小的基礎組件，也封裝了接近開箱即用的組件，并自帶了性能測量工具，提供了方便的debug方法和優化策略

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

專案場景搭建

渲染分層結構

專案渲染層級總體分為兩層：3D 場景層和 HUD 層

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

2.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 自帶的鏡頭沒有避開模型的功能，在產品也沒有處理經驗的時候，我們做了如下兩個方案：

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

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

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

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

與設計團隊的資源交接

模型格式

在眾多的 3D 模型格式中，我們選擇了 .gltf 格式，相對于其他模型格式，.gltf 可以減少 3D 格式中與渲染無關的的冗余資料，從而確保檔案體積更小，

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

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

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

模型輸出流程

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

1.缺少匯出 gltf 檔案功能， 在某些版本的 C4D 不能匯出 gltf 格式的模型；某些版本能匯出，但是匯出有問題，而又因為設計師使用的一些渲染器支持問題，不能輕易更新 C4D 版本，

2.匯出模型大小不統一， 可能因為某些版本的 C4D 匯出的問題，或是 C4D 里的一些設定沒能匯出到 gltf 檔案，設計師幾次匯出的模型大小并不統一，例如人物模型比建筑模型還要大上好幾倍，

3.匯出材質資訊丟失， 設計師在建模時，因為模型可能會在多個渠道使用，例如渲染宣傳圖片，大部分情況會使用第三方的渲染器做渲染，這時候可能模型里會使用這些渲染器獨有的材質，而這些材質匯出到 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 中渲染的流程是先用模型的頂點資訊確定三角面，再在每個三角面上計算需要展示的顏色，所以如果能減少模型面的數量，能減少每次渲染的計算量，減少每幀需要的渲染時間，

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

參考了團隊內其他同學的優化經驗1，使用 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 場景專案，

參考來源：

1. 說一說 glTF 檔案壓縮 https://jelly.jd.com/article/61057292df18aa019e8a2967

作者：京東零售 胡俊文

來源：京東云開發者社區

標籤：Android

上一篇：From Java To Kotlin 2：Kotlin 型別系統與泛型

下一篇：返回列表