導讀：本文是淘寶前端技術專家——徐乾偉（燒鵝）分享的淘寶 Web 3D 應用與遊戲開發實戰，這個話題在業界被談及得比較少。今天将會從移動、3D、遊戲三種交叉的話題來和大家探讨。接下來和小編一起從初試 Web 3D、使用 WebGL、工作流相關的遊戲編輯器三個部分來了解吧~

徐乾偉（燒鵝）-淘寶前端技術專家，來自淘寶虛拟互動團隊，這個團隊主攻 3D /遊戲/ VR / AR 。其中，我們有一個小團隊叫斜杠實驗室，主攻 Web 方向上的動畫和 3D 技術。

為什麼我們會在這樣交叉領域去發力做一些事情？去年的雙十一淘寶去年交易額多少？一千多億，其中有 80% 的 GMV 是來自移動端的，簡單地理解就是說我們公司在電商領域 80% 的錢是通過手機客戶端賺取的，而不是 PC 。這就是為什麼在我們要在移動端做 3D/VR/AR 的應用。

有一句話叫：給我一個支點，我就能撬動地球。

很多人都做過 2D 遊戲， 3D 最大的區别就是多了一根 Z 軸，而給我一個 Z 軸我就能創造 3D 世界。很多做前端的同學對 3D 這個事情是有誤解的，比如說 HTML5 中的 Canvas 有兩個上下文，大家認為 2d Context 隻能畫 2D，WebGL context 才能畫 3D ，這是一種誤解。

其實 3D 和 2D 并不是由繪圖引擎來決定的，而是由數學家決定的。假如我們要畫這樣的曲面會怎麼畫呢？

首先有描述這個面的公式，這個公式根據 X、Y 入參算出 Z 的坐标值，假設 Z 越大顔色越紅，Z 越小顔色越綠，畫出來是這樣的。如果 X、Y、Z 乘以一種神奇的東西叫矩陣（矩陣是數學家發明的），這是 3×3 的旋轉矩陣，把每個點都乘一下，然後畫到屏幕上得到的結果就是這樣的。

大家是不是一臉懵逼呀~

關于如何用 Canvas 2d 繪制 3D 曲面，以後再詳細講解，我有一段時間寫過 CSS3D 的庫，就是用 glMatrix 數學庫做出非常酷炫的效果。

2016 年雙十一我們做過一個小遊戲，不知道大家有沒有玩過？

這個遊戲是用 Canvas 2d 繪制，就是用的 glMatrix 數學庫畫實現 3D 效果。當時為什麼用 Canvas 2d 呢？我們淘寶市場部的同學說我們要做 3D ，因為 pokemongo 做了一個 3D 的，但是你這個東西最後要給我搞到 iPhone 4 上去。大家知道 iPhone 4是不支持 WebGL 的，而當時開發時間非常緊張，我隻能用 Canvas 2d 的方案。

如果點了主場景中的貓，就會進入一個 AR 捉貓的環境。這個不是 web 渲染，因為當時移動端的 web 還不具備獲取攝像頭數據的能力，所以當時 AR 隻能用 Native 的 3D 引擎渲染，叫 T3D，顧名思義 Taobao 3D 。另外還有一個比較有趣的 AR 場景，叫“黃金貓”。黃金貓在雙十一前後三天會出現在銀泰或者蘇甯的商場上方，你隻要搶到了這隻貓至少有一百塊錢的紅包獎勵。

難點一：建築模型的制作，我們的設計師是個平面設計師，不會做 3D ，他當時給我的圖是這樣的，你看着辦吧，我當時花了整整一天時間做模型。

**

難點二：地面算法**，這個地面是六邊型的結構，要把地面從地球坐标系轉換成 3D 世界裡的場景，會分幾步。我們小時候都看過世界地圖，怎樣把一個球形的面投射到平面上呢？

這種投影叫做墨卡托投影（Mercator projection）。這個投影算法的代碼是服務端拷給我的，因為要保持前後端算法一緻，我複制了後端的投影算法。相比墨卡托投影，這是簡化的算法，因為要求看到周圍的貓是在五十米左右，所以精度并不是特别高，簡單的算法就能夠滿足了。

當時的視角是這樣的，以用戶當前的位置經緯度為中心，輻射一圈就可以看到周圍有多少隻貓。

這裡的六邊型地面如果用 X、Y 兩個軸的算法去計算其實是比較慢的，我當時看了一篇論文，這是一個斯坦福的同學花了二十年研究六邊型的算法，他本質上是以夾角為 120 度的 X、Y、Z 三個軸為坐标軸算，相比算 X、Y 兩個軸的算法快很多。上面還有很多基于這個基礎算法拓展的算法如尋路等。

好不容易跨過了雙十一的坎，我們已經看到 Canvas 2d 的方案在模型輸入和繪制性能方面都是非常弱的。

如何繼續開發 3D 類的遊戲呢？可能大家會問，WebGL 在 PC 上都不行，在手機上行不行呀？我跟大家說，現在完全沒問題，我們在上億台同時在線的設備上都試過了，前提是要做一下 WebGL 能力檢測。 PC 還有一些古董浏覽器不支持 WebGL ，反而手機比 PC 發展快得太多。

大家之前理解了 3D 的概念， 3D 不是繪圖引擎的功能， 3D 是數學的概念。那 CPU 繪圖與 GPU 繪圖有什麼區别呢？GPU 是并行處理每一個像素的。

我們剛開始嘗試 WebGL 小心翼翼，因為怕給手淘帶來影響，事實上也造成比較大的 Crash 。

2016 年的聖誕節，市場部同學說要不在手淘裡下一場雪吧，那就下了。後面我會和大家介紹下這場雪的代價。我們還嘗試做類似于右邊這種模型粒子動畫，這是一隻天貓的模型。這兩個都是粒子系統，因為我們剛開始不知道怎麼做複雜的 3D 渲染，我們隻能從最基礎的繪制“點”出發去嘗試。

我們團隊有一種叫 PopLayer 的技術，可以在當前 Native View 上面随時彈出一層 Web View。比如之前搜一下鹿晗出彈幕，還有明星打電話，都是通過 PopLayer 技術實現的。

上文提到，在淘寶首頁的 Poplayer 裡 下一場雪導緻了大面積的客戶端Crash 。原因是 iOS 下的 UIWebView 使用 webgl 渲染時，WebCore 會調用到 OpenGL ES 進行渲染，而蘋果發現有在後台調用 OpenGL ES，就會直接結束 App。

知道 RequestAnimationFrame API 嗎？解法就是監測當前用戶退出後台或當前頁面不可見時，會把 RequestAnimationFrame 停止。

小倩也提到過 Page Visibility 方面的 API ，我們發現安卓是支持這個 API 的， 但 IOS 還是需要調 Js Bridge接口來監聽 App 的是否退後台的狀态。接着，我把遊戲主循環（或者動畫主循環）停下來之後還發現一些用戶會 Crash 。最後我發現一件非常神奇的事情~這個代碼大家都知道，它是用來獲取Canvas的WebGL context，這行代碼為什麼Crash呢？我們翻了 Webkit 的源碼發現它有一個 reshape 函數，reshape 會通過 GPU 獲取當前畫布的高寬，所以它還是會 Crash 。

接下來将會分享 3D 之旅我們的心情，以及我的思維是如何進化的。

2017 年的造物節時我們做了真正意義上的 3D 應用，當時跟英國一家設計公司合作叫 FRAMESTORE ，這個電影（《奇異博士》）大家知道吧，特效就是他們設計制作的。

FRAMESTORE 當時給我的東西是這樣的，俯視圖是這樣的，燈光是這樣打的。雖然他們在影視特效領域非常牛逼，但是他們也沒做過 Web 應用。而我當時也不知道怎麼和設計團隊合作，還是我的老方法手寫代碼。他們給我的模型，我當時也不知道其他高級的格式，隻知道 Obj Mtl 。如果發現 WebGL 渲染有問題，我們就去代碼裡找原因，模型引用的材質對不對，貼圖對不對。我們要翻代碼看一下是不是引用錯了。工作流的問題在這個項目中沒有解決，但是促使我開始尋找問題的解法。

這個項目還有一個性能問題，廣告牌發光效果，我第一個想到的是後處理（Post Processing），大家不理解的話，可以把它當作實時濾鏡，如果在手機屏幕這麼大的 Bloom 濾鏡是會卡死的。我當時的方案是在每塊廣告牌上寫一個獨立的 Shader ，這樣在iphone6上至少是可以流暢渲染的。

上面講了這麼多，痛苦和迷茫。其實我之前做的東西也不能稱之為真正的遊戲，隻能算是營銷互動類遊戲。

我們還是覺得做遊戲要向業界規範的方案靠攏，所以 遊戲編輯器是必須要做的。雖然我今天并沒有做出一款遊戲編輯器，我會跟大家分享為什麼我要做遊戲編輯器（現在已經正在做了），這中間的坎坷是今天要講的重點。

和英國團隊合作之後我非常難過，他們的設計做得那麼酷，而我隻能實現成這樣。我在中國環顧一圈，沒有看到 Web 3D 遊戲方面比較好的方案，因為在中國做 WebGL 的都鳳毛麟角。

2017 年我去澳洲參加了 Web 3D 大會，他們當時用了 X3dom 像 HTML 一樣用标簽地描述 3D 世界。

這是一種非常陳舊的技術，雖然也是基于 WebGL 渲染。這個方案已經推了十幾年了，老外也不知道為什麼這麼執着，有幾十個 Paper 都是講這個的。他們講的東西都非常學術，我覺得對我們的幫助并不是很大。

然後我又去工業界尋找解決方案。這是前索尼 PlayStation 的一位同學做的應用，他用的技術大家可能會大吃一驚，他用了Unity。第一次看到 Unity 和 Web 嫁接起來是非常令我震驚的。我當時用的是 iphone6 ，運行這個 demo 都是 60 fps 滿幀，他是怎麼做到的呢？我去查了一下它的代碼，雖然代碼是壓縮過的，但是為了突破這個技術難關，我閱讀了壓縮後的代碼并且理解了它背後的實現。

我發現裡面有各種各樣的新穎的技術。比如，Unity 可以合并 3D 模型的貼圖。

合并貼圖這件事情是很重要的。做前端的同學都知道雪碧圖，為什麼做雪碧圖？大家都知道是為了減少網絡請求數，但是其實合并貼圖對運行時的性能有很大影響。

GPU 讀一張圖快還是讀十張圖快？計算機資源是非常寶貴的，圖片要适度合并盡量壓縮。一張 200K 的圖片，可能占用 3-4 倍的顯存。 JS 優化半年減少 30K ，圖片批量壓縮減少個幾兆都是有可能的，所以要把時間花在能夠快速見效的事情上面。

下圖的 Texture Baker 就是用來烘培并且合并圖片。這個是 ITween Path 是 Unity 做路徑動畫的插件。

Unity還有一個插件叫 Collada Exporter 。Collada 是标準的 3D 模型格式，看到這裡我們已經抛棄了之前 Obj Mtl 的老方案。而Runtime根據我之前的開發經驗封裝了一套 MVC 的方案。

基于這套工作流，我們做了 2017 年雙十一切紅包項目。我們經常調侃：騰訊做遊戲和阿裡做有戲有什麼區别？騰訊做遊戲是收錢，我們做遊戲是發錢。用 Unity 帶來的好處是能夠直接導入設計師給的源文件，如 Maya 源文件、 Photoshop 源文件。這裡我們看到，紅包模型是預先切開的，大家知道切水果也是這樣做的，即使你豎着切菠蘿它還是橫着裂開的。

至于紅包的特效，我會經常逛一些國外的網站，這是某個遊戲開發者寫的 Shader 特效，我就照着他的思路來寫了一個類似的。

大家看到一個紅包在天上飛，上面有光在流動，其實整個場景中一盞燈都沒有打。光照計算，特别是點光源的計算是非常耗性能的。所以大家做 3D 應用的時候盡量要少放光源。這種效果其實隻要在像素着色器中寫一行代碼就解決了。

紅包是怎麼切中的呢？Picking 這個話題對沒有開發過遊戲的人也許比較陌生，切紅包的遊戲裡我當時做了兩種方案：一種叫做 CPU Picker ，另一種是 GPU Picker 。

CPU Picker：在每個紅包上面套上一個包圍盒，計算射線有沒有擊中這個包圍盒，因為 CPU Picker 的計算成本和場景的複雜度正相關， 用包圍盒會比較快；

GPU Picker：通過拾取離屏畫布上面的顔色值就行了。

雖然感覺 GPU Picker 性能會特别好，但在移動端性能表現卻不佳，因為拾取顔色的過程實際上是 CPU 和 GPU 通信的過程，這個過程會比較慢。所以，CPU Picker 性能會更好一點。

還有一點就是 Dom 操作，在 Web 遊戲開發中，Dom 操作就是魔鬼。我抓了比較慢的一幀花了 25 毫秒（約 40 幀）。

遊戲邏輯加上 Web GL 渲染就花了那麼幾毫秒，而 DOM 操作卻耗掉很長的時間，而且還引發了重繪（紫色部分）。

所以 Dom在遊戲裡是不合适的，GUI 部分需要用 2D 的 Canvas 或者 Web GL 渲染去解決。

最後講一下音效，我個人非常喜歡遊戲中聲音給我帶來的獎勵。我做切紅包的時候注意到了上面幾點，這也是我上周去北京 Unity 大會上聽到關于 CRIWare 的聲音中間件的内容：

• 背景音樂要有漸有漸出，這樣用戶體驗比較好；
• 用戶做一些操作或者比較重要操作的時候，當前聲音要強調一下，背景音樂減弱一下；
• 聲音要有變化，比如說很多射擊的遊戲，如果槍聲都一樣，用戶聽覺會疲勞的，我們切紅包時左切和右切都是不一樣的。

這個軟件叫 bfxr，是一款制作遊戲音效的小軟件，在線和客戶端版本都有，人人都可以設計音效。

講了那麼多技術點，我們總要看一下業界真正做遊戲的人是怎麼做的。我大概探索了一兩年，發現 Playcanvas 引擎是 Web 世界上最健全的遊戲引擎。它的引擎代碼是開源的，但是編輯器不開源。我分析了一下它的引擎源碼，大概有幾部分組成：

• ECS 的架構，Unity 也是采用這樣的設計模式。
• PBR，基于物理的渲染模型，看起來更像真實世界的渲染。物理引擎也是很重要的，還有輸入設備，比如說你的遊戲手柄、手機都是輸入設備。

Playcanvas 和 Threejs 有什麼區别？

Threejs 隻是一個 3D 渲染庫。遊戲還有一個非常重要的東西叫編輯器，這是 Playcanvas 在線的編輯器，我看了這個遊戲之後就覺得一定要做編輯器，因為編輯器是引擎的載體。如果沒有編輯器，我們每次開發遊戲要注意的工程和技術問題太多。

最後講一下我們團隊思考的編輯器的架構，現在隻是一張工程架構圖。

遊戲最後發布的内容是什麼？就是一堆資源，圖片、模型、音頻、腳本，在 Web 開發環境中最後都要發上 CDN 。

遊戲裡的大部分資源如音頻、全景圖、模型這些都是第三方軟件輸入的，模型資源的序列化、減面、合并、烘培等操作我們暫時可能不會去做（還是交給 Unity 做），中間 GUI 部分就是編輯器的面闆操作，最後 Script 組件和 Shader 可以通過 Vscode 來編輯。這張圖是我一兩年的心得，大家可以留言區交流~

作者：徐乾偉(燒鵝)

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!