雲計算

淘寶人生裡的虛擬人像渲染技術

作者 | 冬去

本文根據4月20日淘系技術前端團隊出品的「阿里淘系用戶體驗優化前端實戰系列直播」——《淘寶人生裡的虛擬人像渲染技術》整理而成。

點擊查看視頻

image.png

行業背景

總覽

首先大家可以回想一下,無論是你們看過的電影,還是玩過的遊戲,有沒有主角不是人類的?不光主角,NPC、敵人、故事、等也統統和人類沒有關係,有沒有這種作品?我相信多少也是有的,比如《動物世界》或者《探索宇宙》等之類的題材,但畢竟還是少數。大部分還是以人類題材為主。

今天遊戲和影視領域都已經是非常成熟和發達的產業了,而它們在創作的時候,都不可避免地要研發有關“人體渲染”的技術,比如毛髮、衣服、皮膚的渲染,又比如喜怒哀樂、摸爬滾打等各種人類表情和動作等等,都會頻繁被用到。比如,《阿麗塔-戰鬥天使》花費 14 億在虛擬女主上。

image.png

再舉一個例子,2018年,由騰訊和Epic聯合開發的高仿真虛擬人Siren在當年的GDC上亮相,由一名演員在背後做動作和表情,虛擬人就能跟著被高質量且實時地渲染出來。效果十分驚豔。因此可以看到,整個行業是逐漸表現出對這一塊垂直領域技術的研究興趣。

image.png

跨界典型應用

當然技術甭管怎麼厲害,最後也要看能帶來什麼業務價值,還能有哪些更廣泛的應用場景。說到場景,其實有一個特別好的文化現象,B站的小夥伴一定不會陌生,那就是和二次元文化結合得特別緊密的“虛擬偶像”。

“虛擬偶像”這個話題真要說起來還是蠻大的,我這邊準備了一個案例簡單給大家分享下。和大家想到的“純粹的二次元偶像”不太一樣,她其實是一位真實網紅的“替身”。

image.png

這個美麗的小姐姐叫Pokimane,是來自加拿大的Youtube達人,她是Twith和Youtbue上的知名女主播,坐擁300萬粉絲,去年(2020年)9月的時候使用了一個虛擬形象代替自己進行了一次直播。大家可以感受一下效果。不過這個事件當時還引發了一些爭議,這個我們今天就不提了。

根據Hyprsense的調查,從2018年3月至2019年5月,Youtube上日本地區的”虛擬主播(VTuber)“數量逐月穩步上升,預估全球有超過1w位這樣的VTuber。

說了這麼多,大家可能比較好奇,這些東西和淘寶有什麼關係?難道淘寶裡也有虛擬偶像麼?我的回答是“可以有”,而且這位“偶像”不是別人,就是你自己。

關於我們

淘寶人生

也許有一些朋友已經知道淘寶人生了。不知道的也沒關係,你只要打開手淘,按這個步驟做一次,就能分分鐘創建自己的虛擬形象。

image.png

你在裡面有各種各樣的玩法,比如說去拍照,走格子,抽套裝,捏臉,換裝,美顏,等等。大家可以自己探索下。

淘寶人生這個業務,主打的是情感向的互動方式,希望能吸引年輕新生代在手淘的粘性,讓這個地方成為連接品牌與消費群體的活躍陣地。

image.png

淘系互動團隊

“淘寶人生”這個產品是一個很大的項目,涉及到不少兄弟團隊的協作。而我們淘系遊戲互動團隊從去年開始支撐這一塊的前端業務,並重點研發基於淘寶人生的虛擬人像渲染相關方面的技術。當然我們這方面的建設也借鑑了不少業界的做法和前人的經驗積累。

image.png

除此之外,我們團隊還有“芭芭農場、“淘金幣”、“省錢消消消”等更多的淘內互動遊戲產品,以及各種營銷大促的業務場景。歡迎大家都去體驗一下。歡迎大家都去體驗一下。我們也在一直長期招募優秀的人才,有興趣的小夥伴可以掃這個二維碼加關注,併發簡歷給我們。

image.png

技術內幕

渲染基本流程

在技術這個環節,我們再展開講四個方面內容,分別是“基礎流程和管線”、“換裝和美顏是如何做到”、“捏臉是如何做的”以及“如何與AR互動結合”的。

image.png

首先講一下基本的流程。當用戶進入淘寶人生的時候,程序會先加載全部的模型、紋理和材質等資源。然後讀取基礎的數據,這些數據對所有用戶都是相同的,可以理解成是一個公共的人像模板。

然後再讀取用戶個性化的數據。剛才我們提到,用戶在淘寶人生可以換裝、美顏和捏臉,那麼這些用戶個性化定製的數據也會作為”人像像配置“存放在服務端。程序根據這些配置會動態加載個性化的道具、裝扮、骨骼和表情等各種模型資產。所以這部分數據就是差異化的部分。

加載好後,就需要將這些個性化的模型數據應用到公共的人像模板上,該替換的替換,該合成的合成,該修改的修改。這些細節我們等下會展開說。最後進行渲染,講到渲染的話,先普及一點實時渲染的基礎,就是渲染管線。

image.png

渲染管線基礎

人像渲染技術,歸根到底還是“3D實時渲染技術”的一個子領域應用,說到“實時渲染技術”,就離不開對“渲染管線”的理解,什麼是“渲染管線”呢?其實“管線”這個詞已經很精妙地描繪出它的含義了,就是把上一個環節處理的數據丟給下一個環節去處理,當中CPU和GPU都會參與,但GPU參與的部分更多更重一點。一環扣一環,數據就像在一根管子裡流動一樣,是不是很形象?

經由這條管線繪製一次以後,就能畫出一點東西,它被存放在顯卡的幀緩衝區裡。在實際應用中,實際上只花一次是遠遠不夠的,因為這樣只畫出了一部分內容。每次畫完後,我們或多或少都要調整管線,比如切換材質、切換模型頂點等等,再畫一次,如此往復。每多畫一次,幀緩衝區裡就多點內容。那麼經過很多次這樣的繪製後,一副完整的圖像就被畫出來了。

我們淘寶人生也是類似這麼一個重複繪製的過程。比如說這位漂亮的人偶,她有腦袋、頭髮、眼睛、還戴著眼鏡,配飾,這些模型的網格頂點、材質紋理、渲染狀態都是不一樣的,所以要一步步地畫。從分解圖中可以看出,至少要畫9次,才能將她的頭完整地繪製出來。

image.png

當然啦,由於時間關係,這裡關於“渲染管線”的講解還是很粗糙的,目的只是給大家提供一個比較直觀的體驗。而且業界基本也都是這麼做的,並沒什麼特別的地方。大家可能也更關心,“淘寶人生”在開發的時候有什麼特別的地方嗎?接下來我們就來談一談。

換裝美顏技術實現

之前介紹過,淘寶人生的一大特色是“換裝和美顏”,玩家也會更容易注意到這部分,比如換衣服褲子鞋子、換眼影睫毛脣彩等等。因為這些入口更加顯眼。玩家能換這麼多元素,可以想見不可能每針對一組變化,我們都提前準備一套完整的模型用於渲染,這是不現實的。那我們是怎麼解決的呢?其實”換裝“與”美顏“的實現方式也不太一樣,所以我們分開來說。

道具動態加載

“換裝”的思路比較簡單,其實就是預先製作好各種道具本身的模型,當讀取到用戶的個性化配置數據後,就獲取到對應道具的ID,然後加載這些模型資源,包括上衣、褲子(包括裙子)、鞋子、眼鏡、耳環、項鍊、頭飾等等。它們都是獨立的模型,有各自的材質、紋理等配套資源。

image.png

這些道具被動態加載後,會掛載到人體對應部位的”骨骼“上。然後會隨著渲染管線的流程,一步步地隨著人體一起渲染出來。我們在這個基礎上,還做了一個優化點。大家仔細想一下就會發現,渲染衣服的時候,衣服會”包裹“在人體上,那麼其實這時被包裹的那部分人體就看不到了。那麼如果還渲染那部分模型網格數據的話,就是一種浪費。而且這也不僅僅是浪費的事情,有時候它還會帶來更大的問題。是什麼問題呢?

大家知道服裝產業是非常成熟的,尤其是女孩子的衣服,真是千變萬化多種多樣,比如有大風衣,也有小吊帶。那麼美術同學製作出來的一些道具,比如說鞋子,配到模型人體上的時候,有時就會有”穿模“的現象出現。理論上仔細調整道具也能解決,但這樣做成本實在太高了,而且模型做動畫的時候也還是有瑕疵,效果不好。整體來說就是性價比太低。

因此我們研究了一種辦法,就是在美術製作的時候把人體”分塊切割“,進行標記。然後將各個道具與這些分塊部位關聯。這樣遊戲中在讀到某件道具時,就知道哪塊人體部分不需要渲染。那麼就真的不把渲染它們出來。這樣既減少了渲染量,也解決了穿模的問題。一箭雙鵰。為了實現這個功能,我們專門實現了一套完整的基於Unity的編輯插件,方便美術同學使用和標記。

image.png

”換裝“的思路其實還是比較簡單,說到底就是切換不同的道具模型而已。相比之下,”美顏“就更困難些了。接下來我們看看”美顏“是怎麼做的。

紋理動態合併

我們說“美顏”比較困難,是因為所有的效果都是體現在一個面上的,也就是臉。有女朋友的同學可以想象一下你們女朋友化妝的樣子;沒有女朋友的也不要著急,畢竟單身的日子還會很長:-)。是不是在臉上擦一層粉底,然後畫畫眼線啦刷刷睫毛啦塗塗口紅啦什麼的。這些效果都不是網格頂點,不好用“換模型”那種思路解決。

image.png

一般來說,表現模型表面細節特徵之類的效果,業界都是用“紋理貼圖”解決的。比如衣服的紋路,臉上的皮膚等等。所謂“貼圖”就是貼在模型上的一張圖。所以我們這裡提到的眾多“美顏”效果,用貼圖來表現也是最合適的。一般的貼圖也都是美術提前做好的,用的時候貼上去就行了。我們的基礎頭部效果也是這麼做的。但問題在於,我們的場景中,臉部貼圖上的美顏細節,都是用戶親自精心調製的,我們無法提前製作。

image.png

所以我們的做法是“動態合成紋理”,思路是預先準備好各種美妝部位的局部構成圖,同樣根據用戶的配置數據加載這些圖片資源,包括有粉底、美瞳、眉形、睫毛,脣彩,男生的話還會有鬍子等等。

這些圖片被加載後,會在GPU上經過一次簡單的渲染管線,合成生成一套新的完整臉部的細節紋理圖。然後再次隨著第二次渲染管線的流程,作為臉部模型的紋理被渲染出來。這種思路是比較巧妙的,等於是第一次渲染的結果被用於第二次渲染的原材料,充分利用了渲染管線靈活的特性。當然這個技術也有專門的名字,叫“渲染到紋理”(Render To Texture)。

這就和炒菜一樣,你想炒肉菜的時候,你把生肉下鍋炒熟就直接吃嗎?不是的,你會先把它盛出來,再炒其他的配菜,然後再把剛才的肉放進去。所以這個肉就成了在第二次炒制的過程的原材料。道理是一樣的。所以說,渲染管線和烹飪一樣,都是藝術。

image.png

架構示意

我們設計了專門的對象來統一抽象和處理這種“動態合成“的特性。叫“Renderer”。我們將Renderer設計成層次樹形結構,每個部位都有對應的專有渲染器。最頂層有CharacterRenderer,下面分出HeadRenderer和BodyRenderer。其中BodyRenderer主要封裝了“道具動態加載”的特性,而HeadRenderer同時封裝了“紋理動態合併”相關的特性(我們稱為TextureMerge)以及“道具動態加載”的特性,因為像耳環、眼鏡外掛物等也屬於臉上的“道具”,而不是“美顏”。各自下面還有一些更細的子Renderer,大家看示意圖就好。

image.png

效果優化

這一部分的最後,我們再介紹一點其他有趣的東西,就是有關效果的優化。淘寶人生使用的主要材質還是基於PBR的,PBR材質是什麼意思呢?它意思是“基於物理渲染的材質”,就是說計算一個像素的顏色時,儘可能地模擬了物理學科方面的原理,像光學和輻射學這種學科。比如“遵循能量守恆”、“微面理論”、“遮蔽現象”、“菲涅爾現象”等等。這個知道的同學就懂是什麼意思,不知道的同學回頭可以去了解一下。這裡簡單聽聽就好。

當然這方面的研究和應用已經很成熟了,這些複雜的計算公式被提取抽象出來,我們稱為“光照方程”、“渲染方程”或者“光照模型”,總之意思差不多。業界有不少這種計算公式,代表抽象的特性也不太一樣,但大同小異吧。這裡面最有名的應該就是由Cook-Torrance提出的BRDF(雙向反射分佈方程),大概長這個樣子:

image.png

拋出這個公式也不是為了唬人,因為PBR其實已經是“真實感渲染”的基礎,大部分基於webgl的主流3Dweb引擎都實現了對PBR材質的支持,業界中的gltf模型規範中也有對PBR這一塊的定義和描述。所以淘寶人生用PBR材質也沒什麼好奇怪的。這裡想講的是額外做的材質效果,從而提升最終的畫面體驗。我這裡舉兩個例子。

第一個例子是“次表面散射材質”。它用來描述光線穿過透明/半透明表面時發生散射的照明現象,是指光從表面進入物體經過內部散射,然後又通過物體表面的其他頂點出射的光線傳遞過程。特別適合用於表現類似皮膚、樹葉、蠟像、玉石之類的效果。淘寶人生渲染的是人像,我們希望能儘量模擬出一點“皮膚通透”的質感,因此也實現了一個簡單版本的3S材質。

image.png

第二個例子是“各向異性材質”,它是指物體表面在互相垂直的兩個方向上具有不同的表現特性。這麼說可能比較抽象,比如說鋁製金屬物品,在某些方向會顯示出特別有指向性的“光柱”。淘寶人生裡有不同的髮型、衣服等,他們都可能有不同程度的各向異性特徵,因此也做了相關的模擬和實現。

image.png

總結

由於時間關係,這一塊相關的內容我們暫時就介紹到這裡。我們這裡簡單總結一下,我們談到了應對“換裝”與“美顏”的兩種不同解決方法,一個是用動態加載道具模型的思路解決,並做了隱藏與顯示的優化;另一個是動態合併貼圖,充分利用了管線靈活性的能力;此外我們還談到了材質效果上的一些加成優化。接下來,我們將目光轉向淘寶人生的另外一個特色,”捏臉“。

捏臉技術實現

在淘寶人生裡可以“捏臉”,甚至“臉部局部精修”。比如你可以調節臉型寬窄,調節頭部大小等等。這裡的問題是,它們都是針對已有模型數據的修改和變化,不是說要”換模型或素材“,思路不一樣。那這塊是怎麼做的?

所以我們的問題聚焦在,如何提取並描述這樣一組組的”變化“呢?一般來說,3D渲染技術中經常會用到兩種技術,”骨骼蒙皮”和“頂點變形”,我們分開來說。

骨骼蒙皮

第一種是我們對頂點施加某種”變換“,簡單來說就是包含了位移、旋轉和縮放三種影響的一組數學公式。頂點被這樣的公式重新計算後就能獲得新的位置,從而實現了”變化“。那麼這種”變換“是如何影響人體呢?說到這裡要引出一個概念,就是”骨骼“,或者叫”關節“。想象一下抬起你轉動頭部這個動作,其實就是頭圍繞脖子旋轉一定角度。如果我們給人體的脖子安插一個這樣的”變換“,那麼掛載在脖子部位的所有東西(比如頭)就能被移動、旋轉或者縮放。

這裡要注意一點,就是提前要先設置好有哪些頂點會受到這個”關節“的影響,從而讓關節帶動對應的頂點運動,這個技術我們稱為”蒙皮“。經過蒙皮後,一個關節或者說骨骼,就能帶動一大片頂點的運動。

image.png

所以淘寶人生的捏臉部分,我們使用了骨骼變換的技術達到讓模型變化的目的。舉一個例子,調整頭部大小。玩家在控制器裡調大頭圍的參數,本質上是對頭部安插的關節進行了”放大“操作,那麼對應的所有頭部的頂點也都跟著被放大了。淘寶人生中用於”捏臉“的骨骼大約有20多個,包含了頭圍、眼球、眼角、眼眶、顴骨、臉型等等。

image.png

骨骼變換的方法很好用,因為它能高度抽象這種類型的變化,也容易理解和操作。但凡事有兩邊,對另一些”變化“它就沒那麼容易了。比如說,淘寶人生裡也能調節嘴角的上揚角度,這種功能用骨骼來做是很難做的,因為它只能表達位移、旋轉和縮放中的一種或組合。無法進行逐頂點變化操作。要讓嘴角上揚需要每個頂點都有不同程度的變化。那這種是怎麼做呢?

image.png

頂點變形

這就涉及到了第二種技術,簡單說就是直接修改頂點。因為模型是由網格組成的,網格又是由頂點組成的。3D模型裡提供了原始的頂點位置,那如果有辦法直接修改頂點的位置,那就能修改模型的外觀了。當然具體實現還是要講究點手法的,否則也不太好描述頂點到底怎麼”變化“。一般來說我們會給頂點準備一個基準位置,再提供一個”極端變化“後的最大位置,那麼乘以一定的”權重比例“,就能讓這個頂點在基準位置和極端位置中的任一位置。這種技術業界一般稱為”Morph Target“,也有的叫”Blend Shape“。總之都是指頂點變形的意思。

image.png

這種技術特別適合彌補”骨骼變換“方法的不足,也更容易做出靈活、活潑的頂點動畫。淘寶人生中的”捏臉“部分,大約用到了40多個這樣的”頂點變形器”,包括有眉毛、眼瞼、瞳孔、眼皮、嘴巴、下巴等等。

image.png

但頂點變形也有自己的問題,骨骼可以用一個關節都能管理一大片頂點,而頂點變形是直接修改頂點,所以就要多準備幾套不同的頂點,比如原本只用100個頂點來畫嘴巴,但因為要支持幾種不同的變形,就要翻倍成幾百個。這個很吃資源,對實時計算壓力也不小。所以在實際開發中,哪些用骨骼,哪些用頂點變形,這是一個權衡“效果”與“效率”的工作,需要具體去看,反覆拿捏。而且這些調整與上游的美術製作成果結合的非常緊密,需要程序員與藝術家一起去看。

image.png

架構示意

我們設計了專門的對象來統一抽象和處理這種“變化”,叫“變形組件”(ModifierComponent),然後設計了統一的數據結構來描述這兩種變化,使外部不用關心細節,儘量用統一的思想操控它們。這個外界可能會影響到上游的美術同學、業務開發同學、乃至最後的玩家用戶。而內部我們會分出兩個子變形器,分別是骨骼變形器(BoneModifier)和頂點變形器(MorphModifier),會具體解析不同變形數據的含義。

image.png

動畫及更多應用

骨骼蒙皮與頂點變形不僅用於捏臉,實際上業界用這些技術更多是做“骨骼動畫”與“表情動畫”的。因為原理是類似的,這時只要準備好相應的動畫文件,就可以用這些文件驅動對應的骨骼和頂點運動了,就像是播放一段動畫一樣。甚至我們可以走的更遠,用其它類型的數據驅動它們運動。我們在稍後的話題中,也會介紹下它們和算法和AR方面的結合。

image.png

總結

這一部分也講的差不多了,我們來回顧一下。我們談到了兩種常用的用於描述和實現”局部變化“的技術,一種是”骨骼蒙皮“,另一種是”頂點變形“。它們各自都有優劣,需要結合使用,同時權衡效果與效率。淘寶人生的”捏臉“部門一小半使用了骨骼蒙皮,一大半則使用了頂點變形。這也是長期磨合的結果。這些技術不僅可以用於捏臉,其實只要理解了原理,它們有更多的場景可以發揮。接下來我們稍微再花一點點時間,簡單聊聊它們與“AR互動技術”的結合。

AR 互動技術實現

剛才我們講過,骨骼蒙皮與頂點變形作為渲染技術的底層基礎,可以有很多應用,比如說“捏臉”,也可以播放預製好的骨骼動畫和表情動畫。去年的時候,我們開始嘗試“真人驅動做表情”的技術。於是我們和淘系的兩支兄弟團隊緊密合作,他們分別是淘系多媒體算法團隊與淘系AR平臺團隊,經過近半年的努力後,我們終於將這部分的成果上線,大家可以在淘寶人生的拍照裡,打開“AR頭像”就能體驗到。不過注意先將手淘版本升級到最新。

這個功能在工程方面的流程還是比較容易理解的,簡單說就是我們使用AR相機實時拍攝用戶的臉部表情,底層算法會實時提取出面部表情特徵,並輸出成骨骼信息與Morph表情信息(也就是頂點變形信息),然後將信息傳給渲染層,我們拿到信息後再實時替換淘寶人生的人像頭部相關的數據,這樣就能讓真人驅動虛擬人做表情了。

image.png

算法團隊的算法也比較高級,這種算法是基於深度學習的框架,克服傳統視覺算法泛化性不強的缺點,從海量臉圖像中解耦外貌、臉型、表情等信息,因此準確提取出人臉共性的表情特徵表示。

同層渲染

在開發的時候我們遇到一個問題,就是我們自己是Web層的渲染技術,而想要使用人臉捕捉和背後的算法,需要特殊相機能力的支持,也就是AR平臺團隊提供的“AR相機”。但這種富能力的相機是做在Native層的,與Web並不相通。為了達到這個目的,我們使用了淘系技術自身研發的“同層渲染組件”作為二者的橋樑,從而在Web的容器裡能直接使用來自Native的組件。大家看到的這個AR頭像,手機相機拍到的畫面就是由AR相機透過“同層渲染組件”給到我們這邊的,而其它所有的元素,都是Web自己提供的元素。

image.png

架構示意

為了能夠合理地整合和調度來自算法、AR相機和人像渲染的能力,我們專門開發了一個獨立的技術庫叫“ARCapture”,對相應的能力和部件做了科學的封裝和架構。大家可以看這個庫的內部架構圖。

image.png

效果優化

在開發ARCapture的時候,我們也做了不少優化。這裡舉兩個例子。

第一個是關於眼球跟隨。之前講了“頂點變形”與“骨骼蒙皮”的技術,也談到了通過算法可以將真實人臉的表情與運動捕捉下來並轉化成對應的數據。但是,當時的算法雖然轉換了眼部相關的表情數據,卻沒有直接提供眼球的運動,因為眼球是骨骼驅動的,比如說旋轉,這個能力當時算法是沒有的。因此我們當時決定自己做這個計算。

簡單說就是,根據眼部肌肉相關的BS係數,根據權重值,推斷出眼球的運動,因為二者關係是可以擬合的。比如說當“向右看”這個行為,眼角的肌肉是變化的,算法也能給出這個變化係數,那麼我們也能找到辦法手動計算出眼球骨骼相應的偏移量。

大家可以看這個示意圖。真人眼球的運動,通過計算就能真實適配到渲染的人偶中。

image.png

第二個是關於相機系統。大家知道在渲染引擎中是有相機(Camera)系統這個抽象概念的,當然到了渲染管線底層還是會作為其中一環服務於整體的“空間變換”的目的。但AR相機也是對一個相機系統,它抽象了用戶手機的真實相機。因此就有兩套相機中的某些參數不對應導致效果奇怪的問題。

比如fov,也就是“視場角”。這個是相機中都會存在的概念。我們渲染引擎相機的fov是可以直接設置的,但問題是AR相機並沒有直接提供fov的參數,因為這和AR相機的畫幅比例有關;但AR相機給了我們更底層的一些信息,比如“內參矩陣”,代表真實相機內置的數據,比如鏡頭焦距等等。因此我們根據這些信息進行了計算,重新得到了適用於渲染引擎的相機fov。從而能讓虛擬人像的臉部和真實人臉完全對上。如果這個值計算不對,一開始沒什麼問題,但當人離著更遠的時候,就會發現兩張臉的位置就對不精準了。這會很影響用戶體驗。

image.png

總結

到這裡也總結一下,我們結合了兩支兄弟團隊的力量,利用“識別算法”和“AR相機”進行驅動,讓我們的虛擬人像與真人連接在了一起。同層渲染組件技術也將Web和Native彼此打通,從而讓Web更深入地使用設備底層的能力。對接兩個不同的相機系統時,還需要做一些特殊的適配,才能達到完美的效果。

為什麼是 Web ?

Web 的劣勢

最後我們聊一聊我們的技術選型。

這麼複雜和龐大的工程及技術,離不開上層渲染引擎乃至遊戲引擎的支持。我們是基於Web的產品,因此使用的來自Web技術棧的引擎。在一個階段裡我們選用的是LayaAir,這個在國內的知名度應該也比較高。不過考慮到未來能夠更加自由和靈活地定製底層渲染能力,我們正在使用阿里淘系自有的Web3D引擎,也就是Hilo3D進行遷移和重構了。實際上,目前線上有一部分用戶看到的已經是Hilo3D引擎來渲染的了。目前線上有一部分用戶看到的已經是Hilo3D引擎來渲染的了。

image.png

為什麼選擇用Web做渲染這塊的東西。那在回答這個問題之前呢,我想先反過來談一下,就是用Web做有什麼不好。

首先就是對預加載的支持不夠好。如果是Native的話,很多重要的、大塊的基礎模型數據都可以預埋在端上。只要App裝好了,那麼這一大塊數據也就裝好了。但Web的話就要等打開頁面的進行加載。這也導致了我們對數據資源使用上的“吝嗇”,比如貼圖分辨率不是很高,也不敢用更高質量的美術資產等。

image.png

其次是Web的渲染效果還是比不上Native的,運行效率也差Native一個量級。這有很多原因,比如WebGL在很多能力上都比不上原生的OpenGL,甚至連OpenGL-ES的能力也有兼容性問題。比如說一次繪製時頂點著色器能使用骨骼數量是有限的,這導致我們無法在身體上安插過多的骨骼。另外WebGL是瀏覽器封裝的圖形接口,不像Native那樣直接使用的是OpenGL-ES的接口,畢竟是又隔了一層,效率上也有不小的影響。有些瀏覽器中間用了ANGLE做了翻譯,可能在某些windows平臺上被翻譯成了DX,這也會導致使用GPU能力的一些兼容性問題。

image.png

Web 的優勢

那為什麼我們還要用Web呢?我認為最重要的原因還是因為,我們是長在手淘內的一個子業務。今天淘寶的用戶體量這麼大,手淘擔當的角色也非常重大。我們不可能因為今天要做淘寶人生的業務,就把這麼重的數據都預埋到App端上去,像做一個正式的獨立遊戲App那樣來做淘寶人生是非常非常不現實的。因此還是Web的環境更適合這篇土壤。

image.png

其次Web本身的優勢就是靈活,對發版節奏不像Native那樣死板和被動,如果我們想上一個新特性,用戶再次打開頁面的時候就已經更新了。而Native除了等待發版節奏外,還要祈禱用戶願意去升級。如果不願升級,那還是沒轍。另外,Web也很敏捷,離業務產品非常近。只要我們自己的架構做得好,明天要是上一場圍繞淘寶人生演繹的大促項目,那這些能力還是能很快就用過去的,Native就非常不適合這種場景了。

image.png

最後,其實大家自己玩玩淘寶人生就能體驗到,雖然在渲染效果上比不上Native,但70~80%的體驗已經很接近了。用Web照樣能做出精細的“換裝/美顏/捏臉”的功能,Web也能應用上一些複雜的渲染管線,做出產品級的東西,而不僅是demo一樣的玩具。通過一些橋樑中間級,在特有容器下,Web也能去利用Native的能力,二者共生,發揮各自的優勢。最後我們還要注意到,Web仍在積極蓬勃地發展,我相信未來隨著WebGPU和WebAssembly的成熟,我們在渲染這塊能比現在好的多得多。

image.png

總結

很感謝大家能聽到現在。今天聊了很多哈,總結一下今天的內容,我們聊了行業背景和典型的應用場景,介紹了我們的業務和團隊(這裡還是要強調,歡迎大家多多體驗淘寶人生,也歡迎有興趣有志向的小夥伴發簡歷給我們,聯繫我們)。另外我們分享了一些技術內幕,談到了如何實現“換裝美顏”、如何實現“捏臉”、以及與”AR互動“之間的結合。最後我們還對比了下Web下開發的優勢和劣勢。

很開心能和大家進行這次分享。


image.png

Leave a Reply

Your email address will not be published. Required fields are marked *