建站
咨詢
售后
建站咨詢
新聞中心
開發(fā)背景
得益于“元宇宙”概念在前段時間的爆火，各家公司都推出了使用 3D 場景的活動或頻道。
專注于為中小企業(yè)提供成都網(wǎng)站設計、成都網(wǎng)站制作服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)武平免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千多家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
3D 場景相比傳統(tǒng)的 2D 頁面優(yōu)點是多一個維度，同屏展示的內(nèi)容可以更多，能完整的展示物體、商品的信息。
相應帶來的缺點是用戶使用方式改變，用戶需要額外的學習成本。另外初期需要的開發(fā)量、美術資源和生成3D模型的設備也是增加的成本。
在這樣的背景下，我們團隊接到了食品頻道的一個互動項目的開發(fā)需求，希望通過 3D 場景的展示和互動方式，作為對未來購物的一種嘗試與探索，滿足用戶對未來美好新奇的一個需求。將購物場景化、娛樂化，給用戶帶來美好的購物感受。
前端框架選擇
3D項目相比之前的2D項目改變的主要是客戶端的表現(xiàn)。在希望不依賴app客戶端支持和在盡量多的環(huán)境下能運行，我們首先采用的方案是在 Web 端實現(xiàn) 3D 項目。
開發(fā)套件—
首先我們考慮的是成熟的開發(fā)套件，如unity/egret等，但這些開發(fā)套件都有一些我們不能繞過的問題，例如：
- 商業(yè)化使用需要收費
- 需要使用其他語言開發(fā)（如 C# ），對團隊學習成本較大
- 打包輸出的文件大小過大
- 官方文檔不夠詳細，學習曲線較抖
|
引擎名稱/對比維度 |
使用價格(權重50%) |
腳本上手(權重30%) |
場景搭建(權重20%) |
支持模型格式(權重10%) |
社區(qū)資料豐富程度(權重30%) |
支持web端發(fā)布(一票否決) |
|
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 |
由于以上的原因，開發(fā)套件里沒有令團隊很滿意的選擇，我們從其他方向?qū)ふ议_發(fā)工具。
開源渲染庫—
另外也比較了 Web 前端使用量較多的兩個 3D 渲染庫：
- three.js 提供的組件粒度較小，較基礎，能做很高程度的定制化二次開發(fā)，但如果需要開發(fā)一個互動項目，需要開發(fā)的組件比較多
- babylon.js 既提供了粒度小的基礎組件，也封裝了接近開箱即用的組件。并自帶了性能測量工具，提供了方便的debug方法和優(yōu)化策略
經(jīng)過團隊內(nèi)對各個開發(fā)套件/渲染庫的試用，最后選擇了 babylon.js 作為項目的渲染層庫，在其提供的組件上二次開發(fā)業(yè)務邏輯。
項目場景搭建
渲染分層結(jié)構(gòu)—
項目渲染層級總體分為兩層：3D 場景層和 HUD 層
3D 場景層顧名思義渲染 3D 場景，由人物模型、建筑模型和寶箱這些互動模型組成
HUD 層渲染互動按鈕、彈窗、業(yè)務需要的商品列表等2D UI 內(nèi)容
本來 babylonjs 是支持 3D 和 2D 內(nèi)容混合渲染的，但是如果都使用 babylonjs 渲染，在設置兩種內(nèi)容需要使用統(tǒng)一的分辨率，而在現(xiàn)在的移動端設備上，能支持像素分辨率（如iPhone 14的像素分辨率為1170x2532）渲染不卡頓的只占一小部分。在大部分的設備上，最多只能支持在邏輯分辨率（如iPhone 14邏輯分辨率為390x844）下流暢運行，但設置這樣的分辨率會使 2D 層渲染模糊，所以使用分層的方法渲染。
由 babylonjs 渲染 3D 場景層，而 HUD 層則通過 react 框架使用傳統(tǒng) DOM 方式渲染。
第二個 3D 渲染層—
渲染層分為 3D 場景層和 HUD 層帶來了一個問題，需要在 HUD 層上再渲染 3D 內(nèi)容時，例如展示 3D 模型，則不得不再增加一層 3D渲染層。而 3D 渲染層不停地在調(diào)用渲染方法，以響應用戶操作和播放動畫，這耗費了大量 CPU 和 GPU 的計算資源，還占用了存儲模型頂點信息和貼圖紋理的內(nèi)存空間，因此在多個 3D 渲染層共存的情況下，需進行一定的管理以優(yōu)化性能。我們采用以下策略管理多個 3D 渲染層：
- 在展示另外的 3D 渲染層時再實例化，并暫停原來 3D 渲染層的渲染
- 在不需要展示的時候銷毀，恢復原 3D 渲染層的渲染方法調(diào)用
以盡量減少資源的占用，提高項目的渲染性能。
交互組件開發(fā)
碰撞檢測—
babylonjs 自帶檢測模型間是否碰撞的方法，但使用設計師提供的高精度模型直接去調(diào)用碰撞檢測方法的話，計算量會很大，雖然未在測試設備上出現(xiàn)較嚴重的卡頓現(xiàn)象，但是已經(jīng)使設備發(fā)熱。
因此需要使用一個包圍模型的不可見的、精簡面的“空氣墻”模型來做碰撞檢測。在項目初期，這個“空氣墻”模型需要設計師提供，在建模軟件里根據(jù)原模型制作低精度包圍模型。在后續(xù)迭代開發(fā)中，我們團隊開發(fā)了“一鍵生成空氣墻”的工具，自動生成低精度模型，減少設計師交付的資源數(shù)量，也減少更新模型時出錯的機會。
鏡頭避障—
因為項目用的是第三人稱的鏡頭，鏡頭離開人物模型有一定的距離，在人物走動或用戶控制角度的時候，鏡頭有可能和建筑模型或場景模型碰撞，造成“鏡頭穿?！钡默F(xiàn)象。
babylonjs 自帶的鏡頭沒有避開模型的功能，在產(chǎn)品也沒有處理經(jīng)驗的時候，我們做了如下兩個方案：
- 鏡頭外圍用一個不可見模型包圍，跟人物一樣與建筑、場景模型做碰撞檢測，使鏡頭不會進入到模型中去。
這種方法的優(yōu)點是可以使用內(nèi)置的碰撞檢測方法，不需要額外的開發(fā)量。但是缺點也很明顯，用戶對鏡頭和模型的碰撞導致停止沒有預期，總會覺得鏡頭不自然的不受控制。
- 鏡頭和人物之間用棒狀的模型連接，同樣在棒狀模型上調(diào)用與建筑、場景模型的碰撞檢測，當棒狀模型的某個位置發(fā)生碰撞時，鏡頭將移動到人物與碰撞點之間的位置，避免鏡頭進入模型的同時，也避免模型穿插在人物與鏡頭中間，造成導致用戶找不到人物的問題。
這種方法實現(xiàn)的效果符合一些同樣是第三人稱視角的 3D 游戲的鏡頭運動邏輯，用戶感受更自然，不會出現(xiàn)失控的現(xiàn)象。而引入的額外開發(fā)量也在可控的范圍內(nèi)。
與設計團隊的資源交接
模型格式—
在眾多的 3D 模型格式中，我們選擇了 .gltf 格式。相對于其他模型格式，.gltf 可以減少 3D 格式中與渲染無關的的冗余數(shù)據(jù)，從而確保文件體積更小。
目前 3D 素材相對來說都比較大，這對于移動端加載體驗來說，無疑是致命的。因此擁有更小體積的格式，也擁有了更高的優(yōu)先選擇權重。
除此之外，.gltf 是對近二十年來各種 3D 格式的總結(jié)，使用最優(yōu)的數(shù)據(jù)結(jié)構(gòu)，從而保證最大的兼容性以及可伸縮性，在擁有大容量的同時，支持更多的拓展，比如支持多貼圖、多動畫等。
所以 .gltf 成為了我們與視覺約定好的唯一素材格式。
模型輸出流程—
本來設計師工作流使用的建模軟件是 C4D ，但是在資源交接的過程中，我們發(fā)現(xiàn)了幾個問題：
- 缺少導出 gltf 文件功能。在某些版本的 C4D 不能導出 gltf 格式的模型；某些版本能導出，但是導出有問題。而又因為設計師使用的一些渲染器支持問題，不能輕易更新 C4D 版本。
- 導出模型大小不統(tǒng)一?？赡芤驗槟承┌姹镜?C4D 導出的問題，或是 C4D 里的一些設置沒能導出到 gltf 文件，設計師幾次導出的模型大小并不統(tǒng)一，例如人物模型比建筑模型還要大上好幾倍。
- 導出材質(zhì)信息丟失。設計師在建模時，因為模型可能會在多個渠道使用，例如渲染宣傳圖片，大部分情況會使用第三方的渲染器做渲染，這時候可能模型里會使用這些渲染器獨有的材質(zhì)。而這些材質(zhì)導出到 gltf 文件時，會丟失這些獨有材質(zhì)的信息。再導入到頁面的場景中時，設計師會發(fā)現(xiàn)展示的效果跟他們在建模軟件里看到的相差甚遠。
在和設計師多次溝通后，我們之間定立了一個導出模型的工作流：
在 C4D 建模完成后，導出 FBX 格式的文件，再導入到對 gltf 支持較好的 blender 軟件中，設計師可以預覽他們的材質(zhì)在中轉(zhuǎn)過程中有沒有丟失效果，blender 導出的 gltf 文件中的模型也能保持一致的大小。
預設光影—
在默認的渲染設置中，我們把設計側(cè)輸出的模型放進場景中，加上光源，也只有明暗的變化，沒有影子，缺少了一些立體感。
在我們嘗試加入影子的過程中，發(fā)現(xiàn)性能受到嚴重影響。在查閱了渲染原理后，發(fā)現(xiàn)當每在一個平面上增加影子，相當于多渲染一次場景，渲染的壓力成倍增加。
在跟設計側(cè)交流后，決定在地板的貼圖紋理上預先加上建筑的投影。這種方法對大部分是固定模型的場景能有較好的效果，而人物的陰影可以用靜態(tài)圖片跟隨模型移動模擬。
渲染優(yōu)化
壓縮紋理—
在開發(fā)期間發(fā)現(xiàn)在型號舊一點的iPhone設備上很容易出現(xiàn)閃退的現(xiàn)象，應該是頁面使用的內(nèi)存超過了上限。
在項目中使用的資源體積最大的是模型 gltf 文件，檢查文件的內(nèi)容，占體積很大一部分的是紋理貼圖，解析資源發(fā)現(xiàn)很多貼圖的大小是3K（3072x3072的圖片），根據(jù) WebGL 渲染原理，無論貼圖的資源原來是什么格式，最后在渲染前需要解壓，相當于一張貼圖需要在內(nèi)存中占 3072 x 3072 x 3Byte = 27MB，解壓后還需要傳到 GPU，在多張貼圖同時渲染時很可能占用大量的內(nèi)存。
經(jīng)過和設計側(cè)的溝通，同意在一些展示距離不可能很近的模型上替換較低分辨率的貼圖。
另外通常 2D 項目中使用的 png/jpg 格式圖片，并不適合 3D 渲染，他們需要經(jīng)過上述的解壓過程，才能被 GPU 讀取。
在 3D 渲染領域，有其他適合 GPU 讀取的格式，如安卓支持的 ETC ，iOS 支持的 PVRTC，新一代的標準壓縮紋理格式 ASTC ，他們都不需要解壓就可以被 GPU 讀取，可以大大減少中間解壓占用的內(nèi)存容量。
在項目中，我們使用 gltf-transform 工具做縮小貼圖分辨率，和轉(zhuǎn)換格式的工作。
模型減面—
模型在 WebGL 中渲染的流程是先用模型的頂點信息確定三角面，再在每個三角面上計算需要展示的顏色。
所以如果能減少模型面的數(shù)量，能減少每次渲染的計算量，減少每幀需要的渲染時間。
而如上面所說的，設計師建模的時候，可能面對的需求是輸出渲染圖，而不會對實時渲染做優(yōu)化，所以在某些地方可能使用了過多的面。
參考團隊內(nèi)其他同學的優(yōu)化經(jīng)驗（說一說 glTF 文件壓縮），使用 gltf-transform 工具對模型進行自動化減面。在和設計測反復溝通后，我們確定了減面的參數(shù) ratio = 0, error = 0.0001 。
合批渲染—
在 3D 渲染中有一個 draw call 的概念，一次 draw call 就是 CPU 向 GPU 下的一次畫圖指令。在一次指令中，CPU 會向 GPU 傳遞需要畫的三角形信息，和三角形上顏色怎么計算的方法，這個方法用人類明白的語言稱作材質(zhì)。所以一次 draw call 只能畫相同材質(zhì)的面。
因為每次 draw call 有這些準備的動作，所以通常兩次 draw call 會比一次花的時間多。
在模型文件中，相同材質(zhì)的面，可能不是定義在同一個模型中，這樣 CPU 會把這些面拆分成不同的畫圖指令，令 draw call 數(shù)量增加。
有一種對這種情況的優(yōu)化方法叫合批，可以對這些相同材質(zhì)的面合并，使他們可以在一次 draw call 中完成繪制。
這工作沒有工具幫助我們處理模型文件，但是在前端加載模型文件時，可以遍歷模型中的網(wǎng)格 mesh ，把使用相同材質(zhì)的做合并。
需要注意的是帶動畫的網(wǎng)格不能這樣處理，因為合并后的物體中心會變化，例如兩個自轉(zhuǎn)的球合并之后會圍繞兩個球的中點公轉(zhuǎn)。
后續(xù)迭代
模型懶加載和分級加載—
雖然暫時的項目展示的場景還不是很大，同時加載和渲染對設備的壓力不算很大，但在場景增長到一定程度的時候，需要引入模型的懶加載和分級加載。
- 懶加載策略：在鏡頭移動到足夠靠近時再加載并插入模型到場景，銷毀離鏡頭足夠遠的模型。
- 分級加載策略：在鏡頭較遠時，加載較低精度的模型，較近時再切換成精度高的模型。
以上兩個策略都是現(xiàn)在較大型的 3D 游戲會使用的加載策略，能減少同一屏幕中繪制的面數(shù)量，減輕渲染壓力。
分級渲染—
現(xiàn)時訪問 3D 項目的設備性能差距非常大，有加上特效也能流暢運行的，也有只能在設備分辨率下基本運行的。
babylonjs 自帶一個分級渲染的功能，能實時檢測運行幀率決定是否降級，在之后的迭代中，可以增加從像素分辨率加上特效到設備分辨率基本渲染的分級渲染策略。
實時光影—
在使用以上的分級渲染策略后，可以在性能較好的設備上加上實時光影的特效，動態(tài)替換預烘焙貼圖。
場景搭建工具—
在之前的項目開發(fā)過程中，設計師和產(chǎn)品、運營都需要通過前端輸出demo才能大概體驗到 3D 場景的效果，決定下一步如何調(diào)整。為解決這個痛點，我們團隊開發(fā)了一個 3D 場景的搭建工具，用戶可通過上傳 gltf 文件搭建 3D 場景，實時預覽渲染效果。
并加入了在項目中沉淀的互動組件，快速生成 3D 場景項目。
總結(jié)
以上內(nèi)容基本覆蓋了團隊內(nèi)開發(fā) 3D web 項目的整個流程，在從 0 到 1 的過程中積累了對 3D 模型的控制方法和 3D 渲染原理的理解，并用工程化手段簡化中間的一些渲染優(yōu)化流程。
在對獨立的模型文件作優(yōu)化后，對搭建完成的場景還可以作進一步優(yōu)化，如模型間共用材質(zhì)的合并，重復模型的實例化。并在與設計側(cè)的溝通中，除了用規(guī)范控制輸出模型的規(guī)格外，還需要能即時地告知渲染效果作出反饋，由此引發(fā)出開發(fā)場景搭建工具的想法。
3D 互動項目的開發(fā)經(jīng)驗還在不斷累積的階段，在往后的項目開發(fā)中將不斷迭代開發(fā)工作流及沉淀開發(fā)工具，希望能和有相關開發(fā)經(jīng)驗和興趣的同學更多交流。
參考資料
[1] 說一說 glTF 文件壓縮
網(wǎng)站標題：大型3D互動項目開發(fā)和優(yōu)化實踐
鏈接分享：http://www.dlmjj.cn/article/dpdhsoj.html
