李 楊 邵先杰 李琳娜

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

1 引言

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

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

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

2 四維智能分布式遠(yuǎn)程實(shí)時(shí)渲染模型

為應(yīng)對(duì)用戶開發(fā)中不同的請(qǐng)求場(chǎng)景(靜態(tài)/實(shí)時(shí)渲染、著色、打包等),服務(wù)端配置了多條業(yè)務(wù)流程以滿足客戶不同的開發(fā)場(chǎng)景,用戶端可根據(jù)需要安裝如3DMAX、MAYA或UE、Unity等軟件的內(nèi)置插件,通過傳輸插件與服務(wù)端建立連接的方式進(jìn)行云端渲染操作。

四維智能分布式遠(yuǎn)程實(shí)時(shí)渲染總體功能模塊如下:

圖1 四維智能分布式遠(yuǎn)程實(shí)時(shí)渲染總體功能模塊

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

2.1 維度一:基礎(chǔ)靜態(tài)渲染服務(wù)

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

基礎(chǔ)靜態(tài)模型渲染為常規(guī)云端渲染方案,存在小部分需求差別。用戶使用流程:用戶需要在對(duì)應(yīng)的建模軟件中內(nèi)置插件,在插件中,選擇點(diǎn)擊渲染后,本地文件通過傳輸插件與服務(wù)器建立通信,上載資源。

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

CMT模塊化任務(wù)/整合服務(wù)處理:CMT會(huì)將用戶任務(wù)根據(jù)分析報(bào)告進(jìn)行拆分,如用戶渲染場(chǎng)景中的某幀,會(huì)在分析完成后生成本任務(wù)的分析報(bào)告,CMT依據(jù)分析報(bào)告將本任務(wù)拆分成多份任務(wù)片段轉(zhuǎn)交于調(diào)度中心。如圖2所示,調(diào)度中心派發(fā)任務(wù)到執(zhí)行器進(jìn)行渲染任務(wù),渲染執(zhí)行完畢后將任務(wù)片段發(fā)送回CMT進(jìn)行結(jié)果校驗(yàn)與整合操作,后經(jīng)過存儲(chǔ)與傳輸服務(wù),最終渲染結(jié)果下載至用戶端。

圖2 靜態(tài)渲染智能調(diào)度渲染

圖2所示的渲染流程與傳統(tǒng)的渲染農(nóng)場(chǎng)相比:新增分析服務(wù)器與模塊化任務(wù)/整合服務(wù),提高執(zhí)行器使用率,從而達(dá)到加快渲染的效果。

2.2 維度二:動(dòng)態(tài)響應(yīng)實(shí)時(shí)加載服務(wù)

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

如圖3所示,動(dòng)態(tài)響應(yīng)實(shí)時(shí)加載模型,適用于用戶在使用三維引擎開發(fā)階段,幫助用戶以較低的硬件配置順利完成前期模型加載及后期的打包工作。

圖3 動(dòng)態(tài)響應(yīng)實(shí)時(shí)加載模型

步驟1:用戶使用三維引擎的內(nèi)置插件(需配合業(yè)務(wù)開發(fā),此插件包含傳輸服務(wù))建立與云端的通信,云端會(huì)動(dòng)態(tài)響應(yīng)用戶端的操作。

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

步驟3:分析服務(wù)器校驗(yàn)文件完整性與復(fù)雜程度,生成分析報(bào)告數(shù)據(jù)轉(zhuǎn)交CMT服務(wù)處理。

步驟4:CMT根據(jù)“分析報(bào)告”,將本次任務(wù)細(xì)分多個(gè)子任務(wù)模塊(細(xì)分?jǐn)?shù)量由“分析報(bào)告”參數(shù)決定),后統(tǒng)一打包交由智能調(diào)度中心分配到具體執(zhí)行節(jié)點(diǎn)機(jī)進(jìn)行處理。

步驟5:執(zhí)行器將輸出結(jié)果匯總到CMT,由CMT整合打包后輸出到云端存儲(chǔ)中。

輸出:該方案結(jié)果文件返回給用戶的方法有兩種:①用戶一次性下載全部結(jié)果文件至本地對(duì)應(yīng)路徑下并完成本次動(dòng)態(tài)加載;②使用動(dòng)態(tài)下載機(jī)制,云端存儲(chǔ)內(nèi)收到CMT返回的結(jié)果后,用戶插件端會(huì)動(dòng)態(tài)監(jiān)測(cè)用戶所在的三維場(chǎng)景區(qū)域并實(shí)時(shí)監(jiān)測(cè)當(dāng)前的資源文件分塊,分批次下載到用戶電腦直至完成?！皠?dòng)態(tài)響應(yīng)實(shí)時(shí)加載”方案一定程度上解決了部分資源浪費(fèi)的問題。

2.3 維度三:動(dòng)態(tài)響應(yīng)實(shí)時(shí)渲染服務(wù)

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

動(dòng)態(tài)響應(yīng)實(shí)時(shí)渲染模型即云端動(dòng)態(tài)渲染服務(wù),提供完整的用戶動(dòng)態(tài)在線實(shí)時(shí)渲染解決方案,當(dāng)前系統(tǒng)模型共分為兩種,主要模式為用戶提供不同的應(yīng)用場(chǎng)景解決方案。

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

圖4 動(dòng)態(tài)響應(yīng)實(shí)時(shí)渲染模型

步驟1:用戶使用建模軟件的內(nèi)置插件(需配合業(yè)務(wù)開發(fā),此插件包含傳輸服務(wù))建立與云端的通信,云端會(huì)動(dòng)態(tài)響應(yīng)用戶端的操作。

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

步驟3:分析服務(wù)器校驗(yàn)文件完整性與復(fù)雜程度,生成分析報(bào)告數(shù)據(jù)轉(zhuǎn)交三維引擎轉(zhuǎn)化器。

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

步驟5:CMT根據(jù)“分析報(bào)告”將本次任務(wù)細(xì)分為多個(gè)子任務(wù)模塊(細(xì)分?jǐn)?shù)量由“分析報(bào)告”參數(shù)決定),后統(tǒng)一打包交由智能調(diào)度中心分配到具體執(zhí)行節(jié)點(diǎn)機(jī)進(jìn)行處理。

步驟6:執(zhí)行器將輸出結(jié)果匯總到CMT,由CMT整合打包后輸出到云端存儲(chǔ)中。

輸出:存儲(chǔ)文件部署于WEB服務(wù)器,可通過網(wǎng)絡(luò)訪問并實(shí)時(shí)操作(在實(shí)時(shí)渲染的場(chǎng)景中查看三維元素)。上述步驟會(huì)在用戶修改本地建模軟件的內(nèi)容后動(dòng)態(tài)執(zhí)行并顯示于WEB端以做到異步實(shí)時(shí)渲染的效果。

2.3.2 模式2如圖5所示,用戶使用三維引擎開發(fā)時(shí)與云端建立連接動(dòng)態(tài)實(shí)時(shí)渲染模式。

圖5 動(dòng)態(tài)響應(yīng)實(shí)時(shí)渲染模型

步驟1:用戶使用三維引擎的內(nèi)置插件(需配合業(yè)務(wù)開發(fā),此插件包含傳輸服務(wù))建立與云端的通信,云端會(huì)動(dòng)態(tài)響應(yīng)用戶端的操作。

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

步驟3:分析服務(wù)器校驗(yàn)文件完整性與復(fù)雜程度,生成分析報(bào)告數(shù)據(jù)轉(zhuǎn)交CMT服務(wù)處理。

步驟4:CMT根據(jù)“分析報(bào)告”將本次任務(wù)細(xì)分為多個(gè)子任務(wù)模塊(細(xì)分?jǐn)?shù)量由“分析報(bào)告”參數(shù)決定),后統(tǒng)一打包交由智能調(diào)度中心分配到具體執(zhí)行節(jié)點(diǎn)機(jī)進(jìn)行處理。

輸出:存儲(chǔ)文件部署于WEB服務(wù)器,可通過網(wǎng)絡(luò)訪問并實(shí)時(shí)操作(在實(shí)時(shí)渲染的場(chǎng)景中查看三維元素)。上述步驟會(huì)在用戶修改本地建模軟件的內(nèi)容后動(dòng)態(tài)執(zhí)行并顯示于WEB端以做到異步實(shí)時(shí)渲染的效果。

2.4 維度四:“時(shí)間可視化”項(xiàng)目存儲(chǔ)管理服務(wù)

如圖6所示,本次分布式存儲(chǔ)服務(wù)器包含“四維項(xiàng)目存儲(chǔ)管理”服務(wù),用戶每次通過上述模型進(jìn)行云端通信時(shí),存儲(chǔ)服務(wù)會(huì)記錄當(dāng)前內(nèi)容并生成以時(shí)間為主的節(jié)點(diǎn),本功能可由用戶選擇開啟或關(guān)閉。

圖6 四維項(xiàng)目存儲(chǔ)管理

用戶也可以主動(dòng)將項(xiàng)目提交到云端存儲(chǔ)中進(jìn)行管理,用戶上傳項(xiàng)目后會(huì)在云端存儲(chǔ)中開辟一塊專用加密區(qū)域,本加密區(qū)域受對(duì)應(yīng)權(quán)限管控,上傳者可分配權(quán)限至某組/人,作為后續(xù)協(xié)同開發(fā)的限制條件。

模式1:用戶可自行上載或下載本用戶權(quán)限內(nèi)的項(xiàng)目,包括項(xiàng)目的歷史版本。項(xiàng)目上載用戶即默認(rèn)為本項(xiàng)目的權(quán)限管理員。

模式2:用戶上載項(xiàng)目后,可邀請(qǐng)/分享至其他用戶,被邀請(qǐng)的用戶可通過獲取權(quán)限后下載項(xiàng)目中某個(gè)節(jié)點(diǎn)的項(xiàng)目文件,并可上載生成新項(xiàng)目分支或合并,從而達(dá)成多人協(xié)同開發(fā)的目的。

3 關(guān)鍵技術(shù)

3.1 傳輸技術(shù)

使用多客戶端對(duì)應(yīng)服務(wù)的方式,實(shí)現(xiàn)將當(dāng)前平臺(tái)數(shù)據(jù)實(shí)時(shí)同步到服務(wù)端并對(duì)此數(shù)據(jù)進(jìn)行存儲(chǔ)保存,獲取服務(wù)端數(shù)據(jù)到web端進(jìn)行展示,從而有效降低用戶本地硬件配置需求和硬件成本。通過插件集成的方式,當(dāng)用戶需要同步場(chǎng)景時(shí)將平臺(tái)數(shù)據(jù)(包括當(dāng)前場(chǎng)景環(huán)境數(shù)據(jù)、模型數(shù)據(jù)、著色數(shù)據(jù)等信息)下載到服務(wù)端。

此研究需要的數(shù)據(jù)同步要求較高,既要保證可靠穩(wěn)定的數(shù)據(jù)傳輸,也要保證通信速度快的特點(diǎn),這樣才能達(dá)到在云平臺(tái)同步展示實(shí)時(shí)渲染場(chǎng)景的效果要求。對(duì)應(yīng)此應(yīng)用場(chǎng)景,當(dāng)前主要有TCP和UDP兩種傳輸方式,它們的優(yōu)缺點(diǎn)比較明顯。TCP在傳輸有效數(shù)據(jù)之前,存在“三次握手”用來創(chuàng)建客戶端與服務(wù)端之間的連接,并且在傳遞數(shù)據(jù)時(shí),存在確認(rèn)機(jī)制、窗口機(jī)制、重傳機(jī)制、擁塞控制機(jī)制,在傳遞數(shù)據(jù)完成后,還會(huì)斷開客戶端與服務(wù)端之間的連接以節(jié)約系統(tǒng)資源。正因如此,TCP為了實(shí)現(xiàn)網(wǎng)絡(luò)信息交互與傳遞的可依賴性,使用了復(fù)雜的擁塞控制實(shí)用性方法,請(qǐng)求過程繁瑣。由于TCP內(nèi)置的協(xié)議堆疊,對(duì)其進(jìn)行改進(jìn)比較困難。UDP對(duì)比TCP沒有繁瑣的請(qǐng)求機(jī)制、確認(rèn)機(jī)制、窗口機(jī)制、重傳機(jī)制、擁塞控制機(jī)制,是一個(gè)沒有狀態(tài)的通信協(xié)議,所以在信息交互與傳遞時(shí)非?？?但帶來的后果就是不可靠、不穩(wěn)定,很容易出現(xiàn)丟失有效數(shù)據(jù)的現(xiàn)象,造成數(shù)據(jù)傳輸?shù)氖А?/p>

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

3.2 分布式存儲(chǔ)

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

目前常見的分布式存儲(chǔ)架構(gòu)有中間控制節(jié)點(diǎn)架構(gòu)(HDFS)、安全無中心架構(gòu)——計(jì)算模式(Ceph)、安全無中心架構(gòu)——一致性哈希(Swift)等。

本系統(tǒng)存儲(chǔ)采用分布式系統(tǒng)結(jié)構(gòu),實(shí)現(xiàn)多臺(tái)存儲(chǔ)服務(wù)器分擔(dān)存儲(chǔ)負(fù)荷,位置服務(wù)器定位存儲(chǔ)信息的高效方式。其表現(xiàn)如下:

(1)支持自動(dòng)的分級(jí)存儲(chǔ)有效管理讀緩存和寫緩存機(jī)制。在管理讀緩存中,通過將熱點(diǎn)區(qū)域數(shù)據(jù)映射到高速存儲(chǔ)中實(shí)現(xiàn)提升系統(tǒng)響應(yīng)速度操作,并且在發(fā)現(xiàn)熱點(diǎn)區(qū)域有變化時(shí)就將其移出高速存儲(chǔ)以保證性能;在管理寫緩存中,先將數(shù)據(jù)寫入高速存儲(chǔ),在合適的時(shí)間點(diǎn)自動(dòng)進(jìn)行同步落盤操作。

(2)松耦合的網(wǎng)絡(luò)架構(gòu)機(jī)制。高速、低速存儲(chǔ)分開部署或任意比例混合存儲(chǔ);在敏捷開發(fā)或不可預(yù)測(cè)的業(yè)務(wù)環(huán)境情況下,可以盡可能發(fā)揮分層存儲(chǔ)的優(yōu)勢(shì)。

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

(4)數(shù)據(jù)容災(zāi)備份機(jī)制。為了實(shí)現(xiàn)生產(chǎn)系統(tǒng)各版本數(shù)據(jù)的有效保存,使用了多時(shí)間點(diǎn)快照技術(shù);這種方式還支持同時(shí)提取多個(gè)時(shí)間點(diǎn)樣本同時(shí)恢復(fù),有效保證多個(gè)邏輯錯(cuò)誤災(zāi)難的定位。

(5)彈性擴(kuò)展機(jī)制。為了避免單點(diǎn)過熱,將舊數(shù)據(jù)自動(dòng)遷移至新節(jié)點(diǎn)實(shí)現(xiàn)負(fù)載均衡;添加新節(jié)點(diǎn)后集群系統(tǒng)的整體容量和性能將實(shí)現(xiàn)線性擴(kuò)展,這種方式實(shí)現(xiàn)簡(jiǎn)單,只需將新節(jié)點(diǎn)和原有集群連接到同一網(wǎng)絡(luò)中即可,整個(gè)過程不會(huì)對(duì)業(yè)務(wù)系統(tǒng)產(chǎn)生不必要的麻煩。

3.3 智能調(diào)度

為了將大量運(yùn)算任務(wù)合理分配至執(zhí)行器執(zhí)行,需要依賴于智能調(diào)度服務(wù)的“智能任務(wù)派發(fā)機(jī)制(根據(jù)在線用戶數(shù)量及任務(wù)數(shù)量等條件分配任務(wù))”。智能調(diào)度服務(wù)負(fù)責(zé)向云端節(jié)點(diǎn)機(jī)分發(fā)任務(wù),用于完成渲染、加載等業(yè)務(wù)需求并通過節(jié)點(diǎn)機(jī)實(shí)際運(yùn)用情況合理分配當(dāng)前資源以提升用戶的使用體驗(yàn)。

3.3.1 模塊

調(diào)度中心:負(fù)責(zé)管理調(diào)度信息,根據(jù)后臺(tái)配置設(shè)定選擇適合當(dāng)前使用的調(diào)度策略,完成對(duì)用戶任務(wù)的分配與監(jiān)控各執(zhí)行器的運(yùn)行狀態(tài)與數(shù)據(jù)統(tǒng)計(jì)。

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

3.3.2 架構(gòu)圖

調(diào)度服務(wù)運(yùn)行著一個(gè)節(jié)點(diǎn)管理程序,所有系統(tǒng)內(nèi)運(yùn)行正常的節(jié)點(diǎn)機(jī)都會(huì)注冊(cè)在內(nèi),并且實(shí)時(shí)監(jiān)控節(jié)點(diǎn)機(jī)的運(yùn)行狀態(tài)及“健康”狀況。當(dāng)業(yè)務(wù)端發(fā)來任務(wù)時(shí),調(diào)度中心會(huì)根據(jù)當(dāng)前的用戶數(shù)量、任務(wù)數(shù)量及可用節(jié)點(diǎn)機(jī)數(shù)量分配任務(wù)。執(zhí)行器運(yùn)行結(jié)束后會(huì)將結(jié)果返回至調(diào)度中心,調(diào)度中心則通知業(yè)務(wù)端進(jìn)行后續(xù)處理。

圖7 智能調(diào)度架構(gòu)圖

3.4 虛幻引擎

本文中的實(shí)時(shí)渲染將基于UE4做重點(diǎn)技術(shù)分析。UE4中包括的著色器、半透明物體、動(dòng)態(tài)陰影、材質(zhì)等幾項(xiàng)配置是影響渲染的主要因素,以下為系統(tǒng)重點(diǎn)優(yōu)化的配置選項(xiàng):

3.4.1 渲染幾何體

首先確認(rèn)需渲染物體的順序,渲染時(shí)會(huì)對(duì)每一個(gè)材質(zhì)進(jìn)行一次draw call操作。然后通過stat RHI可以查看draw call信息。若draw call信息超過10000次會(huì)對(duì)性能產(chǎn)生嚴(yán)重影響,如考慮用于手機(jī)游戲和vr設(shè)備端,可控制1500次左右的調(diào)用即可。大量頂點(diǎn)的運(yùn)動(dòng),建議將其移動(dòng)到頂點(diǎn)著色器中實(shí)現(xiàn)。

3.4.2 材質(zhì)

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

3.4.3 反射

UE4中有三種不同的反射系統(tǒng) 。通常將三種反射混合使用,且每出現(xiàn)一次反射就會(huì)重新渲染一次屏幕。

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

(2)反射捕捉Actor:反射捕捉Actor是精心放置在關(guān)卡各處的Object,它將反向數(shù)據(jù)饋送到反射環(huán)境中。當(dāng)前有兩個(gè)反射采集形狀:球體和盒體。形狀十分重要,因?yàn)樗刂浦鴪?chǎng)景的哪個(gè)部分將被采集到立方體貼圖中、反射中關(guān)卡被重新投射到什么形狀上,以及關(guān)卡的哪個(gè)部分可以接收來自該立方體貼圖的反射(影響區(qū)域)。

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

3.4.4 G緩存和光柵化

因?yàn)楫?dāng)物體相對(duì)主視角越遠(yuǎn),它所覆蓋的像素越少,所以應(yīng)該減少物體的面數(shù)來減少著色器的運(yùn)算量。此項(xiàng)在UE5中可能會(huì)有所優(yōu)化。

3.4.5 靜態(tài)光照系統(tǒng)

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

3.4.6 動(dòng)態(tài)光照系統(tǒng)

動(dòng)態(tài)光照使用G-buffer來實(shí)現(xiàn)實(shí)時(shí)渲染,可以隨時(shí)進(jìn)行各參數(shù)修改,但陰影對(duì)性能影響很大,不會(huì)產(chǎn)生軟陰影與產(chǎn)生全局光照。

3.4.7 霧和透明度

UE4中有兩種類型的距離霧:大氣霧和指數(shù)霧,距離霧指霧會(huì)隨距離而衰減。大氣霧性能相對(duì)優(yōu)秀,指數(shù)霧則效果相對(duì)突出。

4 系統(tǒng)組成服務(wù)/搭建

系統(tǒng)總體架構(gòu)如圖8所示。

圖8 四維智能分布式遠(yuǎn)程實(shí)時(shí)渲染模型

4.1 用戶端

用戶將服務(wù)插件集成于軟件(UE4等)中,賦予其權(quán)限后可快捷地將本地項(xiàng)目相關(guān)文件同步到云端(手動(dòng)/自動(dòng)), 在云端完成計(jì)算后,根據(jù)用戶業(yè)務(wù)實(shí)時(shí)顯示于WEB或下載到本地。

4.2 云端

運(yùn)算用戶端交互數(shù)據(jù)、提供WEB實(shí)時(shí)渲染服務(wù)及項(xiàng)目分支管理。

4.2.1 WEB服務(wù)器

為用戶在線實(shí)時(shí)渲染提供WEB端操作/顯示渲染結(jié)果以及提供“時(shí)間可視化”項(xiàng)目存儲(chǔ)管理服務(wù)的訪問。

4.2.2 傳輸服務(wù)

傳輸服務(wù)作為用戶端與云端重要的服務(wù)之一,其性能會(huì)影響到云端服務(wù)響應(yīng)速度,調(diào)用傳輸服務(wù)方式分為軟件內(nèi)置插件調(diào)用與WEB端調(diào)用。傳輸技術(shù)詳情查看3.1。

4.2.3 “時(shí)間可視化”項(xiàng)目存儲(chǔ)管理服務(wù)

項(xiàng)目分支管理系統(tǒng),模式分為兩種:

(1)主動(dòng)管理:用戶可主動(dòng)將工程項(xiàng)目上載至服務(wù)器,服務(wù)器保留各個(gè)時(shí)間段用戶上載的不同項(xiàng)目版本,用戶借此可達(dá)成多地協(xié)同開發(fā)或回退版本及分支開發(fā)測(cè)試、快捷在線渲染等。

(2)被動(dòng)管理:本服務(wù)建立在用戶軟件內(nèi)集成云端插件為前提,系統(tǒng)自動(dòng)將項(xiàng)目同步到云端進(jìn)行管理并自動(dòng)生成以關(guān)鍵時(shí)間為節(jié)點(diǎn)的多版本項(xiàng)目,用戶可用此功能進(jìn)行項(xiàng)目恢復(fù)、協(xié)同開發(fā)或快速渲染等。但此功能項(xiàng)目文件將只存儲(chǔ)近7天內(nèi)容。用戶可選擇關(guān)閉“被動(dòng)管理功能”。

5 總結(jié)

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