作者：金擘(渚薰)
1.今年我們邁出的第一步
隨著淘寶人生小屋專案的正式上線，淘寶人生今年的元宇宙規劃初步成型。
加上在 S1 同淘寶直播團隊的合作上線的 Disney 毛毛狂歡館，我們也正式邁出了“元宇宙”技術的第一步。
今年是淘寶人生上線 3 週年，我們去年從靈犀互娛 C6 小組手中接過這根接力棒，經過了漫長的開著飛機換引擎的過程。在這之前，我們團隊並沒有中大型的 3D 互動遊戲專案經驗，透過這次專案我們也經歷各個方面選擇、徘徊和堅定。說實話，3D 互動遊戲專案確實不好做，從靈犀互娛的那種遊戲工作室模式，轉到淘寶這種職能組織架構，面臨了工種協同、技能匹配、磨合程度等多種問題。
接下來，我把我們的思考和經驗分享出來，希望能成為一個個敲門磚，給到想要同樣追逐這波浪潮的你們。
2.如何選擇合適的移動端 3D 引擎
3D 引擎作為第一塊敲門磚，往往是技術優先去考慮的事情。我們也來透過對業界的優秀引擎的觀察來剖析這個問題。
2.1 讓引擎做它擅長的事
首先，我們對引擎本身所擅長的事需要有個大致的瞭解，通常訪問引擎的官網就能知道一二。例如：
Three.js 的介紹：“The aim of the project is to create an easy to use, lightweight, cross-browser, general purpose 3D library.”
Babylon.js 的介紹：“A fully-featured, open-source game engine, Babylon.js was built with one goal in mind…making it as simple as possible to create powerful and beautiful games that run on the web in any browser.”
從上述描述中，不難看出兩者比較清晰的定位：Three.js 是一個 3D 庫，Babylon.js 是一個遊戲引擎。這裡所謂的 3D 庫指的是實現了 3D 基礎功能，包括渲染（幾何、材質、管線、光照等）、動畫、資源管理和數學工具等。遊戲引擎則具備了遊戲研發的抽象能力，比如：GUI、物理系統、粒子系統、角色系統、狀態機、相機控制、搖桿輸入控制等。我們還可以更加直接的透過 API 的命名和分類瞭解到這個引擎所能提供的主要研發能力。
為什麼要知道一個引擎擅長什麼？ 因為 3D 技術在不同的領域都有廣泛應用，不同領域對 3D 技術的要求也有不同的側重點。Threejs 更像是一個通用型的解決方案，你可以用它來實現遊戲，也可以用它來構建數字孿生（例如 1:1 的數字城市），資料視覺化、工業展示（例如商品、建築、汽車），虛擬人等等。但通用型解決方案面臨的問題，就是想要在不同的領域用好 Threejs，通常需要基於它進行二次的框架研發來滿足特定的技術需求。例如，用 Threejs 來研發 H5 遊戲，就需要用它作為基礎的 3D 庫，進一步構建一套完整的遊戲研發框架，否則長期迭代專案或開發多個專案時就會比較痛苦。而 Babylon.js 就是專注於遊戲研發的引擎，在它 API 文件中，也會看到大量的 3D 基礎功能，同時也能發現不少遊戲研發能力，例如 ArcFollowCamera、Gamepad、PhysicsEngine 等。
現代大多數 3D 引擎，其實沒有明顯的偏科，但在我們做技術選型時總會希望能用到一個上手最快能解決專案問題的引擎。於是我簡單列了一張表格，供大家參考：
2.2 Web、Native 還是 Hybrid？
在瞭解完引擎擅長的事情後，你肯定會發現有那麼多引擎都在做相同的事情，行業內卷程度可想而知。同時發現還需要在技術棧或者平臺方案上再次做出選擇。
例如同為可以做遊戲的引擎：Unreal、PlayCanvas、CocosCreator 就有著完全不一樣的技術棧和平臺定位。
- Unreal：Native、開發語言：C++。
- PlayCanvas：Web-First，開發語言：TypeScript。
- CocosCreator：Hybrid（JS Runtime + Native），開發語言：TypeScript。
如何選擇？我們可以首先要知道實現 3D 的依賴哪些關鍵因素：
- 邏輯運算能力（依賴 CPU，跟 VM Runtime 實現有關）：例如物理模擬（有物理加速技術可以用上 GPU 運算效能，例如 Nvidia PhysX）。
- 浮點運算能力（依賴 GPU，跟圖形介面實現有關）：例如光柵化、全域性光（移動端顯示晶片暫時沒有 GPU 光追）。
這些關鍵因素的表現差異是：
這些關鍵因素可以組合得出：
乍看之下 Native 必將是最佳選擇，但凡事都有兩面性。
首先動態性上，Native 佔據著絕對的劣勢，Web 的傲人之處仍然是優秀的動態性和跨平臺性。當你所要實現的專案停留在簡單的工業展示（不需要高模擬）型別或小遊戲時，Web 引擎仍然是最佳選型之一。同時也因 WebGPU、WebWoker、WebAssembly 這幾年的發展，給 Web3D 帶來了不錯的前景。
在 WebGPU 還未成熟之前，Hybrid 抑或是另一種折中或過渡階段的選擇。因為 Hybrid 可以讓 Web 享受到最新圖形介面帶來的好處，但同樣需要犧牲因部分能力下沉到 Native 實現而丟失的動態性。丟失的動態性多少取決於 JS 和 Native 實現功能分工。為了說明這個影響，我們先來看下大部分 3D 引擎的一個分層架構：
在上述架構中，可以“隨意”切一條線，將一部分功能放入 Native 實現，將另一部分功能放入 JS 內實現。例如：
方案 1：此方案為 JS 提供了最新的圖形介面，並且始終遵循 W3C 的標準 API，它的動態靈活性保持的較好，且我願意稱這類方案是對 Web 社群友好的方案，因為它的誕生是能天然適配市面上大部分 Web3D 引擎的。例如 CocosCreator、淘寶小程式（FCanvas）、微信小遊戲用的都是類似的 Hybrid 方案（主要實現 WebGL API 標準）。透過遵循 WebGPU 的 API 標準，可以讓這個方案獲得比 WebGL 更好的顯示卡特性支援，可以實現更高階和特殊的材質效果。
方案 2：此方案將渲染能力下沉到了 Native 層，可以直接呼叫系統硬體級別的圖形介面，減少 JS Binding 帶來的效能損失，例如對於渲染一個正方體，只需要給 Native 的 API 提交一次幾何和材質資料資訊，之後的逐幀渲染都在 Native 中進行。
方案 3：讓 Native 承擔了更多的職責，但同時因為部分動態性的丟失，整個方案需要迭代發版來支援一些新的能力。同時，JS Framework 和 Native Engine Core 之間如果還是存在每幀的資料呼叫，仍然會出現一些效能瓶頸。這類方案，最適合前端不需要頻繁互動的專案，例如動態展示一個商品、展館等，透過點選可以播放一些商品動畫。換言之，JS 層的 Framework 可以做的非常輕薄，封裝一些業務的抽象邏輯，並用初始資料以及事件更新和 Native 通訊。
我們要認識到瀏覽器的 WebGL 實現等同於一個特殊且統一標準 Hybrid 模式，本質上和我們自己實現的方案區別不大。但所有 Hybrid 方案都有一個問題，就是 JS 和 Native 之間的通訊和資料交換效率，不同方案的效率會有比較大的差異。我們來簡單對比下 WebGL 和 WebGPU 的資料交換效率。
WebGL 的工作需要一個全域性狀態機，任何一次 API 呼叫都是在同步的修改狀態，且每一次狀態的改變都需要在 CPU（JS）和 GPU（OpenGL）之間通訊。例如在提交 buffer 和 texture 時，會在 CPU 記憶體和 GPU 記憶體之間多次進行資料交換，可想而知效率會大幅受限。WebGL（OpenGL）這樣的設計是歷史原因的，那會兒 GPU 的工作沒那麼複雜，這樣的設計足夠了。
WebGPU 的工作就像是一套非同步的指令集，它會將所有的指令按順序暫存在 CPU 記憶體中，並在合適的時機批次提交給 GPU，並且這樣的指令操作可以在多個 Worker 中並行進行，不會阻塞 JS 執行緒。
所以，如果要選擇 Hybrid 方案來彌補 Web（WebGL）的一些效能劣勢，那麼可以自研一套 WebGPU 標準的 API（指上述方案 1）或者將一部分渲染或核心功能下沉到 Native 中實現（指上述方案 2、3）。至於這兩種孰優孰劣就看業務需要什麼、需要給前端多少研發自由度了。
最後說說 Native，它很強大，無論是 Unreal、Unity，還是集團內的一些自研引擎。都能在自己擅長的事情上做到不錯的效果和效能，但使用 Native 對於研發週期管理、產品迭代路徑、長尾版本維護等需要提供足夠的保障，並慎重決策。
2.3 自研還是擁抱社群？
這個問題很微妙，簡而言之，該卷的還得卷^-^。但還得想清楚為什麼要卷？
我們先來看下，社群優秀的引擎有哪些？Three.js，Babylon.js，CocosCreator，Unreal，Unity，每一個都是非常強大且能滿足專案需求。集團內（包括螞蟻）也有優秀的引擎，比如 Hilo3D，Oasis Engine，AceNNR 等，那麼卷不卷的第一個靈魂拷問就是：卷的動嗎？怎麼判斷是否卷的動？
- 有人思考：如何培養一隻有戰鬥力的 3D 團隊（章節 5）
- 對引擎定位（章節 2.1）、技術方案（章節 2.2）能預判
- 擼起袖子幹:如何打造專業的 3D 工作流、如何做到效果和效能的平衡（章節 4）
- 堅持不斷圍繞專案本身的特性和能力最佳化和打磨自研引擎
在我們接手淘寶人生的時候便做了如下的判斷：
- 人，我們有，雖然不多，但精煉能幹
- 堅持以 Web 為主要平臺，雖然介於現狀，WebGL 是明顯的天花板，但 WebGPU 未來可期
- 為淘寶人生打造專業的 3D 工作流，且用一切能用的手段來彌補目前 Web 的短板
- 專注做好淘寶人生的 3D 技術，好鋼使在刀刃上
但反過來，卷不動的情況下，如果擁抱社群（集團）？
首先，選擇一款適合自己業務的引擎，我上面所說的兩點可以作為參考（章節 2.1、2.2）
其次，雖然不需要自研引擎，但是仍然需要在 3D 技術上專業能力的同學來負責整個專案。因為就算是簡單專案（比如展示一個商品或靜態場景），在長期維護下勢必會有很多需要升級或改進的問題。在集團內，可能還會有引擎團隊的同學給予一定的支援，但如果選擇社群方案，那隻能靠自己了。
最後，無論是自研，還是擁抱社群，最關鍵的還是要考慮對業務長期支撐的最優方案，同時，專注在業務需求下的問題解決，不要做大而全，考慮太多通用的事情。
2.4 端還是雲？
最後，再來講講端和雲的話題。雙 11，其實有不少團隊的產品都使用了雲端實時渲染推流的方案，比如 IP 新勢力（Unity + 雲），未來科技城（Unreal + 雲）。
雲的優勢不言而喻：桌面級顯示卡！行業頂尖的引擎！那麼雲方案現在成熟了嗎？這麼說吧，技術上其實相對是成熟的，畢竟雲版的原神有一部分用的是阿里雲提供的服務，那唯一要考慮的就是預算的問題。因為預算關係到了機器，機器關係到了同時線上人數。而在端上（整合到 App 內），要用上行業頂尖的引擎（例如 Unreal），騰訊的超級 QQ 秀和天貓的沉浸式 3D 場景購物體驗也給出了一些結論。
有句老話：夢想要有的萬一實現了呢。所以，無論是雲遊戲/雲渲染，還是 App 內整合頂尖的遊戲引擎，大家也都不要放棄。
但從現如今的實際情況來看，在端上用 Web 或 Hybrid 會是更加穩妥的方案。
3.如何打造專業的 3D 美術工作流
為什麼 3D 專案需要美術工作流，而 2D 專案不需要？ 這個問題可能在沒接觸過 3D 專案的人來，是個非常困惑的事情。那麼接下來我就把為什麼、做什麼、怎麼做講清楚。
首先，3D 美術工作流沒有標準，也沒有好壞，只有是否適合——適合這個團隊和專案，其次它並不是必需的，在簡單的一次性專案中，工作流可以被忽略或者用引擎提供的基礎工作流即可。
那麼怎樣的專案不需要 3D 美術工作流呢？
當你的專案不要求規模化的生產（例如就是一次營銷活動），或暫時沒有能力對美術效果還原做更多介入
（例如，藝術家給你什麼就用什麼）時，可以不考慮 3D 美術工作流的問題。可以把大部分精力投入到引擎的實現和最佳化上。
那麼怎樣的流程算是 3D 美術工作流呢？
比如，靈犀互娛的 C6 小組發揮了自身是工作室模式的優勢，他們（一群極富經驗的 3D 藝術家，APM、主美、技美，產品，運營、技術等）用一套嫻熟方式來完成了整個生產流程——SVN（檔案和版本管理） + Excel（資料管理）+釘釘（流程管理）。
比如，我們接過了靈犀互娛的工作流經過和淘系相關基礎平臺的整合，重新打造了一套線上 SOP 的美術平臺。其中的思考無外乎幾個原因：
- 我們組織架構達不到工作室的效果；
- 非中心化系統管理的方式風險高難追溯（釘釘之間來回傳 execl 確認資訊，有點人肉版區塊鏈的感覺）；
- 我們最適應和習慣的依然是線上 SOP。
那麼怎樣做才能做到專業呢？
首先確定需要合作的角色，一般來講有這幾種：2D 創意設計師（通常是 UED 的同學擔任），3D 藝術家（通常外包給供應商），3D 主美（這個看 UED 團隊的人員構成，通常是沒有或稀缺的，所以要麼外包，要麼想辦法分解他的職責），產品、QA。
緊接著確定需要生產的 3D 內容的種類、標準和差異化流程，明確各個角色在某種生產流程中在什麼時機介入：
然後，把這些流程以 SOP 平臺的方式實現出來。這樣的 SOP 美術平臺基本上是專項專用的，只有以專案為中心才能將一個個細節做到專業。
4.如何做到效果和效能的平衡
效能這個話題是無窮無盡，優秀的效能最佳化方案和文章也層出不窮。透過對執行時效能的最佳化可以一定程度上提升幀率，但再要提升一個量級就可能要損失效果。我們通常考慮會對中低端機做一些降級，顯然這樣的降級對使用者是有損的，例如降低解析度，減少光照計算（包括光源數量、全域性光照的計算等），減少動畫、物理特效等等。如何在不損失過多效果的前提下做到效能的最優解？
在做這樣的技術方案前，我們需要知道，對於不同的 3D 專案，有哪些手段來實現或者說還原藝術家想要的效果，如何可以把電影/CG 級別的效果能夠變成在執行時能夠實現的效果。不少玩遊戲的同學肯定知道，3A 遊戲大作要開啟高畫質高幀率（例如 4K 120fps，4xMSAA），就需要頂級的 GPU，但並不需要頂級的 CPU。這是因為 3A 遊戲在實現高畫質高幀率的效果時大部分依賴 GPU 的特性和運算能力，換句話說如今大多數的 3A 遊戲大作執行過程中，CPU 的運算是過剩的。
回到移動端上，C++ Runtime 和 JS Runtime 的邏輯運算效能對於一些展示性或不需要大量物理計算的 3D 專案效果的提升貢獻差距並沒那麼明顯。這類專案中的邏輯運算更多的是在處理資料組裝、使用者互動響應等。那麼哪些東西會影響效果的實現呢？
- 美術能力：一個具備優秀美術能力的 3D 主美是能在設計階段就可以把控創意和生產質量的，這將直接影響到整體專案的美術效果或觀感；
- 模型細節：通常模型都會先以高精度的標準去製作（例如影視用的標準），包括模型雕刻和紋理貼圖，透過減面和重新佈線拓撲的處理後可以變成適合執行時的精度（例如遊戲用的標準）；
- 物體材質：在現實生活中，物體的材質五花八門，把這些材質透過技術手段還原出來就非常關鍵，材質的還原主要依賴 Shader，以及依賴一些引擎對顯示卡特性的支援。另外，如果專案整體風格是卡通型的，就需要用到特定的卡通材質。這兩種材質可以分別統稱為 PBR（基於物理的渲染）和 NPR（非物理渲染）；
- 光照、陰影：光照和陰影是提升物體部位細節的重要手段，不同的材質對光照和陰影的計算要求也不盡相同。光照也分為直接光照和全域性光照，陰影也分為硬陰影和軟陰影，對計算要求也不盡相同。
知道了上述這些影響效果的東西后，我們就可以來分析下，如果儘可能去平衡效能。
第一、美術能力（創意和審美） 這塊確實沒法省，而且它對效能其實沒啥影響。所以要麼只能接受當下的現狀，要麼就努力去提升美術能力。
第二、對模型細節的分級處理，稱為 Level of Detail（LoD）。我們將同一個物體以不同面數的模型和不同壓縮比例的貼圖（Mipmap）來按需展示。執行時對於 LoD 的處理有很多種策略。比較常見有：場景（建築）遠處用 Low Level 的，近處用 High Level；使用者自己角色是 High Level 的，NPC 或其他玩家是 Low Level，當使用者接近 NPC 或其他玩家時再切換成 High Level。用什麼策略可以優先考慮滿足 30fps 的幀率，其次考慮整個場景需要表現出來的細膩程度。此外，UE5 的 Nanite 技術也是非常優秀的“動態 LoD”方案。
第三、對材質、光照、陰影的處理，首先明確使用者對於效果的期望。因為我們要做的是平衡效能和效果，硬上電影級效果並不現實，完全照顧效能有會讓畫面慘不忍睹。有了對使用者期望的調研和判斷後，無非就兩種選擇：實時渲染和離線烘焙。實時渲染需要進行大量的 GPU 計算，特別是光照計算在實時渲染中非常的消耗效能。在桌面級顯示卡因為有硬體光追加速或類似 UE5 的 Lumen GI 技術可以大大提升光照計算的效能效率，但放到移動端上就有很大的壓力。且材質、陰影都是光照計算的一部分，於是就有了離線烘焙的方式來減少執行時的 GPU 計算壓力。所謂的離線烘焙是指預先對場景內光照，物體的材質、陰影進行提前計算，生成 LightMap 或 ShadowMap，以便在渲染時利用這些烘焙結果展示接近實時渲染的效果。離線烘焙已經是個很成熟的技術，可以使用 Huodini 等軟體完成烘焙。在長期專案中，可以考慮將烘焙流程平臺化和自動化，而對於一次性專案直接交付可用的烘焙結果即可。
5.如何培養一隻有戰鬥力的 3D 團隊
想要建設或培養一隻 3D 團隊之前，要考慮清楚手上的專案需不需要你（假如你是管理者）這麼做，影響這個決策的因素有：
- 是否是個長期迭代的專案：有些專案初期立項的定位是含糊不清的，想長期迭代，但產品規劃上有不足以支撐，那就讓這件事情先緩一緩；
- 技術視野是否能覆蓋大部分 3D 領域的知識：要管理好團隊，管理者也需要在各個方面能都有判斷和決策能力，所以不能當一個“文盲”的 Leader；
- 是不是有了中臺就不用建 3D 團隊：先看中臺團隊能給於你什麼樣的支援，補充哪方面的能力；再決定專案中缺少的能力是否需要自己來補足。通常來講一箇中臺不可能提供所有 3D 專案中的需要涉及的技術支援，而你需要的判斷是接下來是否只需要中臺的 3D 技術支援就足夠了；
- 有沒有信心說服老闆和 HR 給於資源上的傾斜（包括 HC）：不能空有理想，巧婦也難為無米之炊。基於對專案的判斷和對技術發展的規劃決策，有助於說服能幫助到你的人。
接下來看下一隻 3D 團隊內都有哪些角色（不一定是你管理的）：
- 3D 主美：領導藝術家們，並和技術美術合作，為產品最終的美術效果負責
- 藝術家：分為 3D 美術、模型師、動畫師等，負責美術資產的生產工作
- 策劃：類似產品和運營的角色，需要具備一定的美術審美能力，輔助 3D 主美確定產品最終形態
- 美術 PM（APM）：管理美術工作流，協同角色、協調流程
- 技術美術：分為美術向、程式向等，配合 3D - 遊戲程式：使用 3D 引擎研發專案，交付最終產品（3D 遊戲部分）
- 引擎程式：研發或維護 3D 引擎，交付通用型 3D 引擎或專用 3D 引擎（如虛擬人引擎）
- QA：負責對美術效果進行驗證，對專案產品進行測試
這些工作當中適合沉澱到中臺（或通用型功能）有：3D 引擎研發、部分通用工作流或效果研發（例如：烘焙流程，LoD 流程，粒子效果），其他的基本都會隨著專案的變化而發生改變。
可以粗略的用一張流程圖來描述它們之間的流程和分工：
搞清楚 3D 團隊的職能分工後，對於需要補助的角色以及實在沒有角色時的替代方案：
- 3D 主美：策劃和技術美術來分擔一些對於美術最終效果的決策，但需要避免開發一些複雜的美術效果，例如：捏臉、捏身體等。
- 藝術家：通常這部分工作都可以有供應商來承擔，一些特別關鍵的可以透過外包方式進行管理
- 策劃：不可或缺，最好是具備 3D 遊戲類策劃的經驗
- 美術 PM：可以用 SOP 化的美術流程平臺來替代，但需要技術美術來研發這個平臺
- 技術美術：不可或缺，程式向技美可以解決工具研發的問題，美術向技美可以解決效果研發的問題
- 遊戲程式：不可或缺，可以從普通前端技術棧的同學中培養或轉型
- 引擎程式：如果是自研那需要有一名專家級的引擎主程；如果使用二方或三方引擎，那麼需要一名對 3D 和圖形學有經驗的人，這個人主要把專案的需求轉換成對引擎的需求，或在通用型引擎上研發特定的功能。
- QA：針對美術效果的驗證可以從非 3D 向的 QA 轉型或培養。
有了這些決策後，就用一個個專案來磨合這個 3D 團隊（雖然架構上是不同線的，但最好以工作室模式來協同運作），沉澱一份份經驗，不懼失敗和壓力，發揮最大的能量。
6.往後我們走好接下來的路
開頭講到，今年我們剛邁出淘寶人生元宇宙的第一步 —— 人生小屋，這是將淘寶人生的單個形象以更加豐富的姿態和互動展示出來的一步。我們首要的道路就是將淘寶人生的元宇宙規劃進行到底，讓每個使用者的虛擬形象在一個個不同的虛擬世界中暢遊。
面對越來越複雜場景和渲染要求上的技術挑戰，我們也依然會在美術效果、效能最佳化上開足馬力，並以 Web 引擎為主戰場（自研 3D 引擎、美術流程和效果）、藉助 Hybrid 引擎方案來過渡和爭取時間（加速產品落地進度）。當然，我們也不去押寶任何一款 3D 引擎，而是將虛擬人的技術、流程、經驗變成團隊最重要資產。
在社群方面，我們不會吝嗇經驗和沉澱，前端的精神就是開放的。今年 D2，我們會帶來《淘寶人生專屬“小屋” - 虛擬角色和虛擬場景技術探索》議題分享，歡迎屆時觀看！
