開發(fā)背景

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

3D 場景相比傳統(tǒng)的 2D 頁面優(yōu)點(diǎn)是多一個(gè)維度，同屏展示的內(nèi)容可以更多，能完整的展示物體、商品的信息。

相應(yīng)帶來的缺點(diǎn)是用戶使用方式改變，用戶需要額外的學(xué)習(xí)成本。另外初期需要的開發(fā)量、美術(shù)資源和生成3D模型的設(shè)備也是增加的成本。

在這樣的背景下，我們團(tuán)隊(duì)接到了食品頻道的一個(gè)互動(dòng)項(xiàng)目的開發(fā)需求，希望通過 3D 場景的展示和互動(dòng)方式，作為對未來購物的一種嘗試與探索，滿足用戶對未來美好新奇的一個(gè)需求。將購物場景化、娛樂化，給用戶帶來美好的購物感受。

前端框架選擇

3D項(xiàng)目相比之前的2D項(xiàng)目改變的主要是客戶端的表現(xiàn)。在希望不依賴app客戶端支持和在盡量多的環(huán)境下能運(yùn)行，我們首先采用的方案是在 Web 端實(shí)現(xiàn) 3D 項(xiàng)目。

開發(fā)套件—

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

• 商業(yè)化使用需要收費(fèi)
• 需要使用其他語言開發(fā)（如 C# ），對團(tuán)隊(duì)學(xué)習(xí)成本較大
• 打包輸出的文件大小過大
• 官方文檔不夠詳細(xì)，學(xué)習(xí)曲線較抖

由于以上的原因，開發(fā)套件里沒有令團(tuán)隊(duì)很滿意的選擇，我們從其他方向?qū)ふ议_發(fā)工具。

開源渲染庫—

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

• three.js 提供的組件粒度較小，較基礎(chǔ)，能做很高程度的定制化二次開發(fā)，但如果需要開發(fā)一個(gè)互動(dòng)項(xiàng)目，需要開發(fā)的組件比較多
• babylon.js 既提供了粒度小的基礎(chǔ)組件，也封裝了接近開箱即用的組件。并自帶了性能測量工具，提供了方便的debug方法和優(yōu)化策略

經(jīng)過團(tuán)隊(duì)內(nèi)對各個(gè)開發(fā)套件/渲染庫的試用，最后選擇了 babylon.js 作為項(xiàng)目的渲染層庫，在其提供的組件上二次開發(fā)業(yè)務(wù)邏輯。

項(xiàng)目場景搭建

渲染分層結(jié)構(gòu)—

項(xiàng)目渲染層級總體分為兩層：3D 場景層和 HUD 層

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

HUD 層渲染互動(dòng)按鈕、彈窗、業(yè)務(wù)需要的商品列表等2D UI 內(nèi)容

本來 babylonjs 是支持 3D 和 2D 內(nèi)容混合渲染的，但是如果都使用 babylonjs 渲染，在設(shè)置兩種內(nèi)容需要使用統(tǒng)一的分辨率，而在現(xiàn)在的移動(dòng)端設(shè)備上，能支持像素分辨率（如iPhone 14的像素分辨率為1170x2532）渲染不卡頓的只占一小部分。在大部分的設(shè)備上，最多只能支持在邏輯分辨率（如iPhone 14邏輯分辨率為390x844）下流暢運(yùn)行，但設(shè)置這樣的分辨率會(huì)使 2D 層渲染模糊，所以使用分層的方法渲染。

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

第二個(gè) 3D 渲染層—

渲染層分為 3D 場景層和 HUD 層帶來了一個(gè)問題，需要在 HUD 層上再渲染 3D 內(nèi)容時(shí)，例如展示 3D 模型，則不得不再增加一層 3D渲染層。而 3D 渲染層不停地在調(diào)用渲染方法，以響應(yīng)用戶操作和播放動(dòng)畫，這耗費(fèi)了大量 CPU 和 GPU 的計(jì)算資源，還占用了存儲模型頂點(diǎn)信息和貼圖紋理的內(nèi)存空間，因此在多個(gè) 3D 渲染層共存的情況下，需進(jìn)行一定的管理以優(yōu)化性能。我們采用以下策略管理多個(gè) 3D 渲染層：

• 在展示另外的 3D 渲染層時(shí)再實(shí)例化，并暫停原來 3D 渲染層的渲染
• 在不需要展示的時(shí)候銷毀，恢復(fù)原 3D 渲染層的渲染方法調(diào)用

以盡量減少資源的占用，提高項(xiàng)目的渲染性能。

交互組件開發(fā)

碰撞檢測—

babylonjs 自帶檢測模型間是否碰撞的方法，但使用設(shè)計(jì)師提供的高精度模型直接去調(diào)用碰撞檢測方法的話，計(jì)算量會(huì)很大，雖然未在測試設(shè)備上出現(xiàn)較嚴(yán)重的卡頓現(xiàn)象，但是已經(jīng)使設(shè)備發(fā)熱。

因此需要使用一個(gè)包圍模型的不可見的、精簡面的“空氣墻”模型來做碰撞檢測。在項(xiàng)目初期，這個(gè)“空氣墻”模型需要設(shè)計(jì)師提供，在建模軟件里根據(jù)原模型制作低精度包圍模型。在后續(xù)迭代開發(fā)中，我們團(tuán)隊(duì)開發(fā)了“一鍵生成空氣墻”的工具，自動(dòng)生成低精度模型，減少設(shè)計(jì)師交付的資源數(shù)量，也減少更新模型時(shí)出錯(cuò)的機(jī)會(huì)。

鏡頭避障—

因?yàn)轫?xiàng)目用的是第三人稱的鏡頭，鏡頭離開人物模型有一定的距離，在人物走動(dòng)或用戶控制角度的時(shí)候，鏡頭有可能和建筑模型或場景模型碰撞，造成“鏡頭穿?！钡默F(xiàn)象。

babylonjs 自帶的鏡頭沒有避開模型的功能，在產(chǎn)品也沒有處理經(jīng)驗(yàn)的時(shí)候，我們做了如下兩個(gè)方案：

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

這種方法的優(yōu)點(diǎn)是可以使用內(nèi)置的碰撞檢測方法，不需要額外的開發(fā)量。但是缺點(diǎn)也很明顯，用戶對鏡頭和模型的碰撞導(dǎo)致停止沒有預(yù)期，總會(huì)覺得鏡頭不自然的不受控制。

2. 鏡頭和人物之間用棒狀的模型連接，同樣在棒狀模型上調(diào)用與建筑、場景模型的碰撞檢測，當(dāng)棒狀模型的某個(gè)位置發(fā)生碰撞時(shí)，鏡頭將移動(dòng)到人物與碰撞點(diǎn)之間的位置，避免鏡頭進(jìn)入模型的同時(shí)，也避免模型穿插在人物與鏡頭中間，造成導(dǎo)致用戶找不到人物的問題。

這種方法實(shí)現(xiàn)的效果符合一些同樣是第三人稱視角的 3D 游戲的鏡頭運(yùn)動(dòng)邏輯，用戶感受更自然，不會(huì)出現(xiàn)失控的現(xiàn)象。而引入的額外開發(fā)量也在可控的范圍內(nèi)。

與設(shè)計(jì)團(tuán)隊(duì)的資源交接

模型格式—

在眾多的 3D 模型格式中，我們選擇了 .gltf 格式。相對于其他模型格式，.gltf 可以減少 3D 格式中與渲染無關(guān)的的冗余數(shù)據(jù)，從而確保文件體積更小。

目前 3D 素材相對來說都比較大，這對于移動(dòng)端加載體驗(yàn)來說，無疑是致命的。因此擁有更小體積的格式，也擁有了更高的優(yōu)先選擇權(quán)重。

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

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

模型輸出流程—

本來設(shè)計(jì)師工作流使用的建模軟件是 C4D ，但是在資源交接的過程中，我們發(fā)現(xiàn)了幾個(gè)問題：

1. 缺少導(dǎo)出 gltf 文件功能。在某些版本的 C4D 不能導(dǎo)出 gltf 格式的模型；某些版本能導(dǎo)出，但是導(dǎo)出有問題。而又因?yàn)樵O(shè)計(jì)師使用的一些渲染器支持問題，不能輕易更新 C4D 版本。
2. 導(dǎo)出模型大小不統(tǒng)一?？赡芤?yàn)槟承┌姹镜?C4D 導(dǎo)出的問題，或是 C4D 里的一些設(shè)置沒能導(dǎo)出到 gltf 文件，設(shè)計(jì)師幾次導(dǎo)出的模型大小并不統(tǒng)一，例如人物模型比建筑模型還要大上好幾倍。
3. 導(dǎo)出材質(zhì)信息丟失。設(shè)計(jì)師在建模時(shí)，因?yàn)槟Ｐ涂赡軙?huì)在多個(gè)渠道使用，例如渲染宣傳圖片，大部分情況會(huì)使用第三方的渲染器做渲染，這時(shí)候可能模型里會(huì)使用這些渲染器獨(dú)有的材質(zhì)。而這些材質(zhì)導(dǎo)出到 gltf 文件時(shí)，會(huì)丟失這些獨(dú)有材質(zhì)的信息。再導(dǎo)入到頁面的場景中時(shí)，設(shè)計(jì)師會(huì)發(fā)現(xiàn)展示的效果跟他們在建模軟件里看到的相差甚遠(yuǎn)。

在和設(shè)計(jì)師多次溝通后，我們之間定立了一個(gè)導(dǎo)出模型的工作流：

在 C4D 建模完成后，導(dǎo)出 FBX 格式的文件，再導(dǎo)入到對 gltf 支持較好的 blender 軟件中，設(shè)計(jì)師可以預(yù)覽他們的材質(zhì)在中轉(zhuǎn)過程中有沒有丟失效果，blender 導(dǎo)出的 gltf 文件中的模型也能保持一致的大小。

預(yù)設(shè)光影—

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

在我們嘗試加入影子的過程中，發(fā)現(xiàn)性能受到嚴(yán)重影響。在查閱了渲染原理后，發(fā)現(xiàn)當(dāng)每在一個(gè)平面上增加影子，相當(dāng)于多渲染一次場景，渲染的壓力成倍增加。

在跟設(shè)計(jì)側(cè)交流后，決定在地板的貼圖紋理上預(yù)先加上建筑的投影。這種方法對大部分是固定模型的場景能有較好的效果，而人物的陰影可以用靜態(tài)圖片跟隨模型移動(dòng)模擬。

渲染優(yōu)化

壓縮紋理—

在開發(fā)期間發(fā)現(xiàn)在型號舊一點(diǎn)的iPhone設(shè)備上很容易出現(xiàn)閃退的現(xiàn)象，應(yīng)該是頁面使用的內(nèi)存超過了上限。

在項(xiàng)目中使用的資源體積最大的是模型 gltf 文件，檢查文件的內(nèi)容，占體積很大一部分的是紋理貼圖，解析資源發(fā)現(xiàn)很多貼圖的大小是3K（3072x3072的圖片），根據(jù) WebGL 渲染原理，無論貼圖的資源原來是什么格式，最后在渲染前需要解壓，相當(dāng)于一張貼圖需要在內(nèi)存中占 3072 x 3072 x 3Byte = 27MB，解壓后還需要傳到 GPU，在多張貼圖同時(shí)渲染時(shí)很可能占用大量的內(nèi)存。

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

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

在 3D 渲染領(lǐng)域，有其他適合 GPU 讀取的格式，如安卓支持的 ETC ，iOS 支持的 PVRTC，新一代的標(biāo)準(zhǔn)壓縮紋理格式 ASTC ，他們都不需要解壓就可以被 GPU 讀取，可以大大減少中間解壓占用的內(nèi)存容量。

在項(xiàng)目中，我們使用 gltf-transform 工具做縮小貼圖分辨率，和轉(zhuǎn)換格式的工作。

模型減面—

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

所以如果能減少模型面的數(shù)量，能減少每次渲染的計(jì)算量，減少每幀需要的渲染時(shí)間。

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

參考團(tuán)隊(duì)內(nèi)其他同學(xué)的優(yōu)化經(jīng)驗(yàn)（說一說 glTF 文件壓縮），使用 gltf-transform 工具對模型進(jìn)行自動(dòng)化減面。在和設(shè)計(jì)測反復(fù)溝通后，我們確定了減面的參數(shù) ratio = 0, error = 0.0001 。

合批渲染—

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

因?yàn)槊看?draw call 有這些準(zhǔn)備的動(dòng)作，所以通常兩次 draw call 會(huì)比一次花的時(shí)間多。

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

有一種對這種情況的優(yōu)化方法叫合批，可以對這些相同材質(zhì)的面合并，使他們可以在一次 draw call 中完成繪制。

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

需要注意的是帶動(dòng)畫的網(wǎng)格不能這樣處理，因?yàn)楹喜⒑蟮奈矬w中心會(huì)變化，例如兩個(gè)自轉(zhuǎn)的球合并之后會(huì)圍繞兩個(gè)球的中點(diǎn)公轉(zhuǎn)。

后續(xù)迭代

模型懶加載和分級加載—

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

• 懶加載策略：在鏡頭移動(dòng)到足夠靠近時(shí)再加載并插入模型到場景，銷毀離鏡頭足夠遠(yuǎn)的模型。
• 分級加載策略：在鏡頭較遠(yuǎn)時(shí)，加載較低精度的模型，較近時(shí)再切換成精度高的模型。

以上兩個(gè)策略都是現(xiàn)在較大型的 3D 游戲會(huì)使用的加載策略，能減少同一屏幕中繪制的面數(shù)量，減輕渲染壓力。

分級渲染—

現(xiàn)時(shí)訪問 3D 項(xiàng)目的設(shè)備性能差距非常大，有加上特效也能流暢運(yùn)行的，也有只能在設(shè)備分辨率下基本運(yùn)行的。

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

實(shí)時(shí)光影—

在使用以上的分級渲染策略后，可以在性能較好的設(shè)備上加上實(shí)時(shí)光影的特效，動(dòng)態(tài)替換預(yù)烘焙貼圖。

場景搭建工具—

在之前的項(xiàng)目開發(fā)過程中，設(shè)計(jì)師和產(chǎn)品、運(yùn)營都需要通過前端輸出demo才能大概體驗(yàn)到 3D 場景的效果，決定下一步如何調(diào)整。為解決這個(gè)痛點(diǎn)，我們團(tuán)隊(duì)開發(fā)了一個(gè) 3D 場景的搭建工具，用戶可通過上傳 gltf 文件搭建 3D 場景，實(shí)時(shí)預(yù)覽渲染效果。

并加入了在項(xiàng)目中沉淀的互動(dòng)組件，快速生成 3D 場景項(xiàng)目。

總結(jié)

以上內(nèi)容基本覆蓋了團(tuán)隊(duì)內(nèi)開發(fā) 3D web 項(xiàng)目的整個(gè)流程，在從 0 到 1 的過程中積累了對 3D 模型的控制方法和 3D 渲染原理的理解，并用工程化手段簡化中間的一些渲染優(yōu)化流程。

在對獨(dú)立的模型文件作優(yōu)化后，對搭建完成的場景還可以作進(jìn)一步優(yōu)化，如模型間共用材質(zhì)的合并，重復(fù)模型的實(shí)例化。并在與設(shè)計(jì)側(cè)的溝通中，除了用規(guī)范控制輸出模型的規(guī)格外，還需要能即時(shí)地告知渲染效果作出反饋，由此引發(fā)出開發(fā)場景搭建工具的想法。

3D 互動(dòng)項(xiàng)目的開發(fā)經(jīng)驗(yàn)還在不斷累積的階段，在往后的項(xiàng)目開發(fā)中將不斷迭代開發(fā)工作流及沉淀開發(fā)工具，希望能和有相關(guān)開發(fā)經(jīng)驗(yàn)和興趣的同學(xué)更多交流。

參考資料

[1] 說一說 glTF 文件壓縮