劉暢,霍宇馳,張嚴辭,張乾,鄭家祥,唐睿,余耿,王銳*,賈金原
1. 南昌航空大學信息工程學院,南昌 330063; 2. 同濟大學軟件學院,上海 200082;3. 浙江大學計算機科學與技術(shù)學院,杭州 310058; 4. 四川大學計算機學院,成都 610065;5. 上海渲圖科技有限公司,上海 201806; 6. 杭州群核信息技術(shù)有限公司,杭州 310012
5G時代,通過移動互聯(lián)網(wǎng)進行可視化呈現(xiàn)的在線虛擬城市、在線虛擬家居、在線虛擬旅游以及在線虛擬教學等移動互聯(lián)網(wǎng)應(yīng)用已轉(zhuǎn)化為以3維虛擬場景為主要交互對象并具有高度沉浸感的新型在線可視化應(yīng)用,并在移動設(shè)備的輔助下消除了應(yīng)用服務(wù)的距離和時間的限制。隨著移動互聯(lián)網(wǎng)技術(shù)和3維可視化技術(shù)的不斷發(fā)展,以移動在線實時繪制技術(shù)為核心的3維可視化應(yīng)用借助移動互聯(lián)網(wǎng)在各類平臺上得到廣泛的傳播。
移動在線實時繪制技術(shù)直接面向移動端設(shè)備,對移動端設(shè)備的渲染研究十分重要。近年來,工業(yè)界對移動端繪制硬件構(gòu)架的設(shè)計不斷優(yōu)化,這使得移動端硬件設(shè)備對渲染算法的加速水平不斷提升,進而導(dǎo)致了渲染效果的突飛猛進,之前遙不可及的光線跟蹤算法也逐步從電腦(personal computer, PC)端轉(zhuǎn)向了移動端。因此,本文第1節(jié)對移動端的硬件發(fā)展和渲染算法進行了重點闡述。
對于移動互聯(lián)網(wǎng)來說,移動設(shè)備并不是承載信息內(nèi)容的唯一載體。在元宇宙產(chǎn)業(yè)蓬勃發(fā)展的今天,各類虛擬現(xiàn)實、增強現(xiàn)實、混合現(xiàn)實和擴展現(xiàn)實等領(lǐng)域的可穿戴設(shè)備也借助移動互聯(lián)網(wǎng)不斷出現(xiàn)在用戶面前。因此,跨平臺、輕量化的兼容性運行平臺才是當前移動在線實時渲染技術(shù)發(fā)展的基礎(chǔ)。作為一個用戶較廣的輕量級的跨平臺瀏覽環(huán)境,Web端伴隨著Web3D技術(shù)的發(fā)展逐步成為了這樣一個平臺。所以,本文第2節(jié)對Web端的核心渲染機制、關(guān)鍵渲染技術(shù)以及主流渲染工具進行了一定的說明。
雖然移動端和Web端渲染水平逐年提升,但是相對于桌面級終端的渲染能力來說,同屬于瘦客戶端。因此,如何借助像云服務(wù)器這樣具有強大渲染能力的硬件設(shè)備輔助各類瘦客戶端的高質(zhì)量繪制成為移動在線實時繪制技術(shù)的未來。云渲染就是這樣一種輔助式繪制技術(shù),它將渲染任務(wù)分配至云服務(wù)器,然后通過視頻串流回本地客戶端,使得弱客戶端能夠獲得高質(zhì)量的渲染效果,當前主要運用于云游戲、在線擴展現(xiàn)實(extended reality, XR)應(yīng)用等領(lǐng)域。因而,本文在第3節(jié)對云端在線繪制的基礎(chǔ)構(gòu)架、服務(wù)核心以及優(yōu)化重點進行了詳細的描述。
多端協(xié)同在線繪制技術(shù)是一種新型的移動在線實時繪制系統(tǒng),它避免了云渲染系統(tǒng)中客戶端渲染能力的浪費,也彌補了純端渲染系統(tǒng)中客戶端渲染能力的不足。作為一款倍受研究者青睞的全新實時渲染技術(shù),本文在第4節(jié)對端/云協(xié)同和端/邊/云協(xié)同機制進行了深入的探討。
綜上,本文從移動端渲染、Web端在線渲染、云端在線渲染和多端協(xié)同渲染4方面入手對移動在線實時繪制技術(shù)進行深入剖析,力求為移動互聯(lián)網(wǎng)下的新型3維可視化應(yīng)用提供技術(shù)支撐。
移動端主流圖形處理器(graphics processing unit, GPU)近年得到了較快的發(fā)展(如表1所示)。2020年5月,ARM(Acorn RISC Machine)公司發(fā)布的基于第2代Valhall架構(gòu)的Mali-G78 的 GPU已有24個計算核心,支持異步時鐘域、自適應(yīng)可擴展紋理壓縮(adaptive scalable texture compression,ASTC)和ARM幀緩存壓縮(ARM frame buffer compressionm, AFBC)等新型技術(shù),降低功耗的同時,還進一步提升了芯片性能。
表1 近期移動端GPU芯片表Table 1 Table of rectent mobile GPU chips
蘋果公司于2021年發(fā)布的搭載在iPhone 13系列上的A15仿生芯片(如圖1所示),其GPU采用了全新的架構(gòu)設(shè)計,從硬件層面提供了有損壓縮、稀疏深度和模板、隨機和填充等新特性。高通公司的驍龍888芯片搭載的Adreno 660 GPU,在能效提高20%的基礎(chǔ)上,渲染圖形的速度比上一代提高了35%(如圖2所示)。
圖1 ARM架構(gòu)GPU Fig.1 GPU with ARM architecture
圖2 高通驍龍888芯片F(xiàn)ig.2 Snapdragon 888 chip
與桌面端GPU相比,移動端GPU在電源功率、芯片面積、布線以及封裝有一定的限制,因此該GPU的硬件架構(gòu)較前者區(qū)別巨大。通常桌面端的中央處理器(central processing unit, CPU)和GPU各自獨立存在,而移動端則將CPU和GPU集成在一塊SOC(system-on-a-chip)芯片上,CPU和GPU共享內(nèi)存以及帶寬等。因此,桌面端和移動端的GPU在構(gòu)架設(shè)計上有很大的不同。
相對于桌面端GPU采用圍繞大量專用帶寬而設(shè)計的即時模式渲染器(immediate mode renderers, IMR)架構(gòu)而言,移動端GPU采用的是基于塊的渲染(tile-based rendering, TBR)架構(gòu)。與IMR相比,大量顏色和深度緩沖的來回讀寫,被隔離在片內(nèi)的高速緩存中,每一塊的幀緩沖在最終渲染完成后才會被寫回主存,在最小化帶寬消耗的同時,還控制了芯片的功耗和發(fā)熱。
為了進一步提高渲染效率,移動端GPU采用了諸多新穎的設(shè)計。例如,為了不將計算資源浪費在對最終渲染畫面沒有貢獻的片元上,移動端GPU會進一步延遲片元著色,以便在像素級別上實現(xiàn)Over-Draw的消除。每一塊的圖元光柵化成片元后,會等待所有片元全部經(jīng)過深度測試后才進行片元著色,以確保只有離視點最近的片元才會被著色。
同時,近年來許多研究者對移動端GPU發(fā)展進行了研究(Surana 等,2020;Ain等2018;Singh和Jain,2014),并嘗試對原有的移動端渲染硬件進行改進,探索更優(yōu)的架構(gòu)設(shè)計(Lee 等,2012;Gubran和Aamodt,2019)。
由于設(shè)備功耗級別不同,移動端GPU的渲染能力通常不如桌面端GPU,進而導(dǎo)致移動端渲染效果較后者略低。許多研究者從渲染算法和渲染優(yōu)化出發(fā)來提升移動端GPU的渲染效果,以彌補其硬件渲染能力的先天不足(如表2所示)。
表2 移動端渲染算法表Table 2 Table of rendering algorithms on mobile
1.2.1 移動端的光線跟蹤算法
從2018年NVIDIA推出GPU的實時光線跟蹤(ray tracing texel extreme,RTX)技術(shù)后,桌面端的實時渲染畫質(zhì)得到了極大提高。相應(yīng)地,移動端也在積極嘗試引入實時光線跟蹤技術(shù)。
在算法方面,Viitanen等人(2017)提出了一種輕量化的MergeTree結(jié)構(gòu)以加速HLBVH(hierarchical linear bounding volume hierarchy)樹,可用于在移動端上實時計算光線跟蹤。為面向多場景進行優(yōu)化,Lee等人(2016)提出了一種自適應(yīng)的多速率射線采樣算法。為了適應(yīng)移動端低帶寬的特性,Hwang等人(2015)提出了一種混合fix和float格式的優(yōu)化方法,用于減少移動端光追的帶寬。Lee等人(2015)提出了一種帶寬和能源效率高的混合光線跟蹤和光柵化架構(gòu)。為了高效利用移動端的高速緩存,Shin等人(2015)提出了一種有效的光線調(diào)度算法和非塊緩存架構(gòu)來隱藏主內(nèi)存訪問延遲,以實現(xiàn)移動設(shè)備上的實時光線跟蹤。
在硬件以及軟件開發(fā)工具包(software development kit, SDK)方面,移動設(shè)備芯片廠商Imagination公司(IMG)將光線跟蹤分為6個級別,并早在2015年就展示了實時光線跟蹤的PowerVR GR6500 GPU。華為在其2021年的開發(fā)者大會上,推出了其光線跟蹤模塊“鳳凰引擎”,通過多層BVH加速結(jié)構(gòu)以及多叉樹遍歷算法,構(gòu)筑了高效、無偏光線跟蹤算法底座,并基于華為硬件平臺的自研混合渲染管線,實現(xiàn)了實時光線跟蹤技術(shù)在線移動應(yīng)用。2021年10月,三星發(fā)布了基于AMD(advanced micro devices)的RNDA2架構(gòu)的Exynos 2200 GPU,目前能夠支持桌面和移動電腦的光線跟蹤。這項技術(shù)預(yù)計將會引入三星的新一代智能手機,創(chuàng)造出更真實的光照效果。
1.2.2 移動端渲染優(yōu)化
相比于桌面端,移動端的渲染硬件存在特殊的性能瓶頸。Martin等人(2013)對其瓶頸的主要來源進行了分析,并給出了移動端渲染硬件需要解決的核心問題:散熱。為了移動設(shè)備的輕薄性,往往需要將大量硬件集成到輕薄移動設(shè)備專用的主板上,高密度的硬件導(dǎo)致散熱成為了難題。其次,控制設(shè)備產(chǎn)生的熱量,以及提高移動設(shè)備的續(xù)航,這使得渲染硬件的功率也受到了極大的限制。
為了解決這些問題,開發(fā)者往往需要去估計一個渲染管線的功耗,或者在給定的電量預(yù)算下去尋找一個合適的渲染管線配置。針對功耗估計的問題,Sun等人(2014)和Yun等人(2018)給出了通過估計紋理采樣數(shù)、浮點運算吞吐量等方式來估計功耗。而Wang 等人(2016)提出了一種在給定渲染預(yù)算下和最低能量消耗的前提下,獲取最優(yōu)圖形質(zhì)量的方法。
為了緩解移動平臺帶寬瓶頸帶來的影響,許多研究者提出了一系列如何高效利用帶寬的方法。Martin等人(2015)提出了在移動端優(yōu)化高性能的物理渲染(physically based rendering, PBR)方案,該方案使用ARM架構(gòu)特性進行高效的幀緩存讀取,并通過每個像素獨立的局部存儲單元高效利用帶寬。Olsson等人(2015)針對高度占用帶寬的光源渲染算法進行研究,提出了利用移動端特有的架構(gòu)“TBR”來做大量光源渲染的針對性的解決方案。
由于移動端的便攜性,可以很輕松地與虛擬現(xiàn)實(virtual reality, VR)眼鏡結(jié)合,為用戶提供沉浸式的VR體驗。近年來,如何給出更優(yōu)質(zhì)的移動VR體驗受到廣大研究者的關(guān)注。Lee等人(2017)提出了一種全新函數(shù)用于加速在移動端VR中的桶形失真校正計算。Nah等人(2016)提出了一種基于tile的移動架構(gòu)的遍歷順序“Z2遍歷順序”,可以最大化空間局部性的tile遍歷以便在VR應(yīng)用中提高GPU緩存效率。
1.3.1 移動端圖形API
在圖形應(yīng)用程序編程接口(application programming interface,API)方面,OpenGL ES作為目前應(yīng)用最廣的跨平臺圖形API,支持Android、iOS等多個平臺,但OpenGL ES在2015年8月更新至版本3.2后至今沒有發(fā)布新的版本。作為OpenGL的替代者Vulkan將其目標聚集于“高效”和“跨平臺”,旨在提供更高的性能和更均衡的CPU/GPU負載。得益于其多線程渲染管線和多線程指令流的實現(xiàn),Vulkan在移動端有著優(yōu)秀的性能表現(xiàn)。目前,Vulkan在Windows、Linux、Android等各大平臺都有相關(guān)應(yīng)用實現(xiàn);以Unity和Unreal為代表的主流商業(yè)游戲引擎也逐步加強對它的支持。Metal是蘋果公司發(fā)布的兼顧圖形和通用計算的API,它是蘋果公司專門為蘋果產(chǎn)品定制,因此在蘋果產(chǎn)品上有優(yōu)異的表現(xiàn)。
1.3.2 游戲引擎中的移動端渲染
虛幻引擎4(UE4)的移動端渲染器獨立于桌面端,擁有專門針對移動端優(yōu)化的功能。然而,UE4目前沒有為移動端提供特定優(yōu)化的渲染管線,對于較為復(fù)雜的圖形功能沒有提供較好的支持。在材質(zhì)方面,UE4移動端還停留在傳統(tǒng)低復(fù)雜度的材質(zhì)參數(shù)設(shè)置和材質(zhì)著色計算上,不支持曲面細分、次表面散射等圖形技術(shù),也不能較好地模擬毛發(fā)、布料和眼睛等高復(fù)雜度物體的光照著色。陰影、霧等高質(zhì)量渲染效果,也只提供如級聯(lián)陰影映射(cascaded shadow maps,CSM) (Dimitrov, 2007)和大氣霧等工業(yè)界傳統(tǒng)的解決方案。在2021年5月份,Epic官方發(fā)布了UE5預(yù)覽版,在預(yù)覽版中官方也未添加移動端模塊。
相對于UE4對移動端支持不足,Unity對移動端則更加友好。Unity在2018.1 beta版本中就開始引入了可編程渲染管線(scriptable render pipeline, SRP)的概念。通過編寫腳本,用戶可以在渲染管線層面控制場景的剔除、渲染方式和后期處理。在2021年初,Unity為SRP添加了Enlighten實時全局光照系統(tǒng),增加了間接光照計算部分,大大提升了畫面表現(xiàn)力。之后,Unity又在2019.1版本中引入通用渲染管線(universal render pipeline, URP)的概念。通過調(diào)整光照計算和陰影計算的方式,將所有的光照都放到一次渲染管線流程中,降低光照計算和陰影計算的能耗負擔,為移動端提供更好的性能優(yōu)化。近年來,Unity更是與ARM深度合作,讓其用戶內(nèi)容在各類移動設(shè)備上的能耗和帶寬需求降至更低。
在移動互聯(lián)網(wǎng)時代,Web端是一個用戶較廣的輕量級的跨平臺瀏覽環(huán)境。借助Web端進行3維呈現(xiàn)的在線虛擬城市、在線虛擬家居、在線虛擬旅游以及在線虛擬教學等Web3D應(yīng)用打破了傳統(tǒng)Web應(yīng)用以文字、聲音、圖像、視頻以及2維動畫為主要傳播媒體的慣例,進而轉(zhuǎn)為以3維虛擬場景為主要交互對象并具有高度沉浸感的新型Web應(yīng)用。隨著各類Web3D應(yīng)用的興起并在多方面逐步影響人們的生活,用戶對這些應(yīng)用的體驗需求也水漲船高。本節(jié)從Web3D渲染機制、Web端渲染的關(guān)鍵技術(shù)和Web端渲染工具3個方面出發(fā),深度闡述了Web端在線實時繪制的相關(guān)研究。
隨著軟硬件平臺的更新?lián)Q代,一套免插件、高性能Web3D渲染機制不但是Web瀏覽器廠商的期許,更是廣大Web3D應(yīng)用開發(fā)者的期盼。21世紀初,JavaScript作為Web瀏覽器中默認的腳本語言,以其良好的兼容性和強大的可擴展性深受廣大Web3D編程者的青睞。隨著JavaScript虛擬機的巨大性能提升使得在同一個畫框內(nèi)3D空間中數(shù)以千計的頂點得以快速且準確的控制(Evans等,2014),研發(fā)者對于在Web端實現(xiàn)免插件的高性能3D渲染技術(shù)充滿希望,而通過Web瀏覽器借助JavaScript直接訪問GPU的方法標準化需求已非常清晰。
在上述背景下,Khronos組與主要的瀏覽器供應(yīng)商Apple(Safari)、Google(Chrome)、Microsoft(Edge)和Mozilla(Firefox)合作,聯(lián)合推出了一款Web端專屬圖形API的首個版本“WebGL 1.0”。WebGL 1.0的內(nèi)核來自于著名的移動端圖形API“OpenGL ES 2.0”,并以JavaScript作為開發(fā)語言,可以用于在大部分主流的Web瀏覽器中展示2維(two-dimensional, 2D)或3D圖形。該圖形API不僅可以使GPU加速圖形處理,而且允許其內(nèi)部函數(shù)借助JavaScript嵌入Web端的超文本標記語言(HTML)中,實現(xiàn)3D應(yīng)用與Web端免插件無縫對接。2017年,Khronos組推出了WebGL升級版本“WebGL 2.0”,開始支持包括二次冪紋理、雙精度浮點和3維紋理等在內(nèi)的高級圖形渲染功能(Frigo等,2018),并受到Firefox,Chrome和Opera等主流瀏覽器的廣泛支持。一直沿用至今的WebGL已被廣大的Web3D應(yīng)用開發(fā)者所接受,它的運行機制被認為是目前Web3D應(yīng)用的主流渲染機制,并為時下種類繁多的Web端渲染工具提供了有力的技術(shù)支撐。
2.2.1 Web3D引擎
隨著Web3D技術(shù)的發(fā)展,國內(nèi)外出現(xiàn)了多款優(yōu)秀的Web3D引擎(如表3所示),其中國外以Three.js、Babylon.js和PlayCanvas較為突出。
表3 Web3D引擎Table 3 Web3D engine
Three.js由Ricardo Cabello在2010年首次發(fā)布,是基于JavaScript和WebGL搭建的3D圖形渲染庫,可以進行高效、免插件的網(wǎng)頁端3D應(yīng)用的研發(fā)。不少WebVR渲染系統(tǒng)采用了Three.js引擎,如Marion和Jomier(2012)提出的網(wǎng)頁可視化系統(tǒng);Jacinto等人(2012)的實時醫(yī)療圖像的可視化分割系統(tǒng),以及上述Web3D協(xié)同式光照渲染系統(tǒng)Cloud Baking(Liu等,2017,2018a)。
Babylon.js是Microsoft公司于2013年發(fā)布的Web3D游戲引擎,底層完全基于WebGL圖形API。整套引擎通過JavaScript語言進行編寫,同時還支持TypeScript語言,并把工作重心放在Web3D游戲開發(fā)上。
PlayCanvas是Will Eastcott等人開發(fā)的一個開源Web3D引擎,包括3D 游戲引擎、交互式3D應(yīng)用程序引擎以及專有的云托管創(chuàng)建平臺,允許通過基于瀏覽器的界面從多臺計算機同時編輯,2017年被Snap Inc公司收購。與Three.js引擎相比,PlayCanvas開發(fā)資源更為豐富、開發(fā)效率更為突出且具有專業(yè)的云托管平臺(如圖3所示)。
圖3 可編輯PBR材質(zhì)(PlayCanvas)Fig.3 Editable PBR material(PlayCanvas)
國內(nèi)的Web3D引擎以O(shè)asis、Egret、LayaAir和Cocos3D最具代表性。這些引擎以WebGL或WebGPU為底層圖形API,結(jié)合各類腳本語言進行3D圖形渲染庫的搭建,形成具有各自特點的Web3D開發(fā)工具。
Oasis Engine是由螞蟻集團開發(fā)的Web3D 互動圖形引擎。以WebGL為底層圖形API,結(jié)合TypeScript語言進行開發(fā)。主要針對移動端,并且支持前端開發(fā)。
白鷺科技在2014年2月創(chuàng)立了白鷺引擎(Egret Engine),引擎使用TypeScript進行編寫,其底層API仍是WebGL。在渲染方面,Egret使用了Canvas渲染技術(shù),保證了其作品在瀏覽器上的兼容性。并且額外提供了CPU渲染模式和WebGL渲染模式,支持 WebAssembly技術(shù),其效果圖如圖4所示。
圖4 體積光照(Egret Engine)Fig.4 Volumetric lighting(Egret Engine)
LayaAir是Layabox于2016年發(fā)布的一款基于WebGL的開源引擎,支持ActionScript3、JavaScript、TypeScript這3種開發(fā)語言。該引擎同時支持WebGL與Canvas渲染,且優(yōu)先使用WebGL渲染,在優(yōu)秀瀏覽器環(huán)境下運行性能媲美Unity3D等桌面級游戲引擎。
Cocos3D 由雅基軟件公司于2016年開發(fā),以O(shè)penGL為底層API,其核心采用 C++編寫,支持使用C++、Lua 或 JavaScript 進行開發(fā)?;?OpenGL ES 2.0 和 Metal 進行圖形渲染。Cocos Creator 3D將數(shù)據(jù)驅(qū)動和組件化作為其游戲開發(fā)的核心方式。
2.2.2 游戲引擎的Web3D渲染
Unity3D是一個跨平臺的游戲引擎,具有先進的3D圖形功能。與上述3D渲染引擎相比,Unity3D體現(xiàn)出渲染能力強、可擴展性高、程序開發(fā)復(fù)雜度低及跨平臺性靈活等特點,它非常適合于打造多平臺下高質(zhì)量的實時視頻游戲。在Unity3D中創(chuàng)建出的所有3D應(yīng)用,可以導(dǎo)出相應(yīng)的Web格式,并通過Unity Web Player插件在主流的瀏覽器中進行演示。因此本節(jié)仍然把其列為Web3D引擎的一員,盡管這只是它的小部分功能。Unity3D支持的主要開發(fā)語言有JavaScript和C#,其場景編輯器支持3D場景編輯的同時還可以將相應(yīng)的腳本語言代碼直接嵌入編輯對象中(Xie,2012)。
UE5是Epic于2020年公布的第5代游戲引擎,具備照片級逼真的渲染功能、動態(tài)物理與效果、栩栩如生的動畫、健壯的數(shù)據(jù)轉(zhuǎn)換接口等。在第4代引擎UE4的基礎(chǔ)上新增了高級別幾何信息的虛擬微多邊形幾何系統(tǒng)“Nanite”,并很好地優(yōu)化了場景中全局動態(tài)的光照變化的實時性。從UE4開始,該引擎對Web端采用容器的技術(shù),此技術(shù)是一種支持大規(guī)模云應(yīng)用部署的技術(shù),具有輕量、可移植的特點,為Web3D應(yīng)用提供了一致的運行環(huán)境。
2.2.3 Web3D繪制工具的渲染表現(xiàn)
Web3D在線渲染效果取決于承載Web3D應(yīng)用的硬件性能和支撐Web3D圖形API。如2.1節(jié)所述,當前的主流Web3D應(yīng)用的圖形API是WebGL 2.0,該API派生自移動端圖形API——OpenGL ES 3.0并承載其大部分的渲染表現(xiàn)。
雖然Web3D在線渲染無法實現(xiàn)光線跟蹤這類高耗能的實時全局光照渲染算法,但其渲染能力和繪制質(zhì)量仍不可小覷。其中,高性能的物理渲染(physically based rendering, PBR)是提升渲染質(zhì)量(Robart等,1999)的有效手段,尤其在制作全局光照渲染效果時,表現(xiàn)顯著。
國外的Web3D引擎Babylon.js和PlayCanvas就把PBR材質(zhì)的可視化編輯作為其重要渲染任務(wù)之一。國內(nèi)的Web3D引擎Oasis在其PBR工作流中設(shè)置環(huán)境光的漫反射和鏡面反射來達到基于圖像的照明效果(image based lighting,IBL)(Debevec,2006)。
另外,以軟陰影效果為主的高質(zhì)量光照遮擋技術(shù)也是體現(xiàn)Web3D渲染質(zhì)量的一大看點,Babylon.js就在其最新的4.2版本中支持基于環(huán)境光照遮擋的透明物體軟陰影渲染(如圖5所示),而PlayCanvas則支持多種軟陰影算法,并能在引擎運行時生成面向數(shù)十個靜態(tài)燈光的光照貼圖。
圖5 透明物體軟陰影(Babylon.js)Fig.5 Soft shadows of transparent objects(Babylon.js)
除材質(zhì)和光影特效之外,GPU動畫加速、GPU粒子系統(tǒng)加速、伽瑪矯正、紋理混合和線性圖形管道渲染等技術(shù)都在基于WebGL2.0的新一代Web3D應(yīng)用或Web3D引擎中得以體現(xiàn)。
目前,隨著Web3D應(yīng)用逐步被人們接受,Web3D數(shù)據(jù)內(nèi)容(尤其是Web3D場景內(nèi)容)復(fù)雜度和規(guī)模與日俱增,典型的應(yīng)用包括:在線虛擬校園、在線虛擬博物館和在線虛擬城市等。雖然網(wǎng)絡(luò)帶寬與網(wǎng)速也在不斷提升,但遠遠跟不上Web3D數(shù)據(jù)的擴張速度。因此,在線大規(guī)模Web3D場景即時加載成為Web3D應(yīng)用的瓶頸問題,受到廣大研究者的關(guān)注。當前解決這一問題的關(guān)鍵技術(shù)分為兩類:1)Web3D場景的輕量化技術(shù);2)漸進式對等傳輸技術(shù)。
2.3.1 Web3D場景的輕量化技術(shù)
雖然計算機圖形學方法中早對3D場景的輕量化處理有所涉及,如:細節(jié)層次技術(shù)(level of detail, LOD)(李公立和黃毓瑜,2004)、漸進式網(wǎng)格技術(shù)(progressive meshes, PM) (Hoppe,1996;Ma等,2016)等。但這些技術(shù)并不完全適用于在線Web3D應(yīng)用中的虛擬場景。離散型LOD模型只能使得網(wǎng)絡(luò)負載更加沉重;漸進式網(wǎng)格會引起網(wǎng)頁端在線解析時間過長且不適用于所有模型。因此,如何同時使得場景的數(shù)據(jù)量更小、網(wǎng)絡(luò)傳輸速度更快以及到達網(wǎng)頁端的后處理(在線解析和渲染)時間更少才是Web3D場景輕量化的最終目標(涉及技術(shù)如表4所示)。
表4 3維模型輕量化處理技術(shù)表Table 4 Table of 3D model lightweight technology
近來研究者為靠近上述目標提出了新的輕量化方法:基于單元重用的模型輕量化方法(Shikhare 等,2001;Cai 等,2009)、基于幾何最小化的3D數(shù)據(jù)壓縮算法及基于并行快速匹配搜索的解壓縮算法(Siddeq和Rodrigues,2016)、基于貝葉斯學習算法及傅里葉變換的壓縮/重建方案(Lalos等,2017)就是其中的代表。這些方法使得Web3D場景在幾乎無損輕量化的同時未增加網(wǎng)絡(luò)負載,且對模型的通用性更佳。
另外,更有學者將新型方法與傳統(tǒng)方法結(jié)合,提出了輕量化漸進式紋理(Englert等,2015)、輕量化漸進式網(wǎng)格(Wen等,2016)和建筑模型輕量化語義表達(Liu等,2016)等混合改進型輕量化方法,為Web3D場景的輕量化處理再添新的思路(如圖6所示)。
圖6 在線大型BIM場景Web3D繪制(Liu等,2016)Fig.6 Online Web3D rendering of large-scale BIM scenes(Liu et al., 2016)
2.3.2 漸進式對等網(wǎng)絡(luò)傳輸
針對大規(guī)模Web3D場景的網(wǎng)絡(luò)傳輸,傳統(tǒng)的解決方法仍然集中在漸進式傳輸機制上。該機制源于計算機圖形學的漸進式加載技術(shù),通過分步增量式的加載大規(guī)模Web3D場景模型來解決模型數(shù)據(jù)傳輸?shù)木W(wǎng)絡(luò)負載過重問題。為了提升增量式加載的準確性,雙層扇形興趣域(double-layer sector of interests, DAOI)(Wen 等,2016)、擴展多層興趣區(qū)(scalable multi-layer sector AOI, SMLAOI)(賈金原 等,2014;Jia等,2016)和路徑興趣域(path of interests,POI)(Wang等,2015a)等加載增量預(yù)測算法相繼被提出。
研究者們把漸進式傳輸機制常與對等傳輸網(wǎng)絡(luò)(peer-to-peer networking,P2P)環(huán)境有機結(jié)合,提出了兼具增量式傳輸和對等傳輸雙重優(yōu)勢的漸進式對等網(wǎng)絡(luò)傳輸機制(Yahyavi和Kemme,2013;Buyukkaya 等,2015)。在此基礎(chǔ)上,王偉等人(2010)提出了面向?qū)Φ染W(wǎng)絡(luò)的新型漸進式場景更新策略;Hu等人(2008,2010)自主研發(fā)了仿真對等傳輸平臺“FLoD”;Jia等人(2014)在FLoD基礎(chǔ)上進一步提出了可擴展多層興趣區(qū)域的數(shù)據(jù)加載框架,并把FLoD升級為更智能的仿真對等傳輸平臺“iFLoD”;Jia等人(2014)提出了基于路徑興趣域數(shù)據(jù)加載框架,將iFLoD升級為興趣域相關(guān)的仿真對等傳輸平臺“interest-iFLoD”。
上述研究大多是針對P2P 網(wǎng)絡(luò)架構(gòu)場景流式傳輸方法研究(如表5所示),很少關(guān)注用戶本身和場景數(shù)據(jù),隨著場景規(guī)模擴大和用戶訪問量增大,多用戶協(xié)同訪問及資源搜索、節(jié)點定位等處理變得復(fù)雜,這使得基于P2P的Web3D應(yīng)用中的場景數(shù)據(jù)傳輸和交互實時性面臨嚴峻考驗。因此,為Web3D場景的對等傳輸提供構(gòu)建合理、布署方便以及訪問高效的技術(shù)框架是研究者們亟待解決的下一個研究熱點。
表5 漸進式傳輸與對等傳輸相關(guān)技術(shù)Table 5 Technologies of progressive transmission and peer-to-peer transmission
云端在線渲染的本質(zhì)是遠程渲染,其出發(fā)點是希望把繁重的渲染任務(wù)迀移至遠程服務(wù)器而使得瘦客戶端也能進行高質(zhì)量渲染效果展示(Maclntyre和Smith,2018)。在云計算的協(xié)助下,遠程渲染系統(tǒng)中的渲染任務(wù)被遷移至云服務(wù)器中,并逐步形成云端在線繪制技術(shù)(Hou等,2017)。近年來,隨著5G通信和互聯(lián)網(wǎng)技術(shù)的發(fā)展,以追求高質(zhì)量渲染和快交互響應(yīng)為目標的移動云游戲(Hou 等,2021)成為云渲染技術(shù)的主要應(yīng)用領(lǐng)域(Liu 等,2018a)。從云端在線繪制的目標入手,重點討論云端在線繪制系統(tǒng)的構(gòu)架與服務(wù)、優(yōu)化以及核心應(yīng)用“云游戲”。
在實際應(yīng)用中,把所有繪制任務(wù)完全放在客戶端,會受到客戶端的能耗、算力和兼容性等諸多因素的影響。因此,工業(yè)界通常借助遠程云服務(wù)器進行高質(zhì)量的圖形繪制,再將繪制結(jié)果傳輸?shù)娇蛻舳嗽O(shè)備上進行圖形顯示,使得輕量級的客戶端也能支持高質(zhì)量的繪制應(yīng)用。而這個過程就是云繪制過程,完成此過程的系統(tǒng)稱為“云繪制系統(tǒng)”,其框架如圖7所示。
圖7 云繪制架構(gòu)Fig.7 Cloud rendering architecture
該框架以端云分離繪制技術(shù)為基礎(chǔ),云側(cè)的繪制和端側(cè)的繪制是分開進行的。它的端側(cè)只負責渲染任務(wù)的申請和渲染結(jié)果的顯示,完全不承擔渲染任務(wù);而服務(wù)器端負責所有渲染任務(wù),其渲染結(jié)果會通過移動互聯(lián)網(wǎng)流式化傳往移動前端。
作為一種云計算服務(wù),云繪制可以分為3層:基礎(chǔ)架構(gòu)即服務(wù)(infrastructure as a service,Laas)層、平臺即服務(wù)(platform as a service,PaaS)層、軟件即服務(wù)(software as a service,SaaS)層,分別用于滿足云繪制應(yīng)用在底層硬件、中間平臺和高層軟件的不同層次需求。其中,PaaS層作為云繪制服務(wù)的核心層,主要提供3大功能:1)完成3D可視化應(yīng)用(包含VR應(yīng)用)的自動化托管;2)優(yōu)化用戶的計算資源和網(wǎng)絡(luò)資源的調(diào)度;3)實現(xiàn)多媒體數(shù)據(jù)的多終端穩(wěn)定流式化傳輸。在這3大功能中,流式化傳輸功能是PaaS層的關(guān)鍵功能,可細分為多終端的操作信息獲取和傳送、繪制畫面抓取編碼和超低延遲傳輸以及端側(cè)的解碼和顯示,是云繪制服務(wù)的優(yōu)化重點。
如3.1節(jié)所述,云繪制的優(yōu)化重點集中在串流技術(shù)的優(yōu)化上。串流技術(shù)就是對影音等多媒體數(shù)據(jù)(尤其是視頻數(shù)據(jù))進行流式化傳輸?shù)募夹g(shù)總稱。雖然串流技術(shù)在視頻應(yīng)用中優(yōu)勢明顯,但依托此類技術(shù)的視頻傳輸依然存在數(shù)毫秒到上百毫秒的延遲(Choy等,2012;Tolia等,2006)。由于緩存技術(shù)的支持,此類延遲在視頻點播應(yīng)用中可被忽略,然而對強調(diào)互動性的視頻游戲或增強現(xiàn)實(augmented reality, AR)/VR/XR等應(yīng)用的用戶體驗質(zhì)量卻影響巨大(Chen和El-Zarki,2019;Slivar 等,2014)。然而,視頻的壓縮率與帶寬次線性相關(guān)的同時,吞吐量需求卻依然不斷地隨著分辨率和幀率的提高而提高,并且圖像質(zhì)量也會因為有損的壓縮方式而無法最優(yōu)化(Sullivan 等,2012)。
另外,在云繪制過程中,移動端從提出渲染請求到接收渲染結(jié)果并顯示,需要至少一次往返時間,而這些時間是云繪制過程中無法避免的交互延遲時間。交互延遲會導(dǎo)致用戶自然以為云繪制應(yīng)用的交互響應(yīng)過長,實時性不夠,從而在體驗(尤其是視覺體驗)過程中產(chǎn)生頓挫感。減少交互延遲的影響,提升視覺體驗是云繪制優(yōu)化的另一個重點。McMillan(1997)提出的3D warping是一種將參考圖像上的像素映射到任意視點的技術(shù)。它廣泛用于3D視頻處理(Smolic 等,2008)和基于圖像的實時渲染中(Fehn,2004;Mori等,2009)。Shi等人(2012)以及Zhu等人(2011)應(yīng)用3D warping在他們的遠程渲染系統(tǒng)中把接收到的渲染圖像中的像素全部扭曲到交互延遲后的視點下,從而在視覺上減少了“交互延時”帶來的影響。然而,當輸入圖像中的信息不足以生成新視點時,3D warping會產(chǎn)生孔偽影失真。面對這一問題,很多解決方案相繼提出,包括分層深度圖像(layered depth images, LDI)(Shade等,1998),splat warp (Mark等,1997),super-visual distortions(Bao和 Gourlay,2004)等。
作為云端在線繪制系統(tǒng)的核心應(yīng)用,云游戲已經(jīng)成為一種新的計算機游戲范例,它通過在云服務(wù)器上運行視頻游戲并將渲染的幀流式傳輸給用戶,不受時間、空間和設(shè)備性能的限制(Laghari等,2019)。為了達到用戶的體驗質(zhì)量要求,云游戲提供商必須面對3個主要挑戰(zhàn):減少交互延遲、降低云基礎(chǔ)架構(gòu)成本以及降低網(wǎng)絡(luò)帶寬需求。
為此,研究者們提出多種優(yōu)秀的邊緣/云渲染構(gòu)架或系統(tǒng)(如表6所示):Bhojan等人(2020)提出了CloudyGame構(gòu)架,該構(gòu)架要求在不同的游戲?qū)嵗g更有效地共享和管理資源,并促使游戲資源流式化任務(wù)傳往前端以降低初始化成本。Zhang等人(2019b)提出了EdgeGame框架,該構(gòu)架除將計算密集型渲染工作卸載到了網(wǎng)絡(luò)邊緣外,還在邊緣引入了深度強化學習,使其自動地調(diào)整視頻比特率以適應(yīng)網(wǎng)絡(luò)動態(tài)變化。Chen等人(2019)提出的T-Gaming游戲框架采用了優(yōu)先視頻編碼和自適應(yīng)實時流媒體技術(shù),可以有效提高用戶的體驗質(zhì)量。Cai等人(2018)基于組件的認知能力設(shè)計出UBCGaming系統(tǒng),能夠有效平衡系統(tǒng)性能和交互延遲,可以給用戶提供更好的游戲體驗。Pitk?nen等人(2019)設(shè)計了一個面向移動設(shè)備的VR云游戲系統(tǒng),在這種端到端的方案中,VR游戲的執(zhí)行從低功耗的移動設(shè)備端被卸載到邊緣/云服務(wù)器,在邊緣/云服務(wù)器上根據(jù)控制器的方向和通過網(wǎng)絡(luò)傳輸?shù)膭幼鱽沓尸F(xiàn)已執(zhí)行的游戲。
表6 云游戲構(gòu)架表Table 6 Table of cloud game architecture
多端渲染系統(tǒng)不同于遠程渲染系統(tǒng)僅將渲染任務(wù)放于遠程服務(wù)器,而是將渲染任務(wù)分攤放于“端服”協(xié)同執(zhí)行(Chen和El-Zarki,2019)。隨著云計算和邊緣計算的先后提出,該系統(tǒng)也從“端云”協(xié)同逐步轉(zhuǎn)向“端邊云”協(xié)同。
“端云”渲染系統(tǒng)的協(xié)同機制體現(xiàn)在渲染任務(wù)的分攤上。該機制充分發(fā)揮前端的渲染能力,同時降低后端的渲染負載,使系統(tǒng)達到一定程度的負載均衡。此類渲染系統(tǒng)通常借助渲染方程的拆解,目前已有不少出色的研究成果,通過云端輸出圖像的視點相關(guān)性,可分為:1)視點相關(guān)端云渲染系統(tǒng)協(xié)同。該機制要求前后端渲染結(jié)果的視點一致。此類系統(tǒng)如:Crassin等人(2015)提出的協(xié)同式光照渲染系統(tǒng)“Cloud Light”,該系統(tǒng)首次涉及光照渲染任務(wù)的“端云”分攤問題;Liu等人(2018a)提出的面向Web3D的協(xié)同式光影渲染系統(tǒng)“Cloud Baking”,把簡單的直接光照渲染任務(wù)放于Web前端,而把復(fù)雜的全局光照渲染任務(wù)放于云后端,最終的渲染結(jié)果將在Web前端合成并輸出, 為了優(yōu)化該系統(tǒng),該團隊構(gòu)建了基于光圖樹的預(yù)渲染機制(劉暢 等,2019),并提出了基于設(shè)備性能的Web3D動態(tài)實時光影云渲染系統(tǒng)(劉暢 等,2021),進一步細分了“端/云”兩側(cè)各自的渲染任務(wù)。視點相關(guān)多端協(xié)同渲染系統(tǒng)對交互延遲十分敏感,一旦延遲發(fā)生必然使得前后端視點不一致,進而導(dǎo)致依靠兩端結(jié)果融合的輸出結(jié)果失真。對于延遲造成的輸出結(jié)果失真,此類系統(tǒng)通常依靠視點矯正技術(shù)(Jiang和Gu,2015)予以解決。2)視點無關(guān)端云渲染系統(tǒng)協(xié)同,該機制不再要求前后端渲染結(jié)果的視點一致。此類系統(tǒng)如: Bugeja等人(2019)和邵威等人(2020)提出的協(xié)同式光照渲染系統(tǒng),普遍延續(xù)了光照渲染分攤模式,只是云端對全局光照的處理方法有所不同,前者采用基于場景體素化的環(huán)境光遮擋算法,而后者采用的是基于稀疏體素化的Lightmap算法。當然,這兩種算法都是視點無關(guān)的。此類系統(tǒng)對交互延遲有一定容忍度,但云端必不可少地會存儲更多的光照信息圖像。因此,對于這兩種系統(tǒng)的選擇應(yīng)該充分平衡系統(tǒng)的交互性和存儲消耗。除此之外,近年來研究者們還探索了實時渲染過程中著色計算與光柵化計算的“端云”協(xié)同分攤機制,Mueller等人(2018)提出的著色圖集流式傳輸(shading atlas streaming, SAS)協(xié)同渲染系統(tǒng)把絕大部分著色任務(wù)分攤到云端,并將可見區(qū)域渲染圖像匯聚成一個著色圖集,而前端只需對可見模型進行光柵化處理并對云端圖集進行紋理采樣即可;Hladky等人(2019)在此基礎(chǔ)上引入了細分曲面著色器,使得云端著色任務(wù)可以進行多線程硬件加速,提升了系統(tǒng)效率??傮w而言,此類分攤機制的空間占用率高,對云端算力的需求較大,但對弱前端的支持力度明顯。如表7所示。
表7 多端協(xié)同的渲染系統(tǒng)Table 7 Table of multi-terminals collaborative rendering system
隨著邊緣計算融入“端云”協(xié)同渲染系統(tǒng)中,該系統(tǒng)的渲染方式將發(fā)生極大的改變。由于邊緣服務(wù)器距離前端比云服務(wù)器距離前端更近,因此將計算密集型的渲染任務(wù)從前端卸載到邊緣端,可以減少網(wǎng)絡(luò)延遲和帶寬的消耗(Zhang等,2019a)。對于邊緣承載的任務(wù),Chatzopoulos等人(2017)根據(jù)邊緣端的設(shè)備特點給出了兩套方案:1)負責計算和渲染任務(wù);2)只負責計算任務(wù),渲染任務(wù)留在本地。在此基礎(chǔ)上,Zhang等人(2019a)通過測試編碼和渲染任務(wù)在不同邊緣設(shè)備上分離的表現(xiàn)來判定邊緣設(shè)備提高渲染服務(wù)質(zhì)量的標準。Trinelli等人(2019)提出NEAR框架以支持網(wǎng)絡(luò)功能虛擬化對混合現(xiàn)實(mixed reality, MR)設(shè)備的邊緣計算加速。另外,Chen等人(2017)使用Gabriel平臺實現(xiàn)了7種不同可穿戴設(shè)備的認知輔助,并測試了AR應(yīng)用程序在不同設(shè)置和使用不同硬件中的延遲。Bachhuber等人(2019)提出了一個將AR渲染任務(wù)卸載到邊緣的研究。他們特別關(guān)注通過優(yōu)化編碼和解碼步驟來降低端到端的延遲,最終實現(xiàn)了83.5 ms的端對端延遲??傮w看來,“端邊云”渲染系統(tǒng)的任務(wù)協(xié)同機制目前沒有較為統(tǒng)一的標準,視目標的不同“端邊云”協(xié)同的機制也不同。
綜上,“端邊云”渲染系統(tǒng)的協(xié)同機制比“端云”渲染機制更為靈活,但不可控因素更大,容易對邊/云算力造成極大的影響。
多端協(xié)同渲染調(diào)度問題需要優(yōu)化服務(wù)的操作成本和用戶的端到端性能,涉及多個互相沖突的系統(tǒng)目標(如:并發(fā)用戶數(shù)、用戶交互延遲、渲染幀率、運行速度以及用戶瀏覽系統(tǒng)的平均響應(yīng)等因素),這些目標形成離散的、非凸的高次多項式函數(shù),具有一定的耦合性。
Wang等人(2019b)對多端渲染系統(tǒng)的核心業(yè)務(wù)流程,尤其是多任務(wù)渲染流程進行了理論分析,并提出了獨特的參數(shù)調(diào)整策略,即通過優(yōu)化系統(tǒng)中服務(wù)器和渲染機的相關(guān)配置參數(shù)以提高系統(tǒng)的性能。在此基礎(chǔ)上,該團隊還提出一套支持服務(wù)器集群負載均衡、渲染機靜態(tài)擴展和并行任務(wù)調(diào)度的多端協(xié)同云渲染系統(tǒng)(Wang 等,2020)。整套系統(tǒng)的多任務(wù)渲染器和云渲染系統(tǒng)遵循一套通訊機制,可以很好地滿足并發(fā)用戶的渲染需求。Lai等人(2017)提出一種針對“移動端/云”混合渲染的服務(wù)質(zhì)量感知資源調(diào)度策略,該策略將“端/云”兩側(cè)的圖形處理單元相結(jié)合。當網(wǎng)絡(luò)帶寬不穩(wěn)定時,該技術(shù)能夠評估當前的網(wǎng)絡(luò)帶寬,并在“端/云”動態(tài)配置渲染任務(wù)。即使客戶端無法訪問網(wǎng)絡(luò),也仍然可以通過本地計算機上的圖像處理單元執(zhí)行繪制任務(wù)。
動態(tài)服務(wù)調(diào)度在云環(huán)境中得到了廣泛的研究,包括虛擬機合并(Guo 等,2018b)、負載平衡(Le 等,2014)以及網(wǎng)絡(luò)功能鏈接(Guo 等,2018a)等。然而,這些研究通常并不針對外部環(huán)境的可變性所帶來的影響,因此與本項目相比是不夠的。最近的研究已開始側(cè)重于通過在線服務(wù)放置和遷移來解決微型企業(yè)環(huán)境中用戶動態(tài)的關(guān)鍵挑戰(zhàn)(Wang 等,2015b)。此類工作并不一定需要預(yù)測用戶動態(tài)行為,但是針對用戶移動性則可以用馬爾可夫鏈來近似的假設(shè),Taleb等人(2019)制定了一個用戶的馬爾可夫決策過程以跟蹤用戶的最佳用戶感知延遲;Wang等人(2019a)根據(jù)用戶在MEC(mobile edge cloud)網(wǎng)絡(luò)周圍的移動來分配用戶的工作負載,以優(yōu)化隨時間推移的操作和遷移成本;Chen等人(2018)在選定的MECs上放置服務(wù)實例,并隨著時間的推移改進放置決策。
針對多端動態(tài)協(xié)同渲染系統(tǒng),其資源的調(diào)度通?;趦?yōu)化算法獲取當前某時刻應(yīng)用情境的最優(yōu)化配置。然而,渲染系統(tǒng)的實際外部情境下卻是復(fù)雜多變的,某時刻的最優(yōu)化配置無法滿足系統(tǒng)的動態(tài)調(diào)度需求。因此,如何設(shè)定智能且高效的資源調(diào)度配置方案,以適應(yīng)復(fù)雜應(yīng)用情景的動態(tài)變化,成為多端協(xié)同渲染調(diào)度未來研究中的又一個關(guān)鍵問題。
在實際應(yīng)用中,純端繪制會受到能耗、算力和兼容性等因素的影響。因此,在工業(yè)界的生產(chǎn)環(huán)境中的一類重要技術(shù)發(fā)展趨勢就是通過遠程服務(wù)器進行高質(zhì)量的圖形繪制,再將繪制結(jié)果傳輸?shù)蕉嗽O(shè)備上進行圖形顯示,使得輕量級的客戶端也能支持高質(zhì)量的繪制應(yīng)用,這就是工業(yè)界引入遠程渲染的開端。
基于遠程服務(wù)器算力的實時云繪制技術(shù)在實現(xiàn)上沒有統(tǒng)一標準,通常由廠商根據(jù)具體的落地應(yīng)用場景進行深度定制。這些定制重點關(guān)注:硬件集群的資源調(diào)度與管理、串流能力和網(wǎng)絡(luò)自適應(yīng)算法的優(yōu)化、多終端的操作信息獲取和傳送、渲染畫面抓取編碼和超低延遲傳輸以及端側(cè)的解碼和顯示等多維度外圍技術(shù)。
因此,本文立足工業(yè)界,列舉了包括微軟、英偉達、Unity、華為和酷家樂在內(nèi)的國內(nèi)外一線云繪制服務(wù)企業(yè)的經(jīng)典云繪制系統(tǒng),分析并對比了這些系統(tǒng)的設(shè)計框架和技術(shù)特點,為實時云繪制技術(shù)的最終落地提供參考。
CloudXR是美國英偉達公司提出的一套云渲染系統(tǒng),旨在解決包括頭戴式顯示器、手機和平板等瘦客戶端設(shè)備在內(nèi)的前端渲染能力不足問題。CloudXR本質(zhì)上就是一套遠程渲染系統(tǒng),其系統(tǒng)框架如圖8所示。它的主要繪制任務(wù)完全放置于邊緣/云服務(wù)器中,整個繪制過程通過借助英偉達的虛擬化軟件調(diào)用服務(wù)器端GPU得以完成(Gül等,2020)。繪制結(jié)果借助5G或Wi-Fi網(wǎng)絡(luò)以視頻格式串流至前端,解決了包括無線VR/AR應(yīng)用以及移動端在線3維可視化應(yīng)用、移動3維視頻游戲在內(nèi)的瘦客戶端應(yīng)用渲染質(zhì)量低下的問題。
圖8 CloudXR系統(tǒng)架構(gòu)Fig.8 CloudXR system architecture
在數(shù)據(jù)傳輸過程中,CloudXR充分利用5G網(wǎng)絡(luò)優(yōu)先將視頻流推送到近端邊緣服務(wù)器中,之后以更低的網(wǎng)絡(luò)延遲將視頻流迅速推送至各類客戶端設(shè)備(Liubogoshchev等,2021)。另外,NVIDIA還為Cloud-XR提供了5G移動邊緣計算開發(fā)包,給高質(zhì)量三維可視化應(yīng)用在“瘦”客戶端設(shè)備(移動設(shè)備、XR設(shè)備、弱PC設(shè)備)的落地提供了穩(wěn)定的開發(fā)環(huán)境。
Unity render streaming是架構(gòu)在Unity3D游戲引擎上的一套云渲染解決方案??蚣苋鐖D9所示,它基于WebRTC標準建立長連接,實現(xiàn)了高質(zhì)量Unity3D可視化應(yīng)用在Web端的實時展示與交互控制(Tandianus等,2018)。
圖9 Unity render streaming系統(tǒng)架構(gòu)Fig.9 Unity render streaming system architecture
該方案的網(wǎng)絡(luò)構(gòu)架較為簡單,遵循服務(wù)器就近分配原則,一般選取本地云服務(wù)器進行點對點式的端云直接鏈接,排除任何中間服務(wù)器中轉(zhuǎn),如圖10所示。
圖10 Unity render streaming 網(wǎng)絡(luò)架構(gòu)Fig.10 Unity render streaming network architecture
由于架構(gòu)在成熟的游戲引擎中,并以WebRTC為基礎(chǔ),Unity render steaming有其獨特的優(yōu)勢:1)該方案通過引擎內(nèi)核來支持圖像截取,繞開了桌面合成引擎,降低了延遲(Tan等,2021);2)支持Unity所有的渲染特性,支持URP、支持HDRP(high definition render pipeline),也可以支持Builtin管線;3)支持自適應(yīng)碼率,串流帶寬占用較低;4)支持包括Edge、Fireforx、Safari和Chrome在內(nèi)的主流網(wǎng)頁瀏覽器,體現(xiàn)一定的兼容性。對于廣大游戲開發(fā)者而言,尤其是Unity3D引擎的使用者,Unity render steaming是一套行之有效的工業(yè)級云渲染方案。
Azure remote rendering(ARR)是美國微軟公司開發(fā)的遠程渲染系統(tǒng),系統(tǒng)框架如圖11所示,該系統(tǒng)通過移動互聯(lián)網(wǎng)將渲染任務(wù)卸載至云服務(wù)器中,并通過委托在云服務(wù)器上的圖形渲染引擎獲得高質(zhì)量渲染幀,最后將這些渲染幀流式化傳輸至各類微軟支持的移動終端或XR終端中(Chilberto等,2020)。
圖11 ARR系統(tǒng)架構(gòu)Fig.11 ARR system architecture
ARR針對渲染任務(wù)的不同,制定了混合渲染和多GPU渲染兩種方案:1)混合渲染是一種端云協(xié)同式渲染方案,前端負責用戶交互式(user interface, UI)的設(shè)計與渲染,后端負責應(yīng)用的核心渲染任務(wù),兩端的渲染結(jié)果最終都在前端混合并輸出。2)多GPU渲染是一套并行渲染方案,該方案將復(fù)雜的渲染任務(wù)合理地分攤至多個高端GPU上,最終將多個GPU上的渲染結(jié)果進行合并以產(chǎn)生最終的輸出圖像(Jaya等,2020)。
ARR的推出主要是為微軟旗下的MR設(shè)備(Hololens)提供技術(shù)支持,然而隨著系統(tǒng)體系日趨成熟,ARR也逐步成為一套通用的工業(yè)級云渲染解決方案。
酷家樂家裝云設(shè)計平臺(酷家樂云設(shè)計)是一套Web/云協(xié)同渲染平臺(Zheng等,2020),如圖12所示,其中Web端是平臺的主要入口,用戶在Web端通過各垂直細分領(lǐng)域工具,產(chǎn)生3D數(shù)字內(nèi)容,并根據(jù)不同的業(yè)務(wù)需要,提供不同的繪制結(jié)果;云端除基礎(chǔ)服務(wù)外還包含了一個超大規(guī)模的XP 繪制集群,通過集群管理,向用戶提供真實感的繪制結(jié)果,并以圖片或視頻等方式傳送到端。
圖12 酷家樂家裝云設(shè)計平臺Fig.12 “Kujiale” cloud design platform for decoration
平臺的整條技術(shù)鏈路隨著業(yè)務(wù)迭代的復(fù)雜度上升,端與云側(cè)的圖形繪制均呈現(xiàn)了比較大的挑戰(zhàn),具體表現(xiàn)如下:1)Web 端復(fù)雜業(yè)務(wù)及場景帶來的各類問題:(1)場景復(fù)雜度,WebGL 難以充分發(fā)揮現(xiàn)代 GPU 優(yōu)勢,繪制效果與繪制性能的平衡;(2)大場景性能帶來的不可控;(3)細粒度的幾何場景編輯;(4)不同業(yè)務(wù)需要帶來的繪制效果要求與性能平衡。2)復(fù)雜業(yè)務(wù)帶來的離線繪制引擎性能與用戶期望的快速出圖:(1)復(fù)雜場景(數(shù)以億計的三角面片);(2)硬件架構(gòu)如何最優(yōu);(3)服務(wù)器空閑帶來的成本問題;(4)繪制內(nèi)容的多樣化,如圖片、視頻和動畫等。
針對上述問題,酷家樂云設(shè)計平臺基于自主材質(zhì)體系,構(gòu)建了一套較為完備的從Web端到云端的圖形繪制引擎基礎(chǔ)設(shè)施:1)Web端的底層是WebGL圖形顯示引擎,上層是設(shè)計工具及垂直應(yīng)用。2)云端的底層是XPU繪制引擎,上層則是多機器集群通過端云方式,端發(fā)送數(shù)據(jù)到云,同時云端生成繪制結(jié)果返回到端?;诓煌臉I(yè)務(wù)應(yīng)用,云端提供不同的方式返回到端。最終,酷家樂云設(shè)計已經(jīng)能夠作為國內(nèi)在線家裝設(shè)計領(lǐng)域的一線平臺,給廣大用戶(包括移動端、PC端)提供高質(zhì)量的家裝設(shè)計結(jié)果(如圖13所示)。
綜上,通過對比國內(nèi)外著名的一線云渲染系統(tǒng)或解決方案(如表8所示)可以看出,整個工業(yè)界的在線三維可視化應(yīng)用當前正在經(jīng)歷一次由端云協(xié)同驅(qū)動的遠程渲染變革。雖然移動端和Web端這些瘦客戶端不斷地優(yōu)化自身的渲染算法,但對能耗的平衡必然導(dǎo)致此類前端設(shè)備在渲染能力上遠低于桌面端設(shè)備。為此,以在線實時云渲染為代表的遠程渲染技術(shù)隨著網(wǎng)絡(luò)帶寬的不斷增大,逐步成為當下不可或缺的在線實時渲染技術(shù)之一。
表8 工業(yè)界云渲染系統(tǒng)Table 8 Industrial cloud rendering systems
當前,隨著元宇宙及Web 3.0概念的興起,整個3維可視化應(yīng)用正在經(jīng)歷一次由移動互聯(lián)網(wǎng)驅(qū)動的在線實時化繪制變革。雖然近年來移動端GPU渲染能力穩(wěn)步提升,然而受功耗、帶寬以及布局空間等先天條件制約,它與桌面端GPU的性能差距一直在不斷拉大。為了滿足移動互聯(lián)網(wǎng)用戶對設(shè)備繪制能力需求的提升,同時兼顧移動端設(shè)備的功耗級別與負載均衡,設(shè)備廠商提出了包括SOC芯片集成構(gòu)架、TBR渲染構(gòu)架和延遲片元著色等一系列面向移動端的渲染優(yōu)化設(shè)計。研究者們則另辟蹊徑,不僅對高耗能實時光線跟蹤算法的移動端實現(xiàn)提出了挑戰(zhàn),而且面向功耗和帶寬的先天不足提出各種優(yōu)化渲染策略。引擎開發(fā)商也不逞多讓,以Unreal和Unity3D為代表的3D游戲引擎,緊隨移動互聯(lián)網(wǎng)發(fā)展的潮流,為移動端提供了通用的渲染管線和良好的可視化的3D應(yīng)用制作平臺。
Web端作為輕量級跨平臺的主流瀏覽環(huán)境,在移動互聯(lián)網(wǎng)時代下仍然擁有極高的用戶群體。隨著諸如X3D、WebGL和WebGPU等各種3維圖形API的提出,Web端已經(jīng)具有制作3D應(yīng)用的核心技術(shù),具有高度真實感和沉浸感的Web3D應(yīng)用開始展現(xiàn)在用戶面前。隨著移動互聯(lián)網(wǎng)技術(shù)的推波助瀾,Web在線3維實時繪制研究已經(jīng)向超大規(guī)模場景實時繪制、照片級真實感和沉浸式交互感等多個目標發(fā)起挑戰(zhàn)。為此,研究者們針對超大規(guī)模場景輕量化、場景的細粒度化、對等傳輸、基于PBR的真實感材質(zhì)、實時全局光照繪制以及GPU加速動畫繪制等多個方面展開了相關(guān)研究。
雖然移動端和Web端這些瘦客戶端不斷地優(yōu)化自身的渲染算法,但受能耗的限制必然導(dǎo)致此類客戶端在渲染能力上遠低于桌面客戶端。為此,以在線實時云繪制為代表的遠程繪制技術(shù)隨著移動互聯(lián)網(wǎng)帶寬的不斷提升,逐步成為當下不可或缺的在線實時繪制的輔助手段之一。當前,云繪制的主要任務(wù)有3個方面:3D應(yīng)用的自動化托管、資源調(diào)度和串流技術(shù)的應(yīng)用,其中串流技術(shù)的應(yīng)用是云繪制的核心。因此,各大云服務(wù)廠商和研究機構(gòu)把云繪制的優(yōu)化重點放在了串流技術(shù)的優(yōu)化上,包括視頻流的無損/低損壓縮技術(shù)和視頻流質(zhì)量優(yōu)化等。
然而,云繪制技術(shù)過度依托云服務(wù)器的渲染能力,完全忽略了前端設(shè)備。考慮到目前的瘦客戶端的渲染能力已經(jīng)發(fā)展到一定水準,讓端云同時發(fā)揮各自繪制能力的“端云協(xié)同”技術(shù)將成為未來主流的移動在線實時渲染技術(shù)。端云協(xié)同的重點在渲染任務(wù)的分攤上,包括:光影渲染任務(wù)的分攤、著色器渲染任務(wù)的分攤和光柵化渲染任務(wù)的分攤等。渲染任務(wù)分攤好之后,讓前端根據(jù)其繪制能力適當?shù)爻挟斊淞λ芗暗匿秩救蝿?wù),不僅可以提高前端設(shè)備的利用率,而且降低了云服務(wù)器的繪制負擔。展望未來,隨著邊緣計算和云計算的迅速普及,移動互聯(lián)網(wǎng)的在線協(xié)同繪制構(gòu)架已經(jīng)從簡單的端/云構(gòu)架,逐漸演變成較為復(fù)雜的端/邊/云構(gòu)架。面對新的構(gòu)架,全新的端/邊/云渲染任務(wù)的分攤成為協(xié)同渲染的一個研究目標。另外,當前多端渲染系統(tǒng)的計算調(diào)度模式固化,在不同設(shè)備性能、不同軟件平臺和不同網(wǎng)絡(luò)條件的復(fù)雜外部環(huán)境下,智能化協(xié)同調(diào)度機制使得整個多端渲染系統(tǒng)的性能無法發(fā)揮最佳水準,是當前端/邊/云協(xié)同在線繪制的另一個重點研究對象。此外,隨著WebGPU的普及,WebAssembly + WebGPU的組合方案預(yù)計會成為復(fù)雜在線 3D 場景的主流底層技術(shù)方案之一,基于該方案下的實時繪制效果也能得到更好的提升。
致 謝本文由中國圖象圖形學學會虛擬現(xiàn)實專業(yè)委員會組織撰寫,該專委會更多詳情請見鏈接:http://www.csig.org.cn/detail/2385。