在 2025 年 10 月 24 日的游戲案例專(zhuān)場(chǎng)中，《戀與深空》制作組的引擎負(fù)責(zé)人阮天龍和技術(shù)美術(shù)負(fù)責(zé)人秦平帶來(lái)了演講《打造影視級(jí)渲染管線》，詳細(xì)闡述了如何在移動(dòng)端實(shí)現(xiàn)影視級(jí)渲染效果。

阮天龍：大家好，我是疊紙游戲《戀與深空》的制作人阮天龍，很榮幸能夠站在 Unite 的講臺(tái)上。今天我們要給大家介紹的是“我們是如何在戀與深空這款游戲中打造影視級(jí)渲染管線”的。我叫阮天龍、是 2010 年進(jìn)入的游戲行業(yè)，之前先后在盛大、完美和網(wǎng)易，從事過(guò)引擎開(kāi)發(fā)相關(guān)工作，2018 年入職的疊紙，目前擔(dān)任《戀與深空》制作組的引擎負(fù)責(zé)人。

《戀與深空》作為一款超現(xiàn)實(shí) 3D 沉浸戀愛(ài)互動(dòng)手游，自 2024 年 1 月 18 日上線以來(lái)，目前全球玩家的數(shù)量已經(jīng)突破了 7000 萬(wàn)、并榮獲了科隆游戲展 2025 最佳移動(dòng)游戲。我們是基于 Unity 2019 開(kāi)發(fā)的，并且對(duì)引擎源碼進(jìn)行了深度修改，開(kāi)發(fā)了一套自定義的 SRP 管線。Android線 上版本是基于 GLES3.1，未來(lái)也即將上線 Vulkan 版本。持續(xù)提升性能，滿足玩家對(duì)高品質(zhì)游戲的需求。

接下來(lái)，看一段實(shí)機(jī)畫(huà)面的混剪視頻。

這次分享分為兩個(gè)部分：第一部分由我為大家介紹《戀與深空》的渲染管線設(shè)計(jì)與優(yōu)化。主要涵蓋場(chǎng)景渲染的優(yōu)化、光照的方案與管線設(shè)計(jì)、陰影優(yōu)化這三個(gè)部分內(nèi)容。第二部分將由我們的 TA 負(fù)責(zé)人秦平為大家介紹如何聚焦高質(zhì)量角色表演核心渲染技術(shù)，來(lái)打造影視品質(zhì)的效果。

渲染管線設(shè)計(jì)與優(yōu)化

場(chǎng)景渲染優(yōu)化

前面我們對(duì)《戀與深空》這個(gè)項(xiàng)目有了整體了解。現(xiàn)在，我們將聚焦到游戲開(kāi)發(fā)中至關(guān)重要的一環(huán)——場(chǎng)景渲染優(yōu)化。我們開(kāi)發(fā)了一套場(chǎng)景渲染系統(tǒng)，稱(chēng)之為 RenderGroupRenderer。我們將每個(gè)渲染批次稱(chēng)之為一個(gè) RenderGroup。RenderGroupRenderer 主要做了三件事情。首先是自定義靜態(tài)場(chǎng)景描述，去除 GameObject，避免了更新大量的 GameObject 時(shí)帶來(lái)的性能損耗。其次我們對(duì) CPU 上 GPU 的 Upload 的頻率做了優(yōu)化，主要包括了 Instance Data 和 Constant Buffer 的 Upload。Constant Buffer 的 Upload 優(yōu)化方面，我會(huì)在后面介紹單 draw call 性能優(yōu)化時(shí)詳細(xì)解釋。關(guān)于 Instance Data 的 Upload 優(yōu)化，我們?cè)陧?xiàng)目初期主要針對(duì)室內(nèi)小規(guī)模的場(chǎng)景，采用的是靜態(tài)生成 InstanceDataBuffer，配合 BVH 分割裁剪的形式。隨著項(xiàng)目的推進(jìn)，我們的場(chǎng)景精度要求不斷地提高，后期便轉(zhuǎn)向在 GPU 端完成裁剪與 Instance 的填充。最后我們對(duì)靜態(tài)物件的 CPU 側(cè)裁剪也做了對(duì)應(yīng)的優(yōu)化。通過(guò) Burst + Job System 實(shí)現(xiàn)了一套高度并發(fā)的裁剪系統(tǒng)，同時(shí)只在 CPU 側(cè)進(jìn)行粗略的裁剪，將細(xì)粒度的裁剪任務(wù)交由 GPU 完成。

接下來(lái)想介紹一下我們的 InstanceData 的數(shù)據(jù)形式。大家常用的應(yīng)該都是 Constant Buffer 形式的 InstanceData。但是它也有一些缺點(diǎn)。首先它有一個(gè)尺寸限制，通常是 64kb；其次常量緩存通常都比較小。當(dāng)我們聲明的 buffer 比較大，并且通過(guò) Instant ID 對(duì)它做動(dòng)態(tài)索引時(shí)，即使沒(méi)有超過(guò)最大尺寸，也容易發(fā)生緩存擊穿，導(dǎo)致性能顯著下降。另一種常用的形式是用 SSBO 來(lái)傳遞 InstanceData，這種方法也存在一些缺點(diǎn)。首先它的讀取性能通常是不如緩存未擊穿情況下的 ConstantBuffer，甚至通常不如 Texture。很多移動(dòng)設(shè)備芯片會(huì)為 Texture 設(shè)計(jì)更高效的緩存。其次，一些安卓設(shè)備在 GLES 下不支持在 Vertex Shader 中讀取 SSBO，這也限制了它的兼容性。最后這兩個(gè)方案都有一個(gè)共同的問(wèn)題，就是都需要使用動(dòng)態(tài)索引。在低端手機(jī)上，這是一種對(duì)緩存非常不友好的操作。針對(duì)以上問(wèn)題我們提出了一種“新瓶裝舊酒”的方案。使用 PerInstance Step 的 Vertex Stream 作為 Instance Buffer。這是一種在 GPU Instancing 誕生之初就被支持的 Instance 方法，既可避免動(dòng)態(tài)索引帶來(lái)的性能問(wèn)題，也可避免 SSBO 的兼容性問(wèn)題；還可以通過(guò) Compute Shader 向 Instance Vertex Buffer 輸出，來(lái)實(shí)現(xiàn) GLES 下兼容性較高的 GPU 積累。最后因?yàn)?Unity 引擎的底層沒(méi)有支持 PerInstance Step 的 Vertex Stream，所以我們對(duì)引擎做了相應(yīng)的定制。最終暴露給上層的是 CommanBuffer 中添加的一個(gè) DrawMeshInstancedTraditional 接口。它需要將另一個(gè) mesh 作為 instance data 傳進(jìn)來(lái)。我們也加了相應(yīng)的接口來(lái)配置 instance mesh 中各個(gè)數(shù)據(jù)段對(duì)應(yīng)的頂點(diǎn) semantic。

接下來(lái)介紹一下我們的 GPU Driven 系統(tǒng)。首先我們會(huì)依據(jù) Group 的數(shù)量和 Instance 的數(shù)量，提前分配 IndirectParameter Buffer 與 Instant Data Buffer，注意這里 Instance Data Buffer 只是提前分配了空間，實(shí)際的數(shù)據(jù)是在 GPU Cull 的時(shí)候填入的。同時(shí)我們會(huì)預(yù)計(jì)算每個(gè) Group 的 instance offset，并將其存儲(chǔ)到 Parameter 的 InstanceStart 項(xiàng)。這樣我們就可以全程只綁定一份 instance buffer。此外我們還需要生成逐物件的信息 buffer，其中包含了 Group ID、LOD Distance Range、Bounds、Transform 等信息，用于在 GPU 裁剪時(shí)獲取每個(gè)物件的屬性。

在 GPU 裁剪之前，我們會(huì)先執(zhí)行一次 CPU 粗裁剪，CPU 裁剪僅判斷 Group 整體是否可見(jiàn)，從一個(gè)根包圍盒開(kāi)始，比較物件包圍盒體積總和與合并后包圍盒的體積比值，低于閾值就遞歸分裂包圍盒。這個(gè)主要是為了避免兩個(gè)物件距離很遠(yuǎn)，拉出一個(gè)超大的總包圍盒這種情況。同時(shí)我們還會(huì)配合 PVS 進(jìn)一步判斷 Group 的可見(jiàn)性，因?yàn)槲覀儧](méi)有類(lèi)似 DX12 的 IndirectExecute，我們的 GPU 裁剪只能減少 instance 數(shù)，并不能消除 Group 整體的 drawcall，因此需要 CPU 裁剪盡可能準(zhǔn)確地剔除掉完全不可見(jiàn)的 Group。GPU 裁剪則通過(guò)一次 dispatch 對(duì)所有 Group 進(jìn)行逐物件裁剪，包含視錐裁剪、LOD 裁剪、Hiz 遮擋剔除這 3 段裁剪，通過(guò)裁剪就將 Parameter 的 Instance Count 加 1，并輸出 InstanceData。對(duì)于陰影剔除，我們參考了龍之教條分享的方法，將畫(huà)面深度重投影到陰影空間作為 Shadow Receiver Mask，若 shadow caster 投出的 volume 與 Mask 不相交，就可剔除，避免多余陰影渲染。另外想解釋一下我們?yōu)槭裁礇](méi)有實(shí)現(xiàn) Cluster/Meshlet。首先它不是免費(fèi)的，在移動(dòng)端存在比較大的基礎(chǔ)開(kāi)銷(xiāo)。其次在 GLES 下實(shí)現(xiàn) cluster 也存在一些兼容性問(wèn)題，同樣是之前提過(guò)的 Vertex Shader 訪問(wèn) SSBO 的問(wèn)題。綜合考慮之下，我們認(rèn)為優(yōu)先優(yōu)化單 draw call 的性能更能為我們帶來(lái)免費(fèi)且直接的性能提升。

接下來(lái)介紹一下我們對(duì) draw call 調(diào)用本身做的性能優(yōu)化。為什么我們今天要著重介紹這塊內(nèi)容呢？因?yàn)槲野l(fā)現(xiàn)我們周?chē)泻芏嗤禄蛲袑?duì)于渲染的 CPU 耗時(shí)優(yōu)化這塊，往往過(guò)于關(guān)注 draw call 的數(shù)量，而忽視了每個(gè) draw call 本身的耗時(shí)。降低 Draw Call 數(shù)量只是一種優(yōu)化方法，最終的 CPU 耗時(shí)才是唯一的衡量指標(biāo)。而且現(xiàn)代移動(dòng)設(shè)備與圖形標(biāo)準(zhǔn)，其實(shí)早就可以勝任大量的 drawcall，這塊 HypeHype 引擎的團(tuán)隊(duì)在 Siggraph 2023 有過(guò)一個(gè)分享，他們?cè)?iPhone 6s 上測(cè)試了一萬(wàn)個(gè)不同 mesh 與材質(zhì)的 drawcall，結(jié)果耗時(shí)僅有 11.27ms。其他同等的安卓設(shè)備也都基本能維持在 60 幀以上。另外在 2014 年，蘋(píng)果的 Metal 剛剛誕生時(shí)，也早就提出過(guò)比 GLES 多畫(huà) 10 倍 draw call 的口號(hào)。如果當(dāng)年大家已經(jīng)入行了的話，一定聽(tīng)不少人說(shuō)過(guò)，等新的圖形標(biāo)準(zhǔn)普及了以后就不需要合批了之類(lèi)的話。那么 11 年后的今天，我們?yōu)槭裁慈栽跒?draw call 過(guò)多而苦惱？原因在于多方面的開(kāi)銷(xiāo)。我們總結(jié)了一下，主要包括 PSO 切換過(guò)多、Buffer 提交與拷貝、引擎渲染邏輯以及過(guò)多 RHI 調(diào)用的開(kāi)銷(xiāo)，都會(huì)增加 CPU 負(fù)擔(dān)。所以性能優(yōu)化不能只盯著 draw call 數(shù)，而要綜合考量這些因素。

首先關(guān)于 PSO 切換的開(kāi)銷(xiāo)，其實(shí)主要取決于每個(gè)項(xiàng)目對(duì) shader 變體數(shù)量和 shader 復(fù)雜度的權(quán)衡。我們的 RenderGroupRenderer 也只是做了一些基本的渲染隊(duì)列排序。不過(guò)我們對(duì)于陰影做了一個(gè)特殊處理，沒(méi)有 AlphaTest 的材質(zhì)統(tǒng)一用相同 shader 渲染 Shadow Depth，可以減少陰影渲染時(shí)的 PSO 切換頻率。相對(duì)而言我們?cè)?Buffer 提交方面做了更多優(yōu)化。在 GLES 下，Map/Unmap buffer 會(huì)帶來(lái)顯著開(kāi)銷(xiāo)，現(xiàn)代 RHI 支持的 persistent map 雖能顯著減少 upload 耗時(shí)，但仍無(wú)法避免數(shù)據(jù)從主線程到渲染線程，再到 buffer 內(nèi)存的多次拷貝以及 memcmp。我們采用了三種針對(duì)性的策略：PerRendererBuffer 將逐 Renderer 的參數(shù)，比如物體所受的環(huán)境光 SH，存放在由 Renderer 對(duì)象維護(hù)的 Uniform Buffer 中，渲染時(shí)直接綁定；PerShaderBuffer 針對(duì)不需要逐材質(zhì)變化的 Uniform Buffer，只在 shader 切換時(shí)提交一次，相比 PerRendererBuffer 來(lái)說(shuō)，PerShaderBuffer 更加靈活，可以支持不同的 shader 變體；最后針對(duì) PerMaterialBuffer，我們借用了 SRP Batcher 代碼預(yù)生成逐材質(zhì) buffer 并直接綁定，通過(guò)這些方法顯著減少了 buffer upload。

接下來(lái)是渲染邏輯的優(yōu)化。商業(yè)游戲引擎為保證靈活性與穩(wěn)定性，渲染時(shí)會(huì)進(jìn)行復(fù)雜的邏輯判斷。在 Unity 引擎內(nèi)部，每次調(diào)用 draw 的時(shí)候會(huì)先調(diào)用一個(gè) ApplyMaterial 函數(shù)，它負(fù)責(zé)在渲染之前更新所有的渲染狀態(tài)與參數(shù)。我們發(fā)現(xiàn)當(dāng) draw call 數(shù)量較多時(shí)，它存在一些較為可觀的耗時(shí)。因此我們嘗試對(duì) ApplyMaterial 接口進(jìn)行了單獨(dú)拆分拆，僅在材質(zhì)或參數(shù)需要切換時(shí)才由上層主動(dòng)調(diào)用，另外如果我們只需改變 PerMaterialBuffer，就改用簡(jiǎn)化后的專(zhuān)用接口。做完上述優(yōu)化之后，相同 draw call 數(shù)下，CPU 耗時(shí)可以減少 1/3。RHI 調(diào)用優(yōu)化主要的目標(biāo)是減少除了 draw primitive 以外的其他圖形 API 調(diào)用。我們將相同 stride 的 Vertex&Index Buffer 合并到一個(gè) buffer 里，通過(guò) offset 渲染，可以避免逐 draw call bind VB/IB，耗時(shí)可以減少 15%。另一項(xiàng)優(yōu)化是當(dāng) Resource 未發(fā)生變化時(shí)，我們跳過(guò)了 DescriptorSet 設(shè)置。SetDescriptors 本身是個(gè)耗時(shí)很高的接口，而且切換 Descriptor 還會(huì)增加下一次 draw 的耗時(shí)，這個(gè)在 Arm 的 Best Practice Guide 里有過(guò)介紹。做完這個(gè)可以使耗時(shí)進(jìn)一步減少 30%。

我們?cè)诘投税沧吭O(shè)備上測(cè)試了 5000 個(gè) drawcall 的耗時(shí)。使用引擎原生的渲染時(shí)，渲染線程的耗時(shí)是 34.79ms。當(dāng)我們對(duì) Buffer 提交與渲染邏輯進(jìn)行優(yōu)化后，耗時(shí)降低到 22.97ms。在進(jìn)一步優(yōu)化 RHI 調(diào)用次數(shù)后，耗時(shí)進(jìn)一步大幅降至了 11.8ms。最終我們?cè)?draw call 數(shù)量不變的前提下，讓 CPU 耗時(shí)減少到了原來(lái)的 1/3 以下。

我們還嘗試了一些新的 RHI 特性。首先是 MDI，它在支持的設(shè)備上能帶來(lái)明顯的優(yōu)化效果，還能在一定程度上改善 GPU 遮擋剔除可能提交空 draw call 的問(wèn)題，因?yàn)椴煌?mesh 被合成了一個(gè) draw call，總的 CPU 端提交變少了。然而， Bindless 的表現(xiàn)卻不盡如人意，即便在最新的安卓設(shè)備上也出現(xiàn)了神秘的負(fù)優(yōu)化。結(jié)合 MDI 與 Bindless，我們可以實(shí)現(xiàn)幾乎用一個(gè) draw call 渲染所有物件，但是 CPU 耗時(shí)卻比不合批時(shí)還更高。這也是一個(gè)過(guò)度關(guān)注 draw call 數(shù)量的反面案例。當(dāng)然，我們期待以后的移動(dòng)芯片對(duì) bindless 能有更好的支持?，F(xiàn)階段的話，我們嘗試基于 Unity Texture Streaming 擴(kuò)展出了一套無(wú) Feedback SVT 系統(tǒng)作為替代方案，不過(guò)這個(gè)方案也還在驗(yàn)證階段。從 Benchmark 場(chǎng)景測(cè)試結(jié)果來(lái)看，RenderGroupRenderer 對(duì)比原始無(wú) instancing 渲染，draw call 數(shù)減少了 1/3，渲染線程耗時(shí)大幅減少 3/4，主線程耗時(shí)也減少了 2/3。雖然C，因?yàn)殇秩九c裁剪邏輯都移到 SRP 了，但是引擎原生裁剪與 GameObject 更新耗時(shí)減少，整體仍然帶來(lái)了大幅的優(yōu)化。

光照方案

前面我們探討了渲染性能的多方面優(yōu)化?，F(xiàn)在讓我們將目光轉(zhuǎn)向光照的實(shí)現(xiàn)方案。我們?cè)陧?xiàng)目中選擇使用前向渲染管線，這有多方面的理由。首先，前向管線在應(yīng)對(duì)美術(shù)復(fù)雜且多變的需求方面有其優(yōu)勢(shì)，我們不需要擔(dān)心一些材質(zhì)屬性的添加是否會(huì)導(dǎo)致 GBuffer 膨脹。其次，傳統(tǒng)的延遲管線對(duì)于移動(dòng)平臺(tái)而言帶寬不太友好。 OnePassDeferred 則在靈活性方面存在一些局限，比如無(wú)法在 RenderPass 中間改變 RT 的尺寸，也不能 fetch 當(dāng)前位置以外的像素內(nèi)容。另外在 GLES 下， FrameBufferFetch 的兼容性也存在問(wèn)題，不同芯片支持的 fetch RT 數(shù)量不同，有的只支持 1 張 RT，需要改成通過(guò) PLS 實(shí)現(xiàn)，但是我們測(cè)試 PLS 的性能并不是很理想。引擎自帶的逐物件 4 盞光源對(duì)于較大的物件來(lái)說(shuō)不太夠用，因此我們嘗試了 Forward+。但是 Forward+ 在早期設(shè)備上耗時(shí)太高，若限制逐 tile 最大光源數(shù)，鏡頭變化時(shí)，tile 內(nèi)光源數(shù)量不可控，超上限會(huì)帶來(lái)表現(xiàn) bug。為解決這些問(wèn)題，我們采用了水平世界空間 Tile 劃分，默認(rèn) 2 米一格，分布于相機(jī)前方，逐 Tile 最多 4 盞光源，用一張 128*128 Index Map。這種劃分方式使 Tile 光源重疊狀態(tài)穩(wěn)定，便于在制作時(shí)及時(shí)發(fā)現(xiàn)超限問(wèn)題。

我們?cè)谖磥?lái)的 Vulkan 版本的管線中增加了基于 Subpass 的 Light Pre-pass。在 Pre-Z Pass 中，我們會(huì)輸出一張簡(jiǎn)易的 GBuffer RT 并且 store 下來(lái)。由于我們的 local light 光照使用了沒(méi)有 fresnel 的簡(jiǎn)化 PBR 模型，所以我們不需要在 GBuffer 中輸出 specular 或者 Albedo。我們只將 normal,roughness 和一些特殊的材質(zhì) id 或?qū)傩孕畔?pack 到了一張 RGBA8 的 Gbuffer 上。然后我們就可以跑一遍類(lèi)似 deferred shading 的光源 volume 渲染流程，將幾何光照結(jié)果保存到 Tile Memory 上。之后在 shading pass 中，我們會(huì)把物件再畫(huà)一遍，然后 fetch 這些光照信息，再結(jié)合渲染時(shí)獲得的 albedo 等材質(zhì)屬性，就可以得到最終的光照結(jié)果。我們將 TAA 所需的 MotionVector Encode 為 RGBA8，R + G == 0 代表無(wú)有效速度。這樣某些不輸出速度的材質(zhì)可在 BA 通道存其他信息，比如我們針對(duì)一些簡(jiǎn)易且大量的植被，會(huì)在 MotionVector 的 BA 通道上保存他們的 UV 信息，這樣在 shading pass 時(shí)我們就不需要再畫(huà)一遍植被，只需要一個(gè)后處理獲取 gbuffer 中的幾何信息與 MotionVector 中的 UV 信息即可還原出植被的材質(zhì)表現(xiàn)。

Vulkan 版本的管線大致是這樣的流程，首先由 PreZ Pass 輸出 Depth，GBuffe與 MotionVector。然后計(jì)算陰影的遮擋剔除，接著執(zhí)行陰影的深度渲染，再然后是一些 AO 和屏幕空間 SSS 之類(lèi)的計(jì)算。然后我們就進(jìn)入了 NativeRenderPass，在 SubPass 中計(jì)算 ShadowMask，Light Pre-Pass,以及執(zhí)行正常的 Shading Pass。最后退出 RenderPass，再執(zhí)行其他后處理 Pass。Vulkan 版本管線改進(jìn)存在一定局限。Light Pre-Pass 只能替換默認(rèn) Lighting Model，對(duì)于需要更多 Gbuffer 通道的 Lighting Model，還是需要采用 Forward+。不過(guò)我們提供了一個(gè)逐光源可選參數(shù)，可以針對(duì)某個(gè)光源強(qiáng)行使用 Standard Lit Model，對(duì)所有材質(zhì)統(tǒng)一處理，這樣可以在犧牲 lighting model 準(zhǔn)確性的條件下實(shí)現(xiàn)讓同 Tile 內(nèi)的像素受 4 盞以上燈的影響。

然后是 GI 部分。我們線上的 Diffuse GI 用的還是比較傳統(tǒng)的 Lightmap+light probe 的方式，我們的 Lightmap 只保存了間接光信息。另外我們正在開(kāi)發(fā)一套實(shí)時(shí) GI 系統(tǒng)，相信不久就能和大家見(jiàn)面。我們的 Light Probe 除了正常的逐物件單個(gè)采樣點(diǎn)的模式以外，還提供了一種多采樣點(diǎn)模式。能為每個(gè)物體設(shè)置多個(gè)采樣點(diǎn)，依據(jù)線段、三角形或四面體的重心坐標(biāo)進(jìn)行插值。下面是兩張對(duì)比圖，左邊這張圖是單采樣點(diǎn)的效果，可以看到這個(gè) box 的底部受到的是統(tǒng)一的環(huán)境光照。右邊的是用了兩個(gè)采樣點(diǎn)的結(jié)果，可以發(fā)現(xiàn)左右兩邊受到了不同的間接光照。Specular GI 方面，我們主要是基于使用了 AABB 校正的 Reflection Probe。另外對(duì)于一些特定的地板或水面，我們還會(huì)使用平面反射代理。大致可以看成一種專(zhuān)門(mén)用來(lái)畫(huà)反射的 HLOD。此外我們還參考了戰(zhàn)神的做法，對(duì) Reflection Probe 的CubeMap 做了歸一化。具體來(lái)說(shuō)就是我們會(huì)根據(jù) CubeMap 的像素生成一份環(huán)境光照的 SH 系數(shù)，然后將 Cubemap 中的像素顏色與該方向的環(huán)境光照相除，就得到了歸一化的 Cubemap。實(shí)際渲染時(shí)，我們?cè)儆妹總€(gè)像素在反射方向上所受的實(shí)際環(huán)境光照與 Cubemap 像素相乘，還原出反射顏色。這么做的好處是，即使大量的物件采樣的都是同一個(gè) Reflection Probe,不同區(qū)域的反射也能產(chǎn)生不同的明暗差別。

陰影優(yōu)化

前面我們探討了光照和渲染管線相關(guān)的內(nèi)容。接下來(lái)，我們來(lái)進(jìn)入“陰影優(yōu)化”這一環(huán)節(jié)。

我們陰影系統(tǒng)的基本設(shè)計(jì)是，最多 3 級(jí) cascade 的 CSM 加上一級(jí)角色專(zhuān)屬的特寫(xiě)陰影，或者在某些多角色場(chǎng)景時(shí)會(huì)使用 POSM，也就是 Per-Object Shadow Map。我們目前支持兩盞錐燈投影，上面所有陰影的結(jié)果都輸出到了一張 RGBA8的 ScreenSpaceShadowMask上，R 通道保存主光陰影，G 和 B保存了錐燈陰影，A 通道保存了 AO 信息。我們首先做了一個(gè)簡(jiǎn)單的距離剔除，根據(jù)陰影距離修改 ScreenSpaceShadow 后處理三角形頂點(diǎn)的深度值。再用 ZTest Greater 渲染，剔除陰影距離外的 Shadow 計(jì)算。因?yàn)槲覀冊(cè)谟?jì)算陰影時(shí)需要采樣 depth，所以我們需要兩份 depth 分別用于 Test 與 Sample。我們?cè)贜ativeRenderPass 中拷貝了一份 memoryless 的 depth buffer 用于 Test，盡量避免了額外的讀寫(xiě)帶寬。

另外我們還做了一個(gè)半影區(qū)域檢測(cè)功能。我們先在 1/4 分辨率下計(jì)算一次 PCF，隨后在全分辨率 shadow pass 里采樣 1/4 mask，僅對(duì) shadow 值處于中間區(qū)域的像素執(zhí)行全分辨率 PCF，這樣能在保證效果的同時(shí)，降低計(jì)算量。不過(guò)，這么做之后某些細(xì)節(jié)像素會(huì)存在檢測(cè)不準(zhǔn)確的問(wèn)題。為此，我們分別依據(jù) 1/4 buffer 中 position 的偏導(dǎo)與全分辨率 gather 的 4 個(gè)深度值計(jì)算兩組法線。如果法線夾角大于閾值，就判定低分辨率像素不可靠，并強(qiáng)行執(zhí)行全分辨率 PCF。下面是一個(gè)祈煜畫(huà)室場(chǎng)景的 debug 視圖，紅色區(qū)域是被我們判定為半影區(qū)間的區(qū)域，只有這些像素才會(huì)執(zhí)行全分辨率的 PCF。

我們利用 Receiver Plane Depth Bias 算法實(shí)現(xiàn)了逐像素的 Shadow Bias。它的原理也比較簡(jiǎn)單，首先我們求出屏幕空間 Shadow Coordinates 的偏導(dǎo)，然后我們可以發(fā)現(xiàn)，我們?nèi)绻褂闷聊豢臻g的 UV 偏導(dǎo)對(duì)陰影空間的深度偏導(dǎo)做個(gè)二維鏈?zhǔn)睫D(zhuǎn)換，就能得到屏幕空間的深度偏導(dǎo)。將鏈?zhǔn)睫D(zhuǎn)換描述為雅可比矩陣之后，輕易就能得出陰影空間的深度偏導(dǎo)等于雅可比矩陣的逆乘以屏幕空間深度偏導(dǎo)。這個(gè)偏導(dǎo)值可以近似描述像素在陰影空間深度的坡度，進(jìn)而就可以用它與 PCF 的采樣偏移量相乘，得到近似的 bias 值。對(duì)于中心點(diǎn)來(lái)說(shuō)，我們?cè)黾恿?1 個(gè)像素偏移的 bias 結(jié)果作為起始 bias。

下面是逐像素 bias 與固定 bias 的對(duì)比結(jié)果。左邊用的是固定的 bias 值，可以看到 box 的底部有一段漏光區(qū)域，并且與光照方向接近垂直的表面存在一些自陰影的走樣。用了逐像素 bias 之后，我們就只會(huì)在偏導(dǎo)較大的區(qū)域增加 bias，可以在保持細(xì)節(jié)投影的同時(shí)解決自陰影的走樣問(wèn)題。不過(guò)，當(dāng)屏幕深度不連續(xù)時(shí)，逐像素 bias 可能算出錯(cuò)誤結(jié)果，導(dǎo)致一些漏光現(xiàn)象。為了解決這一問(wèn)題，需要美術(shù)手動(dòng)指定 bias 的最大最小范圍。

另外我們針對(duì) draw call 較多的場(chǎng)景，還嘗試了 Scrolling Cached Shadow Map。我們通過(guò)緩存 CSM 的深度，對(duì)于前后兩幀都被陰影視錐完全包含的對(duì)象，將上一幀的 CSM 滾動(dòng)到當(dāng)前幀投影位置直接得到陰影深度，避免直接渲染對(duì)象。我們只對(duì)最后一級(jí) cascade 應(yīng)用了 scrolling，當(dāng) cascade 范圍比較小時(shí)，大量物體與會(huì)與視錐相交，優(yōu)化效果就會(huì)受限。另外針對(duì)移動(dòng)平臺(tái)的帶寬壓力，我們選擇間隔多幀來(lái)更新 CSM 緩存。最后在未來(lái)，我們還準(zhǔn)備支持 Local ShadowMap Atlas 以及緩存機(jī)制。我們將會(huì)支持兩盞以上的局部燈投影，并且根據(jù)光源的屏占比動(dòng)態(tài)調(diào)整 ShadowDepth 精度。對(duì)于遠(yuǎn)距離的局部光源，也會(huì)引入靜態(tài)緩存支持。

以上是我本次分享引用的一些參考資料。下面將由我們的 TA 負(fù)責(zé)人秦平為大家介紹如何打造影視品質(zhì)的效果，謝謝大家！

打造影視品質(zhì)效果

秦平：各位朋友，大家好！前面我的搭檔分享了《戀與深空》項(xiàng)目渲染底層框架的一些內(nèi)容，接下來(lái)我來(lái)分享一下我們?cè)谶@樣的框架下面是如何打造一個(gè)高品質(zhì)效果的。主要是一些方案相關(guān)的東西。我叫秦平，十七年游戲行業(yè)從業(yè)經(jīng)驗(yàn)，曾經(jīng)有幸參與制作《神秘海域4》、《怪物獵人世界》等游戲項(xiàng)目的制作；2017 年加入疊紙成為疊紙的第一個(gè) TA，參與開(kāi)發(fā)了《閃耀暖暖》項(xiàng)目，現(xiàn)任《戀與深空》項(xiàng)目 TA 負(fù)責(zé)人；因?yàn)橹白鲞^(guò)一些主機(jī)游戲，所以我對(duì)高品質(zhì)的游戲效果一直都有一些追求，今天借這個(gè)機(jī)會(huì)跟大家聊一聊《戀與深空》項(xiàng)目追求角色效果表現(xiàn)的路上遇到的一些問(wèn)題和解決思路。

這里我大致總結(jié)了一下對(duì)我們角色表現(xiàn)影響比較大的幾個(gè)方面：首先就是分鏡，我們每一個(gè)劇情表演和每一個(gè)約會(huì)，都是采用了影視級(jí)的導(dǎo)演分鏡思維來(lái)指導(dǎo)創(chuàng)作的。一個(gè)好的分鏡思維對(duì)一個(gè)好的作品是必不可少的內(nèi)容。然后我們大量采用了真人動(dòng)捕的技術(shù)來(lái)提升動(dòng)作表現(xiàn)。有了這個(gè)增進(jìn)和動(dòng)作之后，我們還需要一個(gè)專(zhuān)用的劇情編輯工具。這里我們工具組的同學(xué)花了大概大半年的時(shí)間，精心打造了一套專(zhuān)用的劇情表演工具，配合上 AI 組同學(xué)支持的一個(gè)口型和表情系統(tǒng)。最后是定制化的光照和渲染方案，這個(gè)也是我這次主要要跟大家分享的東西。

角色光照方案

我這邊先分享的是“角色光照方案”，這里講的“光照方案”不是大家熟知的前向渲染、延遲渲染這些管線相關(guān)的內(nèi)容。我這個(gè)方案指的是一個(gè)解決思路，比如我角色應(yīng)該受哪些光，怎么管理這些光。經(jīng)常有美術(shù)的同學(xué)報(bào)怨，我的場(chǎng)景和角色割裂感很重；我一個(gè)近幀打光打好了之后效果還可以，但是鏡頭和角色一動(dòng)起來(lái)效果就崩了，這些問(wèn)題經(jīng)常會(huì)困擾我們。其中最突出的幾個(gè)點(diǎn)：

第一是場(chǎng)景氛圍和角色燈光要求沖突。比如夜晚場(chǎng)景需要冷色調(diào)營(yíng)造氛圍，但是角色面部一般都需要暖色調(diào)保持自然膚色，如果想要用一個(gè)冷色調(diào)去著重表現(xiàn)當(dāng)前是一個(gè)夜晚的氛圍，就很容易讓角色顯得不自然或者失去立體感；第二個(gè)跟前面這個(gè)是息息相關(guān)的，就是場(chǎng)景和角色的美術(shù)同學(xué)需要反復(fù)溝通。比如一個(gè)室內(nèi)場(chǎng)景做好了，但是角色入場(chǎng)之后發(fā)現(xiàn)這個(gè)表演的位置透不進(jìn)光，想在這個(gè)角色附近開(kāi)個(gè)窗，透一個(gè)光進(jìn)來(lái)；或者補(bǔ)一個(gè)光源，比如臺(tái)燈。場(chǎng)景補(bǔ)好之后劇情編輯的時(shí)候可能又發(fā)現(xiàn)這新增的物體會(huì)在表演過(guò)程當(dāng)中遮擋鏡頭，或者是角色動(dòng)作會(huì)穿到這個(gè)物體里面，反反復(fù)復(fù)增加了很多溝通成本；三就是如果每一張卡，每一個(gè)劇情、每一個(gè)表演都要從零開(kāi)始的話，會(huì)帶來(lái)海量的工作內(nèi)容；最后就是我們希望我們提供的作品每一幀都經(jīng)得起反復(fù)觀看，這就需要燈光和效果逐幀精修。

有了這些問(wèn)題，我們就可以把具體需求拆解出來(lái)了，我們需要角色和場(chǎng)景可以分開(kāi)調(diào)整，盡量互不影響；要支持逐幀調(diào)整燈光參數(shù)；還需要支持把調(diào)整好的效果保存成模板，支持編輯和切換功能。

有了明確的需求就可以開(kāi)始干活了：我們知道光照是由直接光和間接光組成的，直接光正常就是平行光、射燈和點(diǎn)光。一般情況下我們只會(huì)有一個(gè)平行光，我們習(xí)慣稱(chēng)之為主光。對(duì)這個(gè)主光，我們讓他正常照亮場(chǎng)景，但在照亮角色的時(shí)候我們保留了它的方向，然后用角色 PPV（Post Process Volume）去復(fù)寫(xiě)它的顏色和強(qiáng)度。具體實(shí)現(xiàn)方式就是給 shader 多傳了一份角色主光顏色，角色的 shader 在獲取主光的時(shí)候獲取到的顏色就是這個(gè)角色主光顏色；另外我們給角色提供了一盞額外的不投影的平行光用來(lái)做輪廓光；此外我們預(yù)留了兩個(gè)額外光給角色，他可以是任意的點(diǎn)光和射燈組合，這兩個(gè)額外光就是正常的光源，他們可以正常照亮范圍內(nèi)的角色和場(chǎng)景物件。因?yàn)槲覀円粋€(gè) 2 米的格子最多可以有四盞額外光，所以在這里劃分了一下，角色兩盞，場(chǎng)景兩盞。間接光我們使用 Unity 的 LightProbe 系統(tǒng)來(lái)創(chuàng)建探針，自己實(shí)現(xiàn)了保存間接光信息到探針里的部分。我們把場(chǎng)景的環(huán)境光和角色的環(huán)境光分開(kāi)存儲(chǔ)，分成了兩套；至于環(huán)境光高光還是使用的同一個(gè)反射球，但是我們?cè)谔厥獾牟馁|(zhì)上支持了一些 cubemap 的覆蓋收入。

然后我們把這些影響角色的光照信息存到一個(gè) scriptableobject 里，由燈光師調(diào)整好之后保存成一個(gè)模板；大家可以看最右邊這張圖就是我們保存下來(lái)的 scriptableobject。它包含了我上面提到的兩盞平行光，兩個(gè)額外光，還有探針保存下來(lái)的 sh 信息，以及一些后處理盒子上可以額外調(diào)整的信息。比如主光顏色、額外光顏色；最后用一個(gè) manager 去用一種類(lèi)似棧的方式去管理起來(lái)，這里選用棧的管理方式跟它的使用關(guān)系很大，通常情況下除了加載新的燈光方案之外，“?！本秃芎玫臐M足了這個(gè)特性、我們就用這個(gè)方式把它管理了起來(lái)。

到這里角色燈光方案基本上就完成了，它實(shí)現(xiàn)了我們拆分出來(lái)的需求。比如：角色和場(chǎng)景可以分開(kāi)調(diào)整，還可以實(shí)時(shí)的切換。這個(gè)動(dòng)圖就是切換不同的光照方案時(shí)這個(gè)角色的表現(xiàn)。

我們把切換燈光方案這個(gè)事情定義為一個(gè)劇情編輯器上的一個(gè)事件，這樣它就天然支持后續(xù)可以銜接光照動(dòng)畫(huà)。因?yàn)橹挥性谇袚Q這個(gè)事件發(fā)生的那一幀，然后修改了當(dāng)前的這些參數(shù)，后續(xù)就可以對(duì)這些參數(shù)額外進(jìn)行 K 幀。下面是一段劇情編輯器上動(dòng)態(tài) K 幀的一個(gè)視頻，給大家展示一下我們可以逐幀調(diào)整光照動(dòng)畫(huà)的內(nèi)容?？梢钥吹?，這個(gè)視頻上面很多的參數(shù)都是被 K 了偵的、包括一些后處理、燈光、陰影，那些藍(lán)掉的地方全部都是 K 了幀的。但是不僅是光會(huì)用，劇情編譯器是我們所有表演的入口，比如：物理之類(lèi)的東西，也是在這個(gè)地方 K 進(jìn)去的。

特寫(xiě)陰影

光和影一直都是密不可分的，前面介紹了光，接下來(lái)介紹一下陰影。前面我的搭檔也有提到，我們的陰影方案是三級(jí) CSM 加特寫(xiě)陰影，這里我著重介紹一下特寫(xiě)陰影。我們特寫(xiě)陰影就是在角色身上選一根骨骼，然后作為一個(gè)球心，然后用這個(gè)球心來(lái)指定一個(gè)指定半徑的球。可以看到這里有一個(gè)子系統(tǒng)，子系統(tǒng)上面有這個(gè)包圍球半徑，還有這個(gè)負(fù)節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)就是指定的這根骨骼，然后用它作為球心，然后用這個(gè) 0.85 作為半徑來(lái)構(gòu)建一個(gè)球。如果有兩個(gè)角色的話，我們會(huì)對(duì)這兩個(gè)球進(jìn)行一個(gè)包裹，用算法求一個(gè)包裹球，然后用這個(gè)球來(lái)計(jì)算最終的 ShadowMap。

這個(gè)視頻里面我們可以看到，就是原本因?yàn)樵谑覂?nèi)整個(gè)都在陰影里面的這個(gè)角色，因?yàn)槲掖蜷_(kāi)了特寫(xiě)陰影，然后他的面部被照亮了。我這里展示的主要就是想要說(shuō)明我們這個(gè)特寫(xiě)陰影的很多參數(shù)都可以單獨(dú)的調(diào)整。比如說(shuō)這個(gè)近裁切平面，近裁切平面往前推室內(nèi)的墻就被不投影了，然后這個(gè)角色就被照亮了。這個(gè)特寫(xiě)陰影上面這些參數(shù)都是可以改動(dòng)的，我希望調(diào)整到一個(gè)角色最好的效果，然后呈現(xiàn)給玩家。

皮膚細(xì)節(jié)

說(shuō)完了光影，接下來(lái)聊一聊角色的皮膚、臉上細(xì)節(jié)相關(guān)的內(nèi)容。皮膚分了兩檔：高配就是屏幕空間的 3S，SSS 圖降了分辨率，就相當(dāng)于做了一次模糊。低配的其實(shí)是用了一個(gè)工具，去實(shí)時(shí)地?cái)M合和保存這預(yù)積分圖，這里不做過(guò)多展開(kāi)。接下來(lái)，我們聚焦一些細(xì)節(jié)的表現(xiàn)。例如：臉紅、流汗的效果，當(dāng)然我們也做了一些張嘴、閉嘴的 AO，以及可以 k 幀的眼睛高光，睜眼閉眼的雙眼皮的一些效果。由于時(shí)間有限，這里先聊一下臉紅和流汗的效果。這里我錄了一張卡，可以展示角色的臉紅的表現(xiàn)。當(dāng)女主和男主進(jìn)行一些互動(dòng)的時(shí)候，如果我改變臉上皮膚的顏色、可以很明顯地讓畫(huà)面看起來(lái)更加的生動(dòng)和更真實(shí)。

通常來(lái)講，“臉紅”的過(guò)程是一個(gè)逐漸變化、并且不同區(qū)域變化程度不一樣的過(guò)程。大部分的人在臉紅的時(shí)候會(huì)從耳朵先開(kāi)始紅，然后臉頰，偶爾會(huì)有整張臉變得通紅的情況。為了模擬這個(gè)過(guò)程，我們把“臉紅”做成了一個(gè)可以區(qū)分通道的遮罩圖。每一個(gè)通道對(duì)應(yīng)一個(gè)區(qū)域。這里也分別提供了對(duì)應(yīng)的色塊，去改變臉紅的顏色。如果逐幀去 K 的話，這個(gè)工作量也會(huì)非常大。這里我們也是采用了模板的思路，美術(shù)同學(xué)可以根據(jù)不同的男主，定制不同的臉紅的曲線做成模板。我們只要在 K 臉紅效果的時(shí)候，調(diào)用對(duì)應(yīng)的模板、就可以做到對(duì)應(yīng)的臉紅效果。

臉紅到一定程度，比如：我現(xiàn)在是在運(yùn)動(dòng)，運(yùn)動(dòng)的時(shí)候臉?lè)浅５募t，可能我接下來(lái)就會(huì)流汗。如果只有臉紅沒(méi)有流汗的效果還是不夠真實(shí)，接下來(lái)我們做了流汗的效果。我們的流汗有兩種：一種是粒子，主要用的是 vfx，用 skinmeshrender 發(fā)射粒子出來(lái)，用來(lái)描述一些“甩汗”的效果。材質(zhì)上的實(shí)現(xiàn)，也分為兩部分：一是修改粗糙度，讓皮膚看起來(lái)比較濕潤(rùn)。第二個(gè)就是凝聚成的汗珠，這個(gè)凝聚汗珠的實(shí)現(xiàn)思路與 Unite2019 閃耀暖暖里分享的實(shí)現(xiàn)思路是一樣的，它詳細(xì)介紹了一個(gè)閃點(diǎn)，有興趣的同學(xué)可以翻一翻當(dāng)年的這篇分享。這就是大概的一個(gè)實(shí)現(xiàn)思路。

下圖最上面這個(gè)部分就是計(jì)算汗滴生成位置，并根據(jù)汗滴的位置修改粗糙度。我們先把 uv 劃分成格子，然后把格子的 ID 做成材質(zhì)的輸入。這樣每個(gè)格子里所有的 uv 就會(huì)返回同一個(gè)隨機(jī)數(shù)，我們把這個(gè)隨機(jī)數(shù)處理當(dāng)成汗滴生成的位置，詳細(xì)代碼如下圖。下方的視頻就是最終實(shí)現(xiàn)出來(lái)的流汗效果。流汗時(shí)汗滴流下來(lái)就是 uv 動(dòng)畫(huà)。但為了讓汗滴流下來(lái)的過(guò)程更真實(shí)，我們做了一個(gè)模擬它軌跡的很小的算法實(shí)現(xiàn)（下圖右下角）。

謝謝大家，我的分享結(jié)束了。

Unity 官方微信

第一時(shí)間了解Unity引擎動(dòng)向，學(xué)習(xí)進(jìn)階開(kāi)發(fā)技能

每一個(gè)“點(diǎn)贊”、“在看”，都是我們前進(jìn)的動(dòng)力