四維智能分布式遠程實時渲染方案

李 楊 邵先杰 李琳娜

(青島已臻化境影視科技有限公司,山東青島 266000)

1 引言

影視行業、汽車行業、建筑行業、游戲行業以及最近興起的“元宇宙”,對三維模型、大型場景、特效、燈光材質等渲染的需求量不斷增大。在解決渲染、著色大型場景及高精度模型時,用戶一般采用基于本地單機的解決方案來完成場景的加載及渲染流程,此傳統渲染、著色、打包流程通常對本地的硬件配置需求較高,不僅增加開發成本,無法保證渲染速度,而且項目(建模或其他基于三維引擎的源文件)制作階段無法精準回溯到對應版本,從而給開發中的項目帶來不可逆的修改/損壞。在此背景下,我們結合工作實踐,提出四維智能分布式遠程實時渲染(Four Dimensional Intelligent Distributed Rendering)的解決方案。

四維智能分布式遠程實時渲染系統為多用戶提供在線的靜態渲染、實時渲染、場景加載、編譯、著色等服務。服務端采用集群模塊化任務(Control Module Types,CMT)工作方式,基于智能分布式調度服務(Intelligent Distributed Scheduling,IDS)為用戶提供高效的云端渲染和加載解決方案。

與傳統意義上的實時渲染概念不同,本文提出的四維智能分布式遠程實時渲染是用戶端通過傳輸插件與服務端建立實時的數據傳輸通道,用戶數據上載到服務端,通過集群模塊化任務(CMT)及智能分布式調度服務(IDS)分發至執行器(執行渲染或加載任務),任務執行完畢后統一打包輸入到用戶端或通過Web遠程顯示渲染任務的輸出結果。此系統為用戶生成以每次上載節點為時間軸的“第四維度”檔案,用戶可以此回檔到以前的任意節點或建立新的分支。本系統核心思想為:用戶以鏈接云端的方式,依托云端服務器集群,獲得高效、實時穩定及安全的開發體驗。因其大部分計算都集成在云端,從而大大降低對本地硬件的配置要求,降低了開發成本。

2 四維智能分布式遠程實時渲染模型

為應對用戶開發中不同的請求場景(靜態/實時渲染、著色、打包等),服務端配置了多條業務流程以滿足客戶不同的開發場景,用戶端可根據需要安裝如3DMAX、MAYA或UE、Unity等軟件的內置插件,通過傳輸插件與服務端建立連接的方式進行云端渲染操作。

四維智能分布式遠程實時渲染總體功能模塊如下:

圖1 四維智能分布式遠程實時渲染總體功能模塊

四維智能分布式遠程實時渲染使用傳輸插件與云端建立通信以動態響應本地操作,并將本次的相應操作以“時間”為節點進行云端存儲。本系統的實時渲染部分底層執行器為主要基于Unreal Engine 4的動態渲染功能或基于普通幀圖(效果圖)的渲染。功能分為:①基礎幀圖(效果圖)渲染;②動態響應本地操作(Unreal Engine 操作)輸出到WEB端的實時渲染;③動態響應本地操作(主流建模軟件操作)輸出到WEB端的實時渲染(服務端);④輔助加載,用戶端通過請求,服務端可將編譯、加載、著色或打包后的文件異步輸出到用戶端。

2.1 維度一:基礎靜態渲染服務

適用用戶群體:需要借助云端進行單一的幀渲染操作的用戶。使用本地軟件完成整個場景的制作后,打包上載到服務器進行渲染任務,輸出物下載到用戶本地。

基礎靜態模型渲染為常規云端渲染方案,存在小部分需求差別。用戶使用流程:用戶需要在對應的建模軟件中內置插件,在插件中,選擇點擊渲染后,本地文件通過傳輸插件與服務器建立通信,上載資源。

用戶資源上載到云端存儲后交由分析服務器進行如下處理:①校驗文件完整性;②.檢查場景內外部資源文件是否正常引入;③分析場景復雜度(面數、材質、燈光及其他基本參數)及用時,隨后生成分析報告數據轉交CMT服務處理。

CMT模塊化任務/整合服務處理:CMT會將用戶任務根據分析報告進行拆分,如用戶渲染場景中的某幀,會在分析完成后生成本任務的分析報告,CMT依據分析報告將本任務拆分成多份任務片段轉交于調度中心。如圖2所示,調度中心派發任務到執行器進行渲染任務,渲染執行完畢后將任務片段發送回CMT進行結果校驗與整合操作,后經過存儲與傳輸服務,最終渲染結果下載至用戶端。

圖2 靜態渲染智能調度渲染

圖2所示的渲染流程與傳統的渲染農場相比:新增分析服務器與模塊化任務/整合服務,提高執行器使用率,從而達到加快渲染的效果。

2.2 維度二:動態響應實時加載服務

適用用戶群體:需要借助云端進行如UE4前期的著色、后期的打包及其他需要長時加載的任務,用戶本地軟件與云端建立實時連接,輸出物下載到用戶本地。

如圖3所示,動態響應實時加載模型,適用于用戶在使用三維引擎開發階段,幫助用戶以較低的硬件配置順利完成前期模型加載及后期的打包工作。

圖3 動態響應實時加載模型

步驟1:用戶使用三維引擎的內置插件(需配合業務開發,此插件包含傳輸服務)建立與云端的通信,云端會動態響應用戶端的操作。

步驟2:插件通過傳輸服務將需要加載的文件上載到云端存儲。

步驟3:分析服務器校驗文件完整性與復雜程度,生成分析報告數據轉交CMT服務處理。

步驟4:CMT根據“分析報告”,將本次任務細分多個子任務模塊(細分數量由“分析報告”參數決定),后統一打包交由智能調度中心分配到具體執行節點機進行處理。

步驟5:執行器將輸出結果匯總到CMT,由CMT整合打包后輸出到云端存儲中。

輸出:該方案結果文件返回給用戶的方法有兩種:①用戶一次性下載全部結果文件至本地對應路徑下并完成本次動態加載;②使用動態下載機制,云端存儲內收到CMT返回的結果后,用戶插件端會動態監測用戶所在的三維場景區域并實時監測當前的資源文件分塊,分批次下載到用戶電腦直至完成。“動態響應實時加載”方案一定程度上解決了部分資源浪費的問題。

2.3 維度三:動態響應實時渲染服務

適用用戶群體:模式1為用戶在本地只有三維建模軟件的情況下,需要輸出實時渲染畫面至Web頁面供用戶查看或分享;模式2是用戶使用三維引擎時需要輸出實時渲染畫面至Web頁面供用戶查看或分享。以上兩種模式均需在使用軟件中與云端建立實時連接。

動態響應實時渲染模型即云端動態渲染服務,提供完整的用戶動態在線實時渲染解決方案,當前系統模型共分為兩種,主要模式為用戶提供不同的應用場景解決方案。

2.3.1 模式1如圖4所示,用戶無需使用任何三維引擎即可完成基于WEB服務器顯示的實時渲染模式。

圖4 動態響應實時渲染模型

步驟1:用戶使用建模軟件的內置插件(需配合業務開發,此插件包含傳輸服務)建立與云端的通信,云端會動態響應用戶端的操作。

步驟2:插件通過傳輸服務將需要加載的文件上載到云端存儲。

步驟3:分析服務器校驗文件完整性與復雜程度,生成分析報告數據轉交三維引擎轉化器。

步驟4:將3D文件通過“三維引擎轉化器”轉換為三維引擎文件,轉交CMT服務處理。

步驟5:CMT根據“分析報告”將本次任務細分為多個子任務模塊(細分數量由“分析報告”參數決定),后統一打包交由智能調度中心分配到具體執行節點機進行處理。

步驟6:執行器將輸出結果匯總到CMT,由CMT整合打包后輸出到云端存儲中。

輸出:存儲文件部署于WEB服務器,可通過網絡訪問并實時操作(在實時渲染的場景中查看三維元素)。上述步驟會在用戶修改本地建模軟件的內容后動態執行并顯示于WEB端以做到異步實時渲染的效果。

2.3.2 模式2如圖5所示,用戶使用三維引擎開發時與云端建立連接動態實時渲染模式。

圖5 動態響應實時渲染模型

步驟1:用戶使用三維引擎的內置插件(需配合業務開發,此插件包含傳輸服務)建立與云端的通信,云端會動態響應用戶端的操作。

步驟2:插件通過傳輸服務將需要加載的文件上載到云端存儲。

步驟3:分析服務器校驗文件完整性與復雜程度,生成分析報告數據轉交CMT服務處理。

步驟4:CMT根據“分析報告”將本次任務細分為多個子任務模塊(細分數量由“分析報告”參數決定),后統一打包交由智能調度中心分配到具體執行節點機進行處理。

輸出:存儲文件部署于WEB服務器,可通過網絡訪問并實時操作(在實時渲染的場景中查看三維元素)。上述步驟會在用戶修改本地建模軟件的內容后動態執行并顯示于WEB端以做到異步實時渲染的效果。

2.4 維度四:“時間可視化”項目存儲管理服務

如圖6所示,本次分布式存儲服務器包含“四維項目存儲管理”服務,用戶每次通過上述模型進行云端通信時,存儲服務會記錄當前內容并生成以時間為主的節點,本功能可由用戶選擇開啟或關閉。

圖6 四維項目存儲管理

用戶也可以主動將項目提交到云端存儲中進行管理,用戶上傳項目后會在云端存儲中開辟一塊專用加密區域,本加密區域受對應權限管控,上傳者可分配權限至某組/人,作為后續協同開發的限制條件。

模式1:用戶可自行上載或下載本用戶權限內的項目,包括項目的歷史版本。項目上載用戶即默認為本項目的權限管理員。

模式2:用戶上載項目后,可邀請/分享至其他用戶,被邀請的用戶可通過獲取權限后下載項目中某個節點的項目文件,并可上載生成新項目分支或合并,從而達成多人協同開發的目的。

3 關鍵技術

3.1 傳輸技術

使用多客戶端對應服務的方式,實現將當前平臺數據實時同步到服務端并對此數據進行存儲保存,獲取服務端數據到web端進行展示,從而有效降低用戶本地硬件配置需求和硬件成本。通過插件集成的方式,當用戶需要同步場景時將平臺數據(包括當前場景環境數據、模型數據、著色數據等信息)下載到服務端。

此研究需要的數據同步要求較高,既要保證可靠穩定的數據傳輸,也要保證通信速度快的特點,這樣才能達到在云平臺同步展示實時渲染場景的效果要求。對應此應用場景,當前主要有TCP和UDP兩種傳輸方式,它們的優缺點比較明顯。TCP在傳輸有效數據之前,存在“三次握手”用來創建客戶端與服務端之間的連接,并且在傳遞數據時,存在確認機制、窗口機制、重傳機制、擁塞控制機制,在傳遞數據完成后,還會斷開客戶端與服務端之間的連接以節約系統資源。正因如此,TCP為了實現網絡信息交互與傳遞的可依賴性,使用了復雜的擁塞控制實用性方法,請求過程繁瑣。由于TCP內置的協議堆疊,對其進行改進比較困難。UDP對比TCP沒有繁瑣的請求機制、確認機制、窗口機制、重傳機制、擁塞控制機制,是一個沒有狀態的通信協議,所以在信息交互與傳遞時非常快,但帶來的后果就是不可靠、不穩定,很容易出現丟失有效數據的現象,造成數據傳輸的失效。

因此,針對于此問題使用基于UDP的高速傳輸同時能夠保證可靠性的新型協議是有必要的。

3.2 分布式存儲

分布式存儲是相對于集中式存儲而言的。集中式存儲相對分布式存儲實現起來比較簡單,易于維護一致性,在一定的頻繁操作中可以為使用者提供較為滿意的性能。集中式存儲的缺點也較明顯:一是如果該服務器失效,整個系統將出現無法正常工作的現象;二是由于集中式存儲中有一個節點專門司職元數據管理,所有元數據都存儲在該節點的存儲設備上。所有客戶端對文件的請求前,都要先對該元數據管理器請求元數據,這樣就會出現當元數據操作過于頻繁時,系統會出現排隊堵塞現象,從而成為整個系統的性能瓶頸。分布式存儲很好地解決了集中式存儲的這兩個弊端。

目前常見的分布式存儲架構有中間控制節點架構(HDFS)、安全無中心架構——計算模式(Ceph)、安全無中心架構——一致性哈希(Swift)等。

本系統存儲采用分布式系統結構,實現多臺存儲服務器分擔存儲負荷,位置服務器定位存儲信息的高效方式。其表現如下:

(1)支持自動的分級存儲有效管理讀緩存和寫緩存機制。在管理讀緩存中,通過將熱點區域數據映射到高速存儲中實現提升系統響應速度操作,并且在發現熱點區域有變化時就將其移出高速存儲以保證性能;在管理寫緩存中,先將數據寫入高速存儲,在合適的時間點自動進行同步落盤操作。

(2)松耦合的網絡架構機制。高速、低速存儲分開部署或任意比例混合存儲;在敏捷開發或不可預測的業務環境情況下,可以盡可能發揮分層存儲的優勢。

(3)概念數據模型及多副本備份機制。在存儲數據之前,先將數據進行分片處理,并將分片后的數據按照有效規則保存到集群節點上;為了保證多個數據副本之間的一致性,使用一個副本寫入,多個副本讀取的方式;為了滿足對于可靠性不同的需求,使用鏡像、條帶、分布式校驗等方式;有效地保證了當讀取失敗時,可以從其余副本讀取數據,寫入該副本進行恢復,從而保證了副本的總數一定;當數據長時間保持不一致錯誤時,系統會自動對數據進行重建恢復,為了對業務產生最小的影響,可設定數據恢復的寬帶規則。

(4)數據容災備份機制。為了實現生產系統各版本數據的有效保存,使用了多時間點快照技術;這種方式還支持同時提取多個時間點樣本同時恢復,有效保證多個邏輯錯誤災難的定位。

(5)彈性擴展機制。為了避免單點過熱,將舊數據自動遷移至新節點實現負載均衡;添加新節點后集群系統的整體容量和性能將實現線性擴展,這種方式實現簡單,只需將新節點和原有集群連接到同一網絡中即可,整個過程不會對業務系統產生不必要的麻煩。

3.3 智能調度

為了將大量運算任務合理分配至執行器執行,需要依賴于智能調度服務的“智能任務派發機制(根據在線用戶數量及任務數量等條件分配任務)”。智能調度服務負責向云端節點機分發任務,用于完成渲染、加載等業務需求并通過節點機實際運用情況合理分配當前資源以提升用戶的使用體驗。

3.3.1 模塊

調度中心:負責管理調度信息,根據后臺配置設定選擇適合當前使用的調度策略,完成對用戶任務的分配與監控各執行器的運行狀態與數據統計。

執行模塊(執行器):用于執行實際的運算任務,如:渲染、加載、打包等。

3.3.2 架構圖

調度服務運行著一個節點管理程序,所有系統內運行正常的節點機都會注冊在內,并且實時監控節點機的運行狀態及“健康”狀況。當業務端發來任務時,調度中心會根據當前的用戶數量、任務數量及可用節點機數量分配任務。執行器運行結束后會將結果返回至調度中心,調度中心則通知業務端進行后續處理。

圖7 智能調度架構圖

3.4 虛幻引擎

本文中的實時渲染將基于UE4做重點技術分析。UE4中包括的著色器、半透明物體、動態陰影、材質等幾項配置是影響渲染的主要因素,以下為系統重點優化的配置選項:

3.4.1 渲染幾何體

首先確認需渲染物體的順序,渲染時會對每一個材質進行一次draw call操作。然后通過stat RHI可以查看draw call信息。若draw call信息超過10000次會對性能產生嚴重影響,如考慮用于手機游戲和vr設備端,可控制1500次左右的調用即可。大量頂點的運動,建議將其移動到頂點著色器中實現。

3.4.2 材質

一般情況下,遠處的幾何體占用的像素較少,因此可以使用相對復雜一點的著色器,近處幾何體反之。著色器指令數一般在90-210之間即可,多出此范圍可能會影響渲染性能。

3.4.3 反射

UE4中有三種不同的反射系統 。通常將三種反射混合使用,且每出現一次反射就會重新渲染一次屏幕。

(1)反射環境:反射環境是采集多個點處的靜態關卡,將其投射到反射中的簡單集合提示上。反射會在編輯的過程中實時更新,但在運行時為靜態。每個像素在多個幾何體貼圖之間混合,以獲得最終效果輸出。較小的Actor將覆蓋較大的Actor,因此可根據設計需要增強區域內的反射視差準確度。簡單來說,就是可以將裝置放置在空間中來提升反射效果。

(2)反射捕捉Actor:反射捕捉Actor是精心放置在關卡各處的Object,它將反向數據饋送到反射環境中。當前有兩個反射采集形狀:球體和盒體。形狀十分重要,因為它控制著場景的哪個部分將被采集到立方體貼圖中、反射中關卡被重新投射到什么形狀上,以及關卡的哪個部分可以接收來自該立方體貼圖的反射(影響區域)。

(3)屏幕空間反射是一種引擎功能,可幫助將Object置于地面之類的平坦表面上。它在默認情況下是激活的,與反射環境的結果相混合,提供更全面的反射感。默認情況下屏幕空間反射在UE4中處于活動狀態,但可以根據設置使用控制臺命令_r.SSR.Quality 3_或_r.SSR.Quality 0_切換。。

3.4.4 G緩存和光柵化

因為當物體相對主視角越遠,它所覆蓋的像素越少,所以應該減少物體的面數來減少著色器的運算量。此項在UE5中可能會有所優化。

3.4.5 靜態光照系統

靜態光照是預計算光照系統,每次有物體改變(形狀、參數、位置等待)就需要重新計算,但是性能很好,渲染很快,可以用于全局光照。

3.4.6 動態光照系統

動態光照使用G-buffer來實現實時渲染,可以隨時進行各參數修改,但陰影對性能影響很大,不會產生軟陰影與產生全局光照。

3.4.7 霧和透明度

UE4中有兩種類型的距離霧:大氣霧和指數霧,距離霧指霧會隨距離而衰減。大氣霧性能相對優秀,指數霧則效果相對突出。

4 系統組成服務/搭建

系統總體架構如圖8所示。

圖8 四維智能分布式遠程實時渲染模型

4.1 用戶端

用戶將服務插件集成于軟件(UE4等)中,賦予其權限后可快捷地將本地項目相關文件同步到云端(手動/自動), 在云端完成計算后,根據用戶業務實時顯示于WEB或下載到本地。

4.2 云端

運算用戶端交互數據、提供WEB實時渲染服務及項目分支管理。

4.2.1 WEB服務器

為用戶在線實時渲染提供WEB端操作/顯示渲染結果以及提供“時間可視化”項目存儲管理服務的訪問。

4.2.2 傳輸服務

傳輸服務作為用戶端與云端重要的服務之一,其性能會影響到云端服務響應速度,調用傳輸服務方式分為軟件內置插件調用與WEB端調用。傳輸技術詳情查看3.1。

4.2.3 “時間可視化”項目存儲管理服務

項目分支管理系統,模式分為兩種:

(1)主動管理:用戶可主動將工程項目上載至服務器,服務器保留各個時間段用戶上載的不同項目版本,用戶借此可達成多地協同開發或回退版本及分支開發測試、快捷在線渲染等。

(2)被動管理:本服務建立在用戶軟件內集成云端插件為前提,系統自動將項目同步到云端進行管理并自動生成以關鍵時間為節點的多版本項目,用戶可用此功能進行項目恢復、協同開發或快速渲染等。但此功能項目文件將只存儲近7天內容。用戶可選擇關閉“被動管理功能”。

5 總結

隨著對實時渲染及模型加載等運算需求的日益增多,以及對硬件配置的要求提高,降低用戶的硬件開發成本及相對縮短開發周期顯得格外重要。我們基于測試、技術預研對智能分布式調度的四維智能分布式遠程實時渲染方面做出研究,以期為行業提供更加高效的云端渲染和資源加載,通過研究和實踐四維智能分布式遠程實時渲染方法,依托云端服務器集群為用戶提供高效、實時穩定及安全的渲染體驗。?