李 楊 邵先杰 李琳娜

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

1 引言

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

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

與傳統(tǒng)意義上的實時渲染概念不同,本文提出的四維智能分布式遠(yuǎn)程實時渲染是用戶端通過傳輸插件與服務(wù)端建立實時的數(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)為時間軸的“第四維度”檔案,用戶可以此回檔到以前的任意節(jié)點(diǎn)或建立新的分支。本系統(tǒng)核心思想為:用戶以鏈接云端的方式,依托云端服務(wù)器集群,獲得高效、實時穩(wěn)定及安全的開發(fā)體驗。因其大部分計算都集成在云端,從而大大降低對本地硬件的配置要求,降低了開發(fā)成本。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖6 四維項目存儲管理

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

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

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

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

3.1 傳輸技術(shù)

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

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

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

3.2 分布式存儲

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

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

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

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

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

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

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

(5)彈性擴(kuò)展機(jī)制。為了避免單點(diǎn)過熱,將舊數(shù)據(jù)自動遷移至新節(jié)點(diǎn)實現(xiàn)負(fù)載均衡;添加新節(jié)點(diǎn)后集群系統(tǒng)的整體容量和性能將實現(xiàn)線性擴(kuò)展,這種方式實現(xiàn)簡單,只需將新節(jié)點(diǎn)和原有集群連接到同一網(wǎng)絡(luò)中即可,整個過程不會對業(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ī)實際運(yùn)用情況合理分配當(dāng)前資源以提升用戶的使用體驗。

3.3.1 模塊

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

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

3.3.2 架構(gòu)圖

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

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

3.4 虛幻引擎

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

3.4.1 渲染幾何體

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

3.4.2 材質(zhì)

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

3.4.3 反射

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

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

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

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

3.4.4 G緩存和光柵化

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

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

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

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

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

3.4.7 霧和透明度

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

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

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

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

4.1 用戶端

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

4.2 云端

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

4.2.1 WEB服務(wù)器

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

4.2.2 傳輸服務(wù)

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

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

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

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

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

5 總結(jié)

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