移動(dòng)端也能使用UnityHDRP？中手游《仙劍世界》實(shí)現(xiàn)了開(kāi)放世界手游技術(shù)革新
近年來(lái)，移動(dòng)用U游仙游技游戲行業(yè)開(kāi)放世界賽道火熱，端也但是中手跨平臺(tái)體驗(yàn)一直是業(yè)界的難題。最近幾款備受期待的劍世界實(shí)界手開(kāi)放世界大作移動(dòng)端接連翻車，要么出現(xiàn)跳票延期的現(xiàn)開(kāi)新情況，令眾多玩家感到失望。放世
但在前陣子的術(shù)革UniteShanghai2024上，來(lái)自中手游的移動(dòng)用U游仙游技仙劍IP首款開(kāi)放世界RPG《仙劍世界》帶來(lái)了開(kāi)放世界跨平臺(tái)優(yōu)化的技術(shù)分享，在大會(huì)上介紹了許多項(xiàng)目曾經(jīng)走過(guò)的端也彎路，以及對(duì)應(yīng)解決的中手經(jīng)驗(yàn)技巧。
以下是劍世界實(shí)界手Untiy中國(guó)對(duì)《仙劍世界》主創(chuàng)團(tuán)隊(duì)的采訪原文，內(nèi)容干貨十足，現(xiàn)開(kāi)新值得全文閱讀。放世
《仙劍世界》作為仙劍 IP系列的術(shù)革最新?篇?作，從故事和劇情上延續(xù)了仙劍的移動(dòng)用U游仙游技精髓。在仙劍33年的世界觀下，游戲打造出了?個(gè)浪漫唯美的江南全景、磅礴恢弘的蜀?、神秘苗疆等區(qū)域，構(gòu)成?個(gè)384平?公?完整的?縫開(kāi)放?世界。以東?題材為起點(diǎn)，以江南的浪漫為開(kāi)端，以巴蜀的幻想?格作為延續(xù)，通過(guò)不斷的迭代和內(nèi)容更新，為秈?們奉上?款難以忘懷的仙俠?作。
Unity中國(guó)有幸采訪到了主創(chuàng)團(tuán)隊(duì)，并邀請(qǐng)他們參加了Unite上海2024，與開(kāi)發(fā)者們面對(duì)面交流。
可以為我們簡(jiǎn)哪個(gè)單介紹下團(tuán)隊(duì)和項(xiàng)?嗎？
?家好，我們是中?游旗下的滿天星?作室，核?成員為原巨??絡(luò)巨??作室原班團(tuán)隊(duì)，參與 過(guò)《征途》瑞游研發(fā)，主導(dǎo)了《巨?》端游，《仙俠世界》系列端游和《?珠最強(qiáng)之戰(zhàn)》?游的研 發(fā)。?前我們正在開(kāi)發(fā)的《仙劍世界》，是中?游?研?發(fā)的仙劍 IP?款開(kāi)放世界RPG，游戲致?于在多端平臺(tái)打造?個(gè)萬(wàn)物有靈的東?浪漫幻想世界。
但在項(xiàng)?研發(fā)早期，由于場(chǎng)景龐?，對(duì)視野要求也很?，我們?度糾結(jié)如何能在有限的時(shí)間內(nèi)整 合各類效果好的 feature，管理開(kāi)銷。所幸有UnityHDRP 管線，得益于它的特性，最終幫助我們實(shí)現(xiàn)了對(duì)游戲世界的暢想，充分展現(xiàn)出東?浪漫幻想世界的魅?。
HDRP相對(duì)于URP，給《仙劍世界》帶來(lái)了什么好處？
URP確實(shí)是一個(gè)非常簡(jiǎn)潔靈活的渲染管線，但是當(dāng)我們需要制作一款在PC體驗(yàn)的大世界游戲的時(shí)候，URP就會(huì)有一些稍顯不足的地方。特別是我們當(dāng)時(shí)使用的是Unity2021，URP在原生支持的feature上略微少一些。反之，HDRP管線則為我們內(nèi)置了大量非常實(shí)用，且效果很好的feature，確實(shí)為我們?cè)陧?xiàng)目初期，提供了快速，穩(wěn)定，優(yōu)質(zhì)的畫面效果提升。
Unite大會(huì)上《仙劍世界》HDRPFeature展示
例如，HDRP下內(nèi)置的SSGI，在我們自己的PRTGI方案還未落地時(shí)，為游戲提供了很好的GI畫面支持。SSS也為角色皮膚提供了非常好的質(zhì)感，讓角色變得更加真實(shí)自然，比項(xiàng)目早期使用預(yù)積分Lut的皮膚SSS方案要更加潤(rùn)澤和透亮，總體來(lái)說(shuō)更符合我們游戲中國(guó)風(fēng)人物的皮膚質(zhì)感。Tile/Cluster的點(diǎn)光解決方案，也讓場(chǎng)景燈光師可以肆意擺放燈光，為副本、夜晚提供很棒的氛圍和質(zhì)感。另外對(duì)于實(shí)時(shí)天氣和日月變化，當(dāng)時(shí)HDRP下提供的Volume體系也可以實(shí)現(xiàn)非常炫酷的效果，甚至提供管線的管理和混合效果。又比如，我們劇情導(dǎo)演希望引擎這邊能提供一個(gè)比較高質(zhì)量基于物理的DOF（景深）效果，那HDRP下的DOF就是一個(gè)很好的選擇，它基于物理相機(jī)的整套參數(shù)調(diào)整，可以讓我們的劇情導(dǎo)演非常容易的上手和理解。
HDRPSSAO遮蔽效果展示
在研發(fā)早期，人力相對(duì)比較緊張，但又正是項(xiàng)目確立游戲風(fēng)格效果、質(zhì)量體系等標(biāo)準(zhǔn)的時(shí)候，HDRP相比于URP會(huì)更加適合我們，因此我們也非常堅(jiān)定的選擇了HDRP管線作為我們的渲染管線。從最終結(jié)果上看，它也為我們節(jié)約了不少預(yù)研時(shí)間，加快了開(kāi)發(fā)進(jìn)度。當(dāng)我們想要嘗試某些效果，幾乎只需要在管線設(shè)置上打開(kāi)相應(yīng)開(kāi)關(guān)，即可看到它帶來(lái)的畫面變化，非常的方便。
HDRPPCSS軟陰影效果展示
從 PC端移植到移動(dòng)端?概花了多久？移植過(guò)程中遇到的最?的困難是什么？
在最開(kāi)始的時(shí)候，項(xiàng)?是基于 URP管線的，但是由于PC端?漸新增的畫?提升需求，我們加?了HDRP來(lái)作為PC端的管線。也就是說(shuō)這個(gè)時(shí)期，我們確實(shí)是URP和HDRP同時(shí)運(yùn)?的。
之所以選擇同時(shí)進(jìn)?，是因?yàn)?nbsp;HDRP原?不?持移動(dòng)平臺(tái)，放眼全球?業(yè)，也鮮有其他游戲?qū)DRP進(jìn)?移植的案例。所以我們?開(kāi)始對(duì)它報(bào)以謹(jǐn)慎的態(tài)度，對(duì)HDRP管線技術(shù)不斷地進(jìn)?學(xué)習(xí)和整合。但是隨著對(duì)HDRP使?的深?，我們了解了它的各種特性和優(yōu)點(diǎn)之后，出于對(duì)引擎維護(hù)和資產(chǎn)流程管理成本的考慮；也因?yàn)槲覀儓F(tuán)隊(duì)相對(duì)有?較成熟的PC和移動(dòng)平臺(tái)的開(kāi)發(fā)移植經(jīng)驗(yàn)，對(duì)??的技術(shù)實(shí)?也很有信?。所以經(jīng)過(guò)評(píng)估之后，我們決定將HDRP向移動(dòng)平臺(tái)進(jìn)?移植。?此，我們游戲就只有HDRP?套渲染管線了。
Unite大會(huì)上《仙劍世界》HDRP跨平臺(tái)優(yōu)化技術(shù)分享
在開(kāi)始移植之前，我們預(yù)留了約一個(gè)月左右的時(shí)間作為移植的緩沖時(shí)間，以防止遇到難以解決的突發(fā)問(wèn)題。另外，我們提前評(píng)估了所有PC上我們正在使用的，甚至還未使用，但是很可能會(huì)用到的HDRP下所有feature，它們?cè)谝苿?dòng)端上可能的性能表現(xiàn)，用于確定是否能在移動(dòng)平臺(tái)保留或簡(jiǎn)化這些feature。我們經(jīng)過(guò)多次會(huì)議和討論，確定了大體的移動(dòng)端管線結(jié)構(gòu)和流程，以及對(duì)應(yīng)的RT的格式和尺寸。然后就是通過(guò)平臺(tái)宏控制，將移動(dòng)平臺(tái)下預(yù)期不佳的功能，從管線和Shader上先進(jìn)行了屏蔽，渲染管線也進(jìn)行了重新設(shè)計(jì)，以適配移動(dòng)平臺(tái)的帶寬壓力。在完成這些整理之后，我們才開(kāi)始正式移植到移動(dòng)真機(jī)上的。整個(gè)移植過(guò)程非常非常順利。由于絕大部分的問(wèn)題在上真機(jī)之前就已經(jīng)預(yù)料和屏蔽了，因此幾乎沒(méi)有遇到什么困難就可以在移動(dòng)平臺(tái)的高端設(shè)備上跑起來(lái)。
Opaque的ColorBuffer的load是不必要的
只是真正的難關(guān)，是在跑起來(lái)之后。
在HDRP移植到真機(jī)之后，我們發(fā)現(xiàn)其運(yùn)行性能實(shí)在不是很好，大約可能只有10+、20+的FPS。這個(gè)離我們的預(yù)期太遠(yuǎn)了，所以我們開(kāi)始Profiler真機(jī)看看問(wèn)題都出在哪里。
主要的問(wèn)題就是在Shader上面。HDRP的標(biāo)準(zhǔn)LitShander在移動(dòng)平臺(tái)下編譯出來(lái)數(shù)千行還帶有循環(huán)的指令，實(shí)在是讓移動(dòng)平臺(tái)的GPU難以應(yīng)對(duì)。因此我們開(kāi)啟了大規(guī)模的Shader的整理和簡(jiǎn)化工作。整個(gè)優(yōu)化流程進(jìn)行了很多輪，時(shí)至今日，我們?nèi)匀贿€在持續(xù)為Shader進(jìn)行移動(dòng)端的優(yōu)化。但是在初期一兩次核心整理之后，F(xiàn)PS就有了大幅提升。主要的優(yōu)化方向有，去掉復(fù)雜的，很多次循環(huán)迭代的某些算法（如陰影，環(huán)境高光等），改用適合移動(dòng)端的輕量級(jí)算法。另外光柵化數(shù)據(jù)的結(jié)構(gòu)整理，也很有必要。去掉各種不必要的feature的分支。因?yàn)槲覀円呀?jīng)熟悉了解了自己項(xiàng)目的需求，因此不必保留這些Shader里面可能的分支流程。最后，由于HDRP原本并不是為移動(dòng)平臺(tái)設(shè)計(jì)的，因此會(huì)存在大量的動(dòng)態(tài)索引設(shè)計(jì)。動(dòng)態(tài)索引確實(shí)在設(shè)計(jì)的靈活性上非常方便，但是這會(huì)使得buffer的訪問(wèn)速度，甚至大量中間變量的計(jì)算速度變得很慢。因此去除主方向光、陰影等等渲染輸入數(shù)據(jù)的List結(jié)構(gòu)，使其變成可以通過(guò)靜態(tài)偏移的方式去訪問(wèn)。使得Shader代碼從行數(shù)，寄存器訪問(wèn)速度，甚至CPU數(shù)據(jù)填充方面都有很大的性能提升。
在移動(dòng)端開(kāi)發(fā)的過(guò)程中，我們也深刻地認(rèn)識(shí)到——移動(dòng)平臺(tái)的優(yōu)化是需要持續(xù)進(jìn)行的，即使到了項(xiàng)目開(kāi)發(fā)的中后期，也應(yīng)該對(duì)移動(dòng)端性能的保持關(guān)注和維護(hù)。過(guò)程雖然會(huì)有困難和卡點(diǎn)，但是優(yōu)化過(guò)后的效果總能讓移動(dòng)端的表現(xiàn)更上一層樓。
PC端的資源?產(chǎn)?作流和移動(dòng)端是怎么平衡和配合的？
我們是以 PC為基礎(chǔ)?產(chǎn)模型資源的，在技術(shù)給定的規(guī)格框架內(nèi)，保證基本效果的情況下向移動(dòng)端過(guò)渡。這個(gè)過(guò)度包括模型的?數(shù)，貼圖材質(zhì)的處理，LOD的處理和銜接，以及技術(shù)Shader上的調(diào)整。兩者之間有共?和繼承關(guān)系，也有完全獨(dú)?的部分。?如PC的最后?級(jí)LOD是移動(dòng)端的第?級(jí)。當(dāng)然，移動(dòng)端因?yàn)榧骖櫺阅芎托Ч麊?wèn)題，我們也會(huì)對(duì)?些模型進(jìn)?單獨(dú)制作和調(diào)整。這個(gè)調(diào)整也是在PC資產(chǎn)的基礎(chǔ)上去想辦法，這樣才能保證PC和移動(dòng)端的效果統(tǒng)?。
游戲場(chǎng)景及規(guī)模都很?，資源和渲染管理??做了哪些特殊的設(shè)計(jì)嗎?
仙劍世界的地圖面積高達(dá)384平方公里，涵蓋多樣化的地形地貌、人文景觀和精怪生態(tài)。其中所涉及的資源種類和數(shù)量非常龐大，我們?cè)趯ふ议_(kāi)發(fā)效率、包體大小、更新效率、性能優(yōu)化和游戲品質(zhì)之間的平衡點(diǎn)時(shí)，遇到了極大的挑戰(zhàn)。通過(guò)項(xiàng)目前期的不斷打磨和調(diào)整，我們最終探索出了一整套的涵蓋資源制作、場(chǎng)景編輯等上下游的規(guī)范、流程和工具鏈。
首先是為不同平臺(tái)制定不同的美術(shù)資源標(biāo)準(zhǔn)，確定每個(gè)平臺(tái)的資源制作規(guī)格、命名規(guī)范和品質(zhì)標(biāo)桿。
其次我們將場(chǎng)景物件按“花草樹(shù)木山石湖河器物”等進(jìn)行細(xì)分，為每個(gè)類別制定專門的場(chǎng)景擺放規(guī)則。通過(guò)資源代理機(jī)制，地編只需制作一份場(chǎng)景，我們可以針對(duì)不同平臺(tái)進(jìn)行細(xì)節(jié)控制，在不影響功能性和品質(zhì)的前提下適配平臺(tái)特性。
《仙劍世界》場(chǎng)景地編
在打磨和調(diào)整過(guò)程中，我們逐步完善了工具鏈，以標(biāo)準(zhǔn)、自動(dòng)、可視、高效為原則，助力各個(gè)生產(chǎn)環(huán)節(jié)，提供效率，保障品質(zhì)。
再次，我們引入了Unity新一代資源構(gòu)建管線SBP，其靈活、可定制、高效的特性，使我們可以從容管理數(shù)十萬(wàn)且還在不斷增長(zhǎng)的資產(chǎn)，隨心控制打包粒度，縮減CICD的時(shí)長(zhǎng)。
最后，我們通過(guò)對(duì)Unity引擎的深度定制化，讓游戲可以承載更豐富的細(xì)節(jié)，容納更多的玩法，體現(xiàn)更高的畫面品質(zhì)。
在渲染方面，我們除了在近景使用了HIS系統(tǒng)進(jìn)行大規(guī)模合批（在Unite大會(huì)詳細(xì)分享過(guò)這個(gè)技術(shù)，它主要針對(duì)材質(zhì)相同，mesh相同，但是數(shù)量非常龐大的組件式的model類型），還利用Unity的BatchRendererGroup來(lái)針對(duì)mesh、材質(zhì)重疊度不高，數(shù)量不大，但是種類很多的靜態(tài)非組件式物件進(jìn)行合批操作。這樣我們近景對(duì)象的DrawCall問(wèn)題就得到了很好的解決。
通過(guò)HIS進(jìn)行場(chǎng)景管理，同樣的場(chǎng)景FPS可以達(dá)到230以上，性能增加了15倍
未來(lái)的上線計(jì)劃能和我們透露嗎？
在前段時(shí)間結(jié)束的多端付費(fèi)刪檔測(cè)試中，?些 HDRP在各個(gè)?機(jī)型號(hào)上的適配效果也得到了初步驗(yàn)證。雖然?前還沒(méi)達(dá)到最佳理想的狀態(tài)，但是從團(tuán)隊(duì)優(yōu)化效果的軌跡來(lái)看，對(duì)于HDRP移動(dòng)端的移植還是保持著樂(lè)觀的預(yù)期。
同時(shí)，?論是 PC端還是移動(dòng)端平臺(tái)，我們都希望游戲給玩家?guī)?lái)更好的感受。最近也是再度開(kāi)啟了?范圍的共研服測(cè)試，針對(duì)畫?、玩法、體驗(yàn)等不同層?進(jìn)?優(yōu)化和迭代。例如針對(duì)我們核?“萬(wàn)物有靈”的玩法，新增多御靈助戰(zhàn)、注靈探索、御靈仙術(shù)、御靈派遣等豐富內(nèi)容；針對(duì)“五靈?克”戰(zhàn)?機(jī)制，優(yōu)化戰(zhàn)?效果與玩法策略；針對(duì)游戲基礎(chǔ)體驗(yàn)，優(yōu)化UI表現(xiàn)和戰(zhàn)??感等等。后續(xù)將會(huì)有更好的效果表現(xiàn)呈現(xiàn)給?家，也可以期待?下。
采訪還附上了 U3D引擎開(kāi)發(fā)工程師何姝姝，在UniteShanghai 2024 上的分享《<仙劍世界>: HDRP 管線下的超大世界游戲與跨平臺(tái)優(yōu)化》演講全文。
大家好，我叫何姝姝，來(lái)自上海凡影滿天星工作室，我們最近開(kāi)發(fā)了一款名叫《仙劍世界》的開(kāi)放世界游戲，很高興今天有機(jī)會(huì)跟大家分享我們?cè)凇断蓜κ澜纭愤@款游戲中所遇到的技術(shù)方面的經(jīng)驗(yàn)和數(shù)據(jù)。
立項(xiàng)的時(shí)候，我們計(jì)劃制作一款大世界游戲，它可以上天入地、自由飛翔，它有什么特點(diǎn)呢？它非常的大，它是一個(gè)開(kāi)放性地圖，地圖直徑有 24公里，總規(guī)模達(dá)到384平方公里，全場(chǎng)景自由探索，并且完全沒(méi)有l(wèi)oading條，我們支持PC、iOS和安卓，可能還會(huì)有其他平臺(tái)后續(xù)的支持計(jì)劃。在PC上，我們要求很高的質(zhì)量，并且移動(dòng)平臺(tái)我們要求非常流暢。
《仙劍世界》御劍飛行效果展示
我們項(xiàng)目早期是 URP管線，優(yōu)點(diǎn)是簡(jiǎn)潔、靈活、代碼總量小、便于維護(hù)，控制它的成本比較小，但這也是它的缺點(diǎn)，它實(shí)在太簡(jiǎn)單了，缺少大項(xiàng)目需要很多feature。當(dāng)時(shí)我們有兩個(gè)選擇，一個(gè)是自己造輪子，進(jìn)度和計(jì)劃不是很允許。另外是尋找各種feature的package，把它們整合到一起，但是整合成本也很高，可能會(huì)有很多bug。總的來(lái)說(shuō)，我們當(dāng)時(shí)的訴求是快速、好看、靈活、效果豐富和穩(wěn)定。
我們當(dāng)時(shí)比較重視曾經(jīng)使用了/或者還在使用的效果feature，包括SSS、Tile/Cluster的精確光系統(tǒng)、volume級(jí)別的環(huán)境效果、管線管理，SSAO，基于物理的光照單位（lux、lumen等），物理的光照、大氣，更加完善的PBR著色，基于探針的環(huán)境GI、SSGI等全局光照體系，PCF和PCSS的陰影體系，后處理中比較方便的如DOF、運(yùn)動(dòng)模糊等效果體系，以及TAA、DLSS等抗噪體系，更完善的ColorGrading和Tonemaping等畫面風(fēng)格化處理，最后是極度便捷好用的RenderingDebug系統(tǒng)。
我這里給大家直接在游戲內(nèi)截的圖，比較真實(shí)的反饋了 SSS帶來(lái)的皮膚效果。與選人或者抽卡等這種影棚燈光效果不同，大世界游戲場(chǎng)景的燈光會(huì)相對(duì)比較簡(jiǎn)單，這樣更能給大家?guī)?lái)直觀的SSS效果體驗(yàn)。我們這里看到,即使是從月光照射下，甚至在陰影下,SSS 都給角色皮膚帶來(lái)了較為清透的質(zhì)感效果。
SSAO也是游戲中比較重要的效果，左下圖是SSAO貼圖，左上是關(guān)閉了SSAO的效果，右下是開(kāi)啟SSAO的效果。開(kāi)啟SSAO之后，屋檐下的遮蔽更加明顯，建筑和畫面也因此變得更加立體和扎實(shí)。
在后面這組畫面中，建筑基本位于陰影之下，SSGI沒(méi)有開(kāi)啟之前，屋檐內(nèi)部光照缺乏層次細(xì)節(jié)，黑糊糊一團(tuán)，使用了SSGI之后，不僅外部柱子因?yàn)檎诒螠p少，亮度提升，夾縫中的屋檐也因?yàn)榉磸椆獗徽樟亮?，并且屋檐下每個(gè)橫梁、每個(gè)面都受到了不同GI的效果，畫面也豐富了很多。
得益于 HDRP便捷的Volume系統(tǒng)，我們可以方便快捷的實(shí)現(xiàn)日月變化和動(dòng)態(tài)天氣效果。
PCSS也是HDRP的一個(gè)特色feature，它可以為我們實(shí)現(xiàn)比較高質(zhì)量的軟陰影效果，大家可以看到樹(shù)葉打到柱子、樹(shù)葉、地面，墻壁上的陰影呈現(xiàn)不同程度的soft效果，比較柔和自然。
這里我想給大家重點(diǎn)推薦一下 DLSS，在關(guān)閉DLSS畫面的竹葉噪點(diǎn)很多，也比較閃爍，開(kāi)啟DLSS的那一剎那，畫面得到了非常大的提升，沒(méi)有噪點(diǎn)，更加穩(wěn)定，甚至樹(shù)葉形態(tài)都更加清晰了。DLSS確實(shí)是非常重要的提升效果的feature。
我們后來(lái)接入 HDRP之后遇到了一些問(wèn)題，首當(dāng)其沖的就是Shader，HDRP的Shader是基于Uber方式進(jìn)行管理的，它提供了非常多便捷的feature支持，HDRP開(kāi)發(fā)者將眾多大型游戲中或者其他工業(yè)渲染中可能會(huì)運(yùn)用到的各種功能濃縮到一套UberShader 下，這樣做的好處非常明顯，它可以在早期開(kāi)發(fā)時(shí)期以很低廉的學(xué)習(xí)成本，直接運(yùn)用和控制這些feature。比如所有的Lit shader可以輕易切換成更適合自己的游戲算法。中后期，Uber為我們帶來(lái)了很多問(wèn)題，比如它的代碼量實(shí)在太大了，所以閱讀起來(lái)非常耗時(shí)。其次它的編譯太慢了，初期可能改一個(gè)底層的Lightloop文件需要編譯20分鐘時(shí)間，簡(jiǎn)直難以讓人忍受。最后，代碼或者keyword和分支過(guò)多之后，整個(gè)shader所占用的總內(nèi)存就會(huì)變得很龐大，達(dá)到數(shù)百M(fèi)以上。
這三點(diǎn)每一點(diǎn)都很痛。好在后面我們都摸索出了一些解決方案。
首先，我們?nèi)匀皇墙ㄗh，在 HDRP下，盡可能的使用Uber的方式進(jìn)行shader管理HDRP的feature過(guò)多，渲染代碼量非常大，且分支過(guò)多，因此一定要注意維持shader以及keyword的數(shù)量，keyword的新增是申請(qǐng)制，去掉一切不會(huì)使用到的feature。采用靜態(tài)keyword去替代掉動(dòng)態(tài)keyword。
第二，減少 if分支的使用。去掉不用的if分支。HDRP因?yàn)榉种н^(guò)多，會(huì)導(dǎo)致編譯器無(wú)法合并，位于不同分支內(nèi)的相同運(yùn)算過(guò)程，這將使代碼復(fù)雜度、運(yùn)算量大大增加。
第三，盡量嚴(yán)格統(tǒng)一底層，使用相同的 Lit和LightLoop等底層光照文件，便于后期統(tǒng)一優(yōu)化，因?yàn)槲覀円欢ㄐ枰獌?yōu)化。效果沒(méi)有確定下來(lái)之前，建議使用ShaderGraph 來(lái)探索渲染效果，建議花費(fèi)一些時(shí)間修改ShaderGraph的package中源碼，增加其ShaderGraph 轉(zhuǎn)成CodeShader后的代碼可讀性和維護(hù)性，否則轉(zhuǎn)出來(lái)的代碼太長(zhǎng)了，實(shí)在沒(méi)有什么可讀性，優(yōu)化起來(lái)也不是很方便。
第二個(gè)問(wèn)題是 Volume的更新，因?yàn)橛袑?shí)時(shí)日月天氣的變化，依賴Volume以后，可以很輕松實(shí)現(xiàn)。從右圖可以看到，一個(gè)環(huán)境配置可能包括有數(shù)十個(gè)不同的組件，包括Unity自帶的組件和我們自己實(shí)現(xiàn)得功能等，但是每個(gè)組件又帶有數(shù)十個(gè)變量，會(huì)造成刷新性能不好的結(jié)果。因此，我們的優(yōu)化方向是需要嚴(yán)格控制刷新頻率，比如沒(méi)有變化的時(shí)候不刷新、不需要刷新的變量也不刷新，這部分的優(yōu)化是必不可少的大家可以根據(jù)自己的項(xiàng)目情況進(jìn)行極限壓縮，主要是為了減少刷新的計(jì)算量。
控制好 Volume體系開(kāi)銷之后，我們發(fā)現(xiàn)RenderGraph 管線開(kāi)銷也很大。首先HDRP管線，我來(lái)給大家梳理一下它的大體工作流程：
他們大部分都需 newRendererListDesc() 函數(shù)，這就需要引擎層為這些所有的pass，執(zhí)行SRPBatcher工作。Unity引擎底層會(huì)將這些，通過(guò)了Filter裁剪器之后的Renderer，pack成RenderNode，然后把他們分發(fā)到多個(gè)Job線程，去整合他們的材質(zhì)，變量，區(qū)分每一個(gè)變量是否是Global的，如果是，還要把變量從Global區(qū)域copy出來(lái)，填充形成自己這個(gè)Drawcall的cbuffer。另外還有每個(gè)需要裁剪的Camera，還需要對(duì)所有RenderNode進(jìn)行裁剪，還有各種Probe的裁剪，Bound計(jì)算等等。管線的工作成本是非常高的。而且這個(gè)高，是會(huì)隨著相機(jī)數(shù)量成倍數(shù)增長(zhǎng)。即使開(kāi)了Job，并且實(shí)在多線程中完成這些計(jì)算，但是當(dāng)場(chǎng)景中的渲染對(duì)象多到一定程度之后，我們發(fā)現(xiàn)RenderGraph在PC上的成本都是很高的，更何況并行能力更差的移動(dòng)平臺(tái)。有時(shí)候其開(kāi)銷能達(dá)到10ms以上，基本上很難接受。因此我們的優(yōu)化策略是一定要控制住Camera的數(shù)量，絕不額外增加Camera。剩下的相機(jī)，一定增加多種相機(jī)類型，以便于精確控制除了主相機(jī)之外的相機(jī)的渲染流程。例如：UICameraAvatarCamera 等等特殊相機(jī)類型。
如果要?jiǎng)討B(tài)改變環(huán)境，當(dāng)發(fā)生變化的時(shí)候，每個(gè)模塊都需要刷新，這個(gè)時(shí)候就需要對(duì)每個(gè)相機(jī)的每個(gè)管線，進(jìn)行量身定制，以減少除了主相機(jī)之外的所有次要管線內(nèi)非必要計(jì)算：
例如：UpdateEnvironment()（他們包括了SkyBox更新，Convolutionmipmap 的計(jì)算，GI的球諧刷新等等），我們只需要計(jì)算和渲染主相機(jī)那一次，其他情況盡可能復(fù)用。另外，昂貴的PostProcess體系最好只有主相機(jī)有，其他相機(jī)只保留必要的feature即可，能去掉的盡量去掉。最后，GlobalBuffer會(huì)在多條管線中填充多次，很多時(shí)候是可以復(fù)用的，盡量減輕管線的負(fù)擔(dān)，盡量減少非必要填充。
跨過(guò)了 RenderGraph之后，我們遇到了一個(gè)新的問(wèn)題，那就是Batch。首先，我們已經(jīng)定制修改渲染管線了，CPU壓力就解決了嗎？但是別忘了，我們是一個(gè)大世界游戲。
這里我給大家補(bǔ)充一些信息。
第一個(gè)，HDRP和URP同屬于SRP管線，其底層都是具有SRPBatcher 功能的。本來(lái)SRPBatcher 是一個(gè)優(yōu)化游戲性能的東西，為什么到這里，就變成一個(gè)性能瓶頸了呢？因?yàn)榇笫澜绲腞enderer數(shù)量太多了，能達(dá)到30W個(gè)以上，其CPU管理成本非常非常高，所以Batch成本也是很高。
所以我們開(kāi)發(fā)了一套 HIS系統(tǒng)。場(chǎng)景的Renderer太多，動(dòng)態(tài)計(jì)算即使使用Job也很難承擔(dān)SRPBatch 和底層渲染的CPU壓力。那么我們采取的方案是：脫離Renderer對(duì)象管理(Renderer僅用于烘焙場(chǎng)景)——這樣做減少了絕大部分原本SRPBatch 的壓力。
BVHTree場(chǎng)景靜態(tài)烘焙加速場(chǎng)景管理，它可以預(yù)先烘焙記錄材質(zhì)、變量等信息，直接從烘焙結(jié)果中得到Batch結(jié)構(gòu)，不再需要?jiǎng)討B(tài)計(jì)算。適合大量的，相同材質(zhì)Shader的場(chǎng)景組件，可以一次性使用DrawInstanced 繪制成百上千的對(duì)象。徹底解決SRPBatcher 合批之后，仍然會(huì)有多個(gè)DrawcallSet的問(wèn)題。得益于這個(gè)系統(tǒng)，我們可以發(fā)現(xiàn)，大量相同的場(chǎng)景組件，其Drawcall以及其他渲染狀態(tài)切換均只有一次。GPU壓力也因此得到降低。
我們可以看到右邊圖片，HIS合并之后，場(chǎng)景中的大量物體都進(jìn)行了Instancing合批繪制，非常高效，最高的有1200多次。
這是 BVHTree 的烘焙結(jié)果，這個(gè)動(dòng)畫展示了4層的BVHTree 的烘焙結(jié)果。當(dāng)我們想要定位攝像機(jī)內(nèi)有哪些渲染對(duì)象的時(shí)候，可以根據(jù)BVHTree 進(jìn)行加速篩選定位。
我們來(lái)看看這個(gè) HIS系統(tǒng)加入前后的性能表現(xiàn)差異，這是以一個(gè)Renderer對(duì)象超過(guò)8W的小型城市建筑群。大家可以通過(guò)右上角的統(tǒng)計(jì)面板看到，SPRBatch 之后只有10個(gè)左右的setpass。但是在我的電腦I7的Cpu上，它僅僅能跑15fps。
我們來(lái)看 Profiler，是什么消耗了CPU性能。通過(guò)Unity的Profiler，我們可以清楚的看到，CPU每幀總開(kāi)銷超過(guò)50ms，其中60%以上來(lái)自SRPBatcher 的開(kāi)銷。當(dāng)開(kāi)啟了HIS之后，我們的FPS可以達(dá)到230以上，整體CPU性能增加了15倍。
在場(chǎng)景的管理解決之后，我們又發(fā)現(xiàn)大世界中的光照也很麻煩，左邊的視頻可以看到，制作人要求我們實(shí)現(xiàn)實(shí)時(shí)日月光照角度變化，同時(shí)又要支持不同的天氣效果切換。右邊的視頻可以看到角色從地面飛行到三百米的高空中，如果使用 Lightmap，可能需要加載很大范圍內(nèi)的貼圖數(shù)據(jù)，并且PC端還被要求實(shí)現(xiàn)一根柱子不同朝向的GI變化，因此傳統(tǒng)的Lightmap很難從內(nèi)存和效果上達(dá)到我們的要求。因此我們采用PRTGI的方式來(lái)實(shí)現(xiàn)實(shí)時(shí)GI。
我們基本上參考了《對(duì)馬島之魂》在 2021的SIGGRAPH上發(fā)表的這篇文章，來(lái)實(shí)現(xiàn)的預(yù)烘焙部分。烘焙主要采用了DX12的光線追蹤算法，來(lái)記錄了以0.5米為單位的LightProbe內(nèi)烘焙信息。具體做法是，烘焙時(shí)通過(guò)構(gòu)建一個(gè)單位亮度為1的白色天空球的反彈信息x實(shí)時(shí)天空盒的0階球諧(天光的反彈)+ 模擬水平面和垂直面的反彈的實(shí)時(shí)主光的反彈球諧（主光反彈）+實(shí)時(shí)天空盒SH，計(jì)算游戲的最終GI。
我們通過(guò)這種預(yù)烘焙和實(shí)時(shí)結(jié)合的方式，獲得了低成本的實(shí)時(shí) GI效果。由于其優(yōu)秀的性能和內(nèi)存表現(xiàn)，這套方案可以完全運(yùn)行到移動(dòng)平臺(tái)上，它的性能開(kāi)銷可以控制在2ms內(nèi)和40m左右。當(dāng)然便捷的操作也是必不可少了。不能讓我們場(chǎng)景美術(shù)手動(dòng)去布置這些探針球，畢竟我們場(chǎng)景很大。因此自適應(yīng)生成系統(tǒng)必不可少。另外特殊的地方可以進(jìn)行人為修正也是可以支持的。
但是我們和大部分的 PRTGI系統(tǒng)一樣，都會(huì)遇到的類似的問(wèn)題，那就是——漏光。我們可以看到，由于漏光，在墻體物件和外界交界的地方，存在大量不均勻的，不穩(wěn)定的遮蔽程度，嚴(yán)重影響效果。
我們采用的方案是借助 Dilation(Post-Bake)和VirtualOffset(Pre-Bake)，我們很好的控制住了漏光現(xiàn)象，獲得了均勻可信的烘焙GI信息，大家可以看同一個(gè)場(chǎng)景，漏光解決后，是不是均勻很多？大家可以參考Unity在SIGGRAPH2022 年發(fā)布的Enemies論文，我在這里就不作過(guò)多的詳述了。
PC平臺(tái)的一些問(wèn)題我們介紹完了，下面著重給大家介紹一下移動(dòng)平臺(tái)。在PC版本逐漸穩(wěn)定了之后，我們開(kāi)啟了對(duì)其進(jìn)行移動(dòng)平臺(tái)的移植。這將是一個(gè)更大的挑戰(zhàn)，因?yàn)槲覀兌贾溃琀DRP原生是不支持移動(dòng)平臺(tái)的，如果我們要做一致，要選擇適合的項(xiàng)目時(shí)機(jī)，我們要預(yù)留比較長(zhǎng)的容錯(cuò)時(shí)間，安排合適的項(xiàng)目進(jìn)度。由于管線的復(fù)雜程度，可能早期8Gen3的手機(jī)上只有10FP，但一定要有堅(jiān)定的信心。
移植前需要做一些什么準(zhǔn)備工作呢？
第一，HDRP是同時(shí)支持延時(shí)和前向管線的。所以需要根據(jù)自己項(xiàng)目對(duì)渲染的需求，設(shè)計(jì)自己的移動(dòng)平臺(tái)的渲染管線，是forward/deferred。挑選移動(dòng)平臺(tái)需要的feature。
第二，由于 HDRP整個(gè)管線體系內(nèi)的Shader都并非面向移動(dòng)平臺(tái)，因此有大量feature是使ComputeShader，即使可以優(yōu)化，也需要做好自己項(xiàng)目的支持的設(shè)備性能基線機(jī)型選擇。因?yàn)镃omputeShader 可能對(duì)少部分低端機(jī)不友好。部分featureHDRP提供了Shader和CS兩種版本?？梢园葱柽x擇。如果要支持移動(dòng)平臺(tái)，建議盡量使用shader版本。因此要評(píng)估自己的項(xiàng)目對(duì)低端機(jī)下限的容忍程度。如果沒(méi)有特別長(zhǎng)的時(shí)間專門去做優(yōu)化，選擇HDRP可能不能做到面向特別低端的手機(jī)。
第三，由于是移植，多端通用的資源意味著，往往并不是為移動(dòng)平臺(tái)設(shè)計(jì)的資源。那么需要提前預(yù)備好，優(yōu)化這些資源的人力和時(shí)間。根據(jù) PC端的面數(shù)和Drawcall數(shù)量，估算出多端資源的各級(jí)指標(biāo)，比如角色面數(shù)上限，場(chǎng)景面數(shù)上限等，這些需要在制作PC資源的時(shí)候就要準(zhǔn)備好，可以加快移動(dòng)平臺(tái)的移植進(jìn)程。
接下來(lái)看一下我們?cè)缙谟龅降膯?wèn)題，我們?cè)缙诘?nbsp;Drawcall數(shù)量可能達(dá)到了一兩千個(gè)，帶寬開(kāi)銷可能是1G以上，巨量的三角面數(shù)有時(shí)候達(dá)到了兩千萬(wàn)億左右，管線和Shader代碼對(duì)移動(dòng)平臺(tái)不太友好，很多機(jī)型上有崩潰現(xiàn)象。
其中一點(diǎn)就是 DrawCall，我們的解決方案就是，前面介紹過(guò)的HIS系統(tǒng)。游戲的場(chǎng)景物件，盡可能使用模塊組件化設(shè)計(jì)。目的是為了極大的提高M(jìn)esh的利用率，從而提高我們自己寫的Insancing合批程度。另外就是HLod系統(tǒng)，HIS系統(tǒng)合并掉了近處的物件，那么中遠(yuǎn)景的場(chǎng)景就交給了HLod系統(tǒng)。它可以將一大堆建筑合并成一個(gè)Drawcall，也極大的減輕了管線壓力，是非常值得挖掘的體系。多輪的資源優(yōu)化和面數(shù)控制，最重要的還是輸入數(shù)據(jù)就能控制到接近的數(shù)量級(jí)上，其次是多級(jí)的LOD體系，非常有助于減面。
最后我想講一下剔除算法，第一個(gè)是 HIZ剔除，它用GPUDriven的方式，利用PreDepthPass的深度圖，生成HIZ的深度金字塔，將實(shí)際上被遮擋的水體、植被等進(jìn)行GPU上的剔除處理。它的特點(diǎn)是是可以以非常廉價(jià)的GPU開(kāi)銷，一次性的剔除掉大量的Renderer對(duì)象。但是如果不采用GPU回讀的方式，由于它的剔除行為發(fā)生在GPU階段，因此所有渲染數(shù)據(jù)都需要向GPU提交。因此CPU壓力并沒(méi)有得到釋放。如果進(jìn)行回讀，當(dāng)視角與上一幀變化稍大一些，其回讀數(shù)據(jù)就會(huì)喪失可信任性，仍然是會(huì)產(chǎn)生CPU的渲染提交，以及GPU上最終的渲染成本。另一方面，由于它是以相同材質(zhì)和Mesh來(lái)作為單元管理，當(dāng)材質(zhì)和Mesh的多樣性非常高，實(shí)例化數(shù)量卻不大的時(shí)候，CPU的管理壓力就相對(duì)會(huì)比較大。
最后，在 CPU方面，我們有采取了Intel的SOC軟光柵化剔除來(lái)減少?gòu)腃PU提交Drawcall的數(shù)量。CPU剔除就沒(méi)有材質(zhì)類型的限制，但是它依賴遮擋體的設(shè)計(jì)和制作。因此也更適合用于城市中，墻體周圍的小道具和小建筑等等的剔除。
這兩個(gè)剔除算法都很重要。他們能協(xié)助我們從每一個(gè)層面，去最大可能的減少 Drawcall的渲染數(shù)量。
Drawcall看完了，讓我們來(lái)看看帶寬。首先，重新設(shè)計(jì)管線流程，盡量去掉每個(gè)pass之間RT和狀態(tài)切換的次數(shù)，最好不切換。另外，不需要讀取RT之前信息的時(shí)候，如ColorBuffer在Opaque階段第一個(gè)pass前，使用DontCare或者Clear做為RTLoad 的Flag，避免強(qiáng)迫Load之前的渲染結(jié)果，導(dǎo)致帶寬增加。
第三，由于 feature的減少，HDRP下Shader的VertShader部分的輸出會(huì)出現(xiàn)大量冗余操作，例如去掉了NormalBuffer的輸出，則無(wú)需讀取頂點(diǎn)法線，更無(wú)需進(jìn)入光柵化過(guò)程等。因此優(yōu)化過(guò)程中一定要去掉Vertex函數(shù)輸出結(jié)構(gòu)中,不需要frag過(guò)程中使用的寄存器類型，不要有浪費(fèi)的情況，應(yīng)該控制住每個(gè)寄存器。容易被忽略的是使用Unity提供的Mesh.SetVertexBufferParam函數(shù)，對(duì)Mesh進(jìn)行Split處理，使其在非著色pass中VertexBuffer綁定大小減少。
第四，可以嘗試壓縮頂點(diǎn)，但是可能會(huì)帶來(lái)額外的頂點(diǎn)計(jì)算量，要權(quán)衡一下是否適合，每個(gè)項(xiàng)目的情況也不一樣。最后，評(píng)估優(yōu)化每一張管線中的 RenderTarget貼圖，選擇適合移動(dòng)平臺(tái)的尺寸和格式。比如能用R16，千萬(wàn)不要用R36，也不要使用全分辨率等等。最后，如果帶寬切換太過(guò)嚴(yán)重，可以考慮局部使用Subpass，以避免掉帶寬Load/Store。
說(shuō)完了管線部分，我們來(lái)看看 shader部分。首先Shader里面盡可能去掉各種，開(kāi)關(guān)某些功能的條件分支和for循環(huán)。分支間的即使相同的計(jì)算，也無(wú)法獲得優(yōu)化。比如寄存器不能復(fù)用，可能導(dǎo)致多次相同計(jì)算和采樣（可能還會(huì)產(chǎn)生大量帶寬問(wèn)題）建議將其降低次數(shù)后展開(kāi)for循環(huán)，并根據(jù)項(xiàng)目feature依賴情況直接去掉不需要的分支（或者采用靜態(tài)宏條件分支）。
其次 HDRP采用了大量的動(dòng)態(tài)生成的Buffer來(lái)進(jìn)行數(shù)據(jù)填充，比如GISh，比如主光，點(diǎn)光，陰影設(shè)置，等等。嚴(yán)格控制RWBuffer的數(shù)量，最大不可超過(guò)4個(gè)，否則會(huì)有移動(dòng)平臺(tái)很多設(shè)備上的兼容問(wèn)題。
然后提高 Half計(jì)算占比，是我們一個(gè)Shader優(yōu)化的常用手段。但是HDRP的光照強(qiáng)度很可能會(huì)超過(guò)10W以上，Half計(jì)算之后，幾乎會(huì)一直處于溢出狀態(tài)，需要進(jìn)行壓縮后再計(jì)算，否者我們常年可能會(huì)遇到各種溢出。
還有環(huán)境高光計(jì)算太過(guò)復(fù)雜，過(guò)多的循環(huán)和混合，導(dǎo)致性能非常差，由于對(duì)畫面貢獻(xiàn)較小，移動(dòng)平臺(tái)上替換成 URP類似的環(huán)境高光計(jì)算即可。
最后更換陰影 PCSS算法（循環(huán)次數(shù)過(guò)多），使用更合適的陰影算法，如PCF、VSM等。
讓我們來(lái)看看還有哪些 Shader中被忽略的點(diǎn)。索引大家都知道是什么意思，那么動(dòng)態(tài)索引呢，就是HDRP底層比較喜歡將渲染的數(shù)據(jù)，比如方向光主光，生成list結(jié)構(gòu)，用for循環(huán)的方式在Lightloop中進(jìn)行渲染，這樣，當(dāng)GPU在執(zhí)行一次渲染的時(shí)候，將兩個(gè)像素分別派發(fā)給了不同的wave，這時(shí)GPU就不能清楚的知道，這兩個(gè)wave在訪問(wèn)方向光數(shù)據(jù)的時(shí)候，是否使用了相同索引數(shù)據(jù)，那么這樣數(shù)據(jù)訪問(wèn)的結(jié)果就會(huì)被存儲(chǔ)到向量寄存器VGPR中，而VGPR中的數(shù)據(jù)，是無(wú)法在多個(gè)wave之間進(jìn)行共享的。反之，如果這些數(shù)據(jù)被存到了標(biāo)量寄存器中，GPU多個(gè)wave之間將會(huì)只采樣和計(jì)算一次這個(gè)光照數(shù)據(jù)，在所有wave間進(jìn)行共享。因此這兩種寄存器會(huì)給Shader帶來(lái)非常大的性能差異結(jié)果。因此我們對(duì)Shader的優(yōu)化方向，就需要嚴(yán)格控制Shader中VGRP寄存器的使用率。具體的做法是，將HDRP管線下Shader中動(dòng)態(tài)索引數(shù)據(jù)，比如主光，精確光，陰影等數(shù)據(jù)，統(tǒng)統(tǒng)都拋棄了list的數(shù)據(jù)結(jié)構(gòu)，直接定義到Buffer中，用固定的offset去訪問(wèn)這些Buffer數(shù)據(jù)。這樣這些被訪問(wèn)的數(shù)據(jù)以及這些數(shù)據(jù)的中間計(jì)算結(jié)果，都將有可能被存儲(chǔ)到標(biāo)量寄存器中，從而實(shí)現(xiàn)wave間的共享，避免掉多次計(jì)算。
另外還有容易被忽略的 LRZ的被關(guān)閉的條件。除了我們眾所周知的Frag中進(jìn)行與深度相關(guān)的Clip操作。還有，比如在這些pass渲染輸出了深度/stencil也不行。這里提供一種解決的思路，如果我們希望，Opaque內(nèi)能LRZ的更高效一些，我們需要盡量將深度和stencil的write，在Opaquepass 內(nèi)關(guān)閉掉。最后，不可以使用SecondCommandBuffer，否則在某些設(shè)備上，可能也會(huì)被關(guān)閉LRZ。
我們?cè)賮?lái)看看還有哪些注意點(diǎn)，使用 Vulkan，性能指標(biāo)要好很多，對(duì)ComputeShader支持也更好，機(jī)型兼容性更強(qiáng)，使用多線程渲染和RenderingBatches Jobs我們來(lái)看看右邊這個(gè)圖片。另外，移動(dòng)平臺(tái)下，對(duì)于CPU和GPU都會(huì)訪問(wèn)的的ComputeBuffer，比如CPU內(nèi)填充setdata數(shù)據(jù)，GPU也會(huì)訪問(wèn)讀取這些數(shù)據(jù)。這種情況，newComputeBuffer的時(shí)候，盡量去指定使用ComputeBufferMode的Dynamic/SubUpdates類型，以避免因?yàn)樯暾?qǐng)成默認(rèn)的Immutable類型。因?yàn)镮mm類型的Buffer只允許GPU進(jìn)行讀寫，但是我們又要setdata，因此渲染底層會(huì)幫我們?cè)诿繋淖铋_(kāi)始，將這個(gè)我們會(huì)setdata的buffer，通過(guò)copyBuffer出一個(gè)新的dynamicbuffer，給CPU使用和填充。這樣會(huì)產(chǎn)生每幀大量的CopyBuffer成本。具體寫法可以看右邊這個(gè)圖片。
最后，有源碼條件的同學(xué)，也可以嘗試更改一下渲染 Job的同步點(diǎn)類型，不同的項(xiàng)目可能適合的同步點(diǎn)不一樣，有助于更好的實(shí)現(xiàn)線程之間，或者CPU/GPU之間的并行。
現(xiàn)在我們來(lái)說(shuō)說(shuō)移動(dòng)平臺(tái)的光照解決方案。得益于 PRTGI烘焙，可以讓實(shí)時(shí)計(jì)算的復(fù)雜度減少。這是shader優(yōu)化后效果。我們可以看到房屋下面的AO遮蔽和GI效果也比較明顯。
讓我們來(lái)繼續(xù)看一下移動(dòng)平臺(tái)的點(diǎn)光方案。因?yàn)槲覀兪且粋€(gè)多端通用資源的項(xiàng)目。從維護(hù)的便捷性方面考慮，移動(dòng)平臺(tái)仍然使用 HDRP的Cluster 點(diǎn)光管理方案，但是，我們限制了最大同一個(gè)Cluster內(nèi)支持4-8盞點(diǎn)光，同屏最大支持達(dá)到80個(gè)以上點(diǎn)光。
精確光循環(huán)的計(jì)算內(nèi)容，代碼完全被展開(kāi)，以更好的進(jìn)行寄存器共享，并利用 SIMD計(jì)算，一次性計(jì)算多盞點(diǎn)光的光強(qiáng)衰減和diffuse和GGX高光計(jì)算。可將點(diǎn)光所有的代碼量控制到150行DXBC指令左右。
我們可以看到左邊是移動(dòng)平臺(tái)的副本點(diǎn)光效果，右邊是 PC平臺(tái)的點(diǎn)光效果。除了資源有所不同，其光照效果基本一致。
最后的最后，我想聊一下 HDRP平臺(tái)上的各種Debug工具。首先HDRP自帶的RenderingDebuger工具非常好用，它囊括了幾乎絕大部分PBR渲染流程能的核心參數(shù)顯示，對(duì)于檢查材質(zhì)正確性，它具有完全的不可替代性。
第二個(gè)是經(jīng)常被使用的老牌 Debug工具，它非常好用，與Unity也結(jié)合的非常好。Xcode的各種工具Profiler，用于檢查IOS真機(jī)的內(nèi)存、CPU、GPU、管線帶寬、Shader/CS性能開(kāi)銷，CasheMissing程度等等敏感指標(biāo)，仍然是最方便的。SnapdragonProfile用于檢查安卓真機(jī)的性能開(kāi)銷，profiler性能數(shù)據(jù)也不錯(cuò)，遺憾對(duì)vulkan支持較弱。Arm_Mobile_Studio用于檢查shader性能，分析寄存器情況，SimplePerf用于查看安卓真機(jī)CPU開(kāi)銷情況也很好用。
在 PC上，我們比較喜歡使用的是GPA和Nsight，特別是N卡用戶，可以通過(guò)Nsight，可以獲得更加準(zhǔn)確的GPU開(kāi)銷信息。
這是剛才提到的兩個(gè)算法論文選型，謝謝大家！
