團結引擎的實時全局光照系統支持完全動態的場景、動態材質和動態燈光的 GI 渲染，包括無限次彈射的漫反射和鏡面反射 GI。在 Unite Shanghai 2024 團結引擎專場演講中，Unity 中國高級技術經理周赫為大家深入解析了團結引擎的實時全局光照系統。

以下為演講內容回顧。

團結引擎致力于解決中國開發者的需求，全動態的實時全局光照（Real-time Dynamic Global Illumination）可以說是開發者千呼萬喚的功能。在實時渲染領域中，如果常年有海量的物體、海量的燈光，這些物體燈光都可以移動，這些燈光還都帶陰影，那么計算實際光照都已經是一個很難的問題了。

傳統的計算方式，比如說光照圖，比如說 Unity 自帶的 Enlighten，它是半實時的，需要進行預計算。 但是我們看到現實世界中的光照是非常細膩的，燈光和物體運動情況下，它們的動態細節是可以辨認出來的。如果是預計算的話，因為它的預計算時間很長，但是存儲量很有限，這就是實時全動態全局光照需要解決的問題。

傳統方案對于重度游戲場景來說難度很大， 現在流行的重度開放世界的游戲更難采用這種方案。 還有一個工作流的問題，大型的場景預計算時間很長，每天晚上開始計算場景，到第二天早上都沒有計算完，這種對工作流來說也做不到及時反饋，運行畫面真實感應也很難保證。

下面放一個視頻直接感受什么是實時的全動態 GI。

這是一個室內場景，整個場景只用一個平行光做光源，剛才看到的地方都是平行光的陰影。室內場景遮擋復雜，在這些地方有比較細的光照表現。另外，場景中有一個鏡子，是完全光滑的表面，它是從鏡子往外發射光線，打到 GI 場景的數據結構，這個結構是對整個三角面場景的簡化。鏡子中的 GI 場景不仔細看無法看出和真實三角面場景的差異，它的光照和幾何細節都很細。基于這樣的 GI 場景才能實現實時全動態全局光照。

這個視頻是室外場景。這個場景同樣只有一個平行光，因為整個天空盒有一定的亮度，平行光陰影范圍內是天空盒光線照亮的。如果是墻面的背面，會有很多凹凸置換的紋理，如果沒有我們的實時光照就會是平的。我們播放細節可以看到平行光移動的時候，陰影區域反射光是在變化的，這些都是實時全動態 GI 的細膩效果。游戲中有一類很難表現的陰天/多云場景，這些陰影區域可以認為和這樣的場景表現類似。

上面是開發中的視頻，首先展示了關掉 GI 的效果，它的材質紋理可以表現出來，但是沒有光照細節，看起來很平。怎樣打開 GI 呢？只需要一個開關，打開就有這個效果，不需要進行任何預計算。這個場景是開發中的畫面，它是從 Asset Store 隨機下載的一個室外場景，陽光非常強，沒有特意表現間接光照效果，但是實時 GI 對真實感進行了提升。

下面兩個視頻展示了在團結編輯器中的交互：

什么是全局光照

什么叫做全局光照呢？

這個公式是做渲染方面很熟悉的，積分號右邊是一個 Lr，x’ 是一個表面，ωi 是一個方向，指這個表面在某一個方向接收的光線。左邊的 Lr 表示我們要算一個 x 點的 GI。右邊的光線來自另外一個表面，另外一個表面發出的光線被接收了。f 是一個 BRDF 雙向傳播的函數，是關于面元 x 還有兩個角度的函數。還有 G，它是距離平方反比的系數，它的兩個表面與光線傳播方向有一定的夾角就會自然衰減。公式最重要的一點是 V，這個 V 是關于 x 和 x’ 兩個面元的函數，可見為 1，不可見為 0。這個公式對場景中所有的面元產生影響，對于有非常多的物體在里面的游戲場景，每個物體劃分非常細才能得到比較細的 GI 效果，這個公式的 x 數量級非常高，要算是否可見一般使用射線檢測（光線追蹤），用這種方式去做計算很耗時，面元數量也非常多，這個 V 可見性的系數計算是非常大的性能開銷。

另外一個非常大的計算開銷來自哪里呢？我們正常算直接光照，一個光源有多亮是已知數；但在這個公式里它是一個未知數，它是關于 Lr 的方程。已經有文獻對這個方程進行求解，改寫成了 Fredholm 積分方程形式，可以認為是一個線性公式，用線性算子去求解。Le 是任何一個表面所發射的光線，它發的光線如果不同就寫成 Le，Le 是一個已知數，不需要更多的計算量。

我們再看算子求解，它還引出一個概念是多次彈射。左邊是 L（未知數），把 L 歸并以后，這里用到一個解的技巧，這個 “I-K” 再 “×” 后面是一個單位陣，所以它乘起來就是 “I+K+K2+…” 再 “×E”，再展開以后就變成這么一個公式。

從右邊的圖可以直觀看到復雜程度，首先 Le 是一個面元發射的光線，在圖里只有亮的面元（光源的面元）才有 Le。依次彈射指的是直接光照，因為這是一個面積光，第一行中我們看到陰影地方是完全黑的，因為面積光有一定的過渡，但是實際中點光源或者平行光沒有過渡，這是直接光照的結果。如果是第二行算一次彈射間接光照，會比剛才的圖好一點，但是也好不了多少。第二行最后是多次計算彈射間接光照。這個圖，我們認為它的效果是接近真實效果的。

因此我們就引出了計算復雜性的第二個來源“多次彈射”，現實中的場景光源從能量角度來看，從光源發出的能量經過無數次的彈射達到平衡的狀態，全局光照就要把平衡狀態渲染出來。

剛才說的運算很復雜，像一些電影動畫會采用離線渲染來算，一幀畫面出幾個小時甚至一天的時間。但是我們游戲的實時應用也要全局光照才能達到更高的真實性。全局光照對于畫面真實感，還有像陰影區域高頻細節提升是非常顯著的。要使畫面更自然，即使是非真實感的畫面也需要全局光照。

這個運算量大的問題怎么解決呢？除了傳統的靜態方式（光照圖、環境光照探針）外，每個探針記錄了比較少的系數，但是用這種去做反射，其實還是要存更多的數據，每個探針數據量就會大，要整個場景用探針方式存儲量就會很大，尤其是光滑的反射，就不能使用這種方式。

預計算 visibility，即 Unity 現有系統 Enlighten，它其實按剛才的方式把場景分成面元，面元組成一個層級，并不會計算每個面元到每個面元的 visibility 系數，它系數還存在 G，但是運算比較少。我們看 visibility，它計算層級中的一些根節點之間的系數，是否可見記錄在這個數據結構中，它的存儲量不是 O(n^2) 了，就能存儲小一些，但是面元多的話還是存儲量太大了。我們使用 Enlighten 的時候，會把場景劃分面元劃分很大。這是需要預計算的方式，當然更新也需要時間。運行的時候，它能做到場景是靜態，光源是動態，而做不到物體和光源完全是全動態。

全動態實時全局光照算法演進

下面我們重點介紹一下全動態實時全局光照算法演進。

所有不需要預計算的方法都可以認為是演進的一部分，都有哪些呢？我們可以簡單列舉一些。

右上角的圖（RSM），它從光源出發，渲了一張 reflective shadow map，它其實跟正常陰影貼圖相比除了深度以外還有一些材質信息，還有打上去的光的信息，針對每個光源都要進行操作。而且重點是，它只計算了從光源出發到這個點的 visibility，忽略了從這個點反彈的 visibility。我們會看到效果有點怪，我們說一個渲染畫面它的質量是由材質和光照，還有一些幾何體綜合起來構成的。如果像這種場景，只有大的色塊，沒有材質細節，并沒有那么精確，會有比較大的畫質損失。還有一些如 Instant Radiosity、ISM。

第二類是基于體素 （LPV，SVOGI，VXGI），LPV 沒有 visibility，VXGI 計算了 visibility，但存儲的分辨率有限，在接近遮擋物邊緣的地方，相當于相鄰體素進行了線性差值，會發現過渡是不自然的。也就是說總結下來，我們只要是計算過程中過于省略，忽略很多細節，看到的畫面一定會肉眼發現不自然，跟真實場景不一樣。所以全局光照對于人觀察世界來說是一些重要的細節，我們要把它盡量還原出來才能做到真實。

還有一些問題，因為體素顆粒度比較多，還有基于圖像會因為場景中少一些屏幕、攝像機空間之外的信息，也會造成不真實。另外，閃爍也是一個重要的點，如果基于圖像，由于信息不完整，導致畫面上下幀差異比較大造成閃爍，我們盡量會復用相鄰像素的信息進行過濾。

團結引擎全動態實時全局光照系統

我們看一下團結引擎全動態實時全局光照系統。我們基于兩階段的方法，這個方法1987 年就有人提出。因為計算復雜性來源兩個地方，一個是要計算無限次的彈射，另外一個是計算非常多的射線檢測。

怎么樣能減少運算呢？首先需要把 GI 場景用一種比較粗粒度的方式表現出來，用來計算多次彈射的結果。在最后一次彈射的時候，從畫面中的物體彈射到攝像機，實際操作是反過來的（從攝像機出發），這次彈射我們利用屏幕空間的高頻信息（G-Buffer），還有相應的 motion vector 信息，用這些信息發出光線，這個信息是精確的，因為屏幕空間包括置換、貼圖信息都是包括在內的。

歷史上第一個用兩階段方法也是用在離線渲染上，它用的是 Radiosity 加上 Ray Trace，還有著名的算法，比如光子映射，它完全是使用兩階段的方法。因為光子映射是對場景的粗糙表示，只保存低精度的光子，光子數量很少的時候很不精確，但是在最終聚集階段利用屏幕上的 G-Buffer 點上出發，它的精度是比較高的。即使粗粒度表示精度不高，也能使最終畫面效果提升。

第一，使用 GI 場景進行近似計算的話，粗粒度場景有幾個功能，首先是進行Raymarching 加速。也就是說射線檢測有多種方式，比如光追、Raymarching，我們如果有距離場或者是一些體素方式，再以一定步長去遍歷場景，打到場景中存的物體上，命中或者未命中，能比光追計算要快。光追是完全精確通過 BVH 碰撞三角面，一般來說計算比較慢，比較復雜。

還有，粗粒度場景可以對材質和光照進行緩存，最重要的是光照緩存。比如之前的 VXGI，如果準備兩套體素，在兩套體素之間進行傳遞，比如已經算出上一幀的 VXGI，我們知道它是單次彈射的，如果下一幀復用上一幀的結果，從體素出發打的是上一幀的體素，能得到累計光照的效應。也就是說最開始列的 KL 公式，是累計了之前的結果。可以看到粗粒度表示可以用多種數據結構，可以理解為抽象的一個接口，接口的實現可以用多種方式。一會兒會介紹到最終的實現方式。

第二即用最終聚集計算 GI，也就是剛才提到的從 G-Buffer 出發。

我們再介紹一下團結引擎全動態實時全局光照的特點，兩個階段各有特點，當然后一階段是提升精度。性能來說，我們發現實際最大量的射線檢測是在于 final gather 階段。另外一個特點是模塊化，每個階段可以支持更多的算法。

PC 和移動平臺的特性是不一樣的，移動平臺的帶寬很有限、GPU 性能有限，比如光線追蹤在移動端也可以有實時方式，但它每秒鐘發出的光線數量遠少于桌面 GPU，我們必須用一種方式把總的計算量減少。

GI 場景

我們現在介紹一下 GI 場景，也就是粗粒度的場景表示。這里是它需要解決的一些問題：

• 覆蓋攝像機附近的場景范圍，大概 300 米。更遠的場景怎么辦？更遠場景渲染時會有一些圖像空間的信息，去補全信息。

• 真實場景變化時實時更新，要做到實時更新有多種方式，一種是所有東西更新一遍，還有一種是在 GPU 端對已有數據進行增刪改查，在 GPU 端用 compute shader 處理 CPU 端發布的增量數據。現在主要用的是增量更新。

• 加速世界空間射線檢測，剛才也說了很多種數據結構可以做到。另外，我們射線檢測只能檢測到兩個點之間是否可見，可見之后如果是命中了，能得到命中點的三維空間坐標，要想進行后續的光照計算，必須從這個坐標查詢到三維空間世界空間的點對應的存儲空間，存儲空間可能存了物體 PBR 屬性，還有之前累積的直接光照和間接光照的數據。必須從 3D 坐標點查詢到數據，這需要一種數據結構能快速查詢，而且要占的空間更小。如果是之前提到的體素，或稀疏的體素存儲，它的存儲空間都偏大，所以需要用其他的方式去存。

我們再介紹一下GI 場景中射線檢測的部分。我們提到射線檢測是給定一個點，這個點對應 x 面元，從這個點出發可以朝著 final gather 所指定的方向打光線。那么它其實有多種計算方式可以適用不同的場景，對外是一個抽象接口，內部實現有多種。首先是物體空間 SDF，它是兩套索引，首先是物體的 instance ID 的索引，每幀都去構造，從攝像機出發，把攝像機追臺劃分成小的 froxel，每個 froxel 記錄它所會相交的 instance 數據，這是每幀計算的，但是因為 froxel 數量有限，所以可以以較快方式把它計算出來，這是物體空間的 SDF。

還有重點介紹GPU DF，它是一個全動態的，無符號的距離場。之所以無符號，因為我們在 GPU 端對三角面進行體素化的時候，并不知道當前的體素格子在面的什么方向，有可能在正向，有可能在反向，我們干脆不判斷它在什么方向，而是采用無符號的方式存儲它。我們距離場的特點，首先是無符號存儲，它也是分塊的，因為整體數據結構稀疏，葉子節點是一個塊，塊里面數據緊湊，但是塊外稀疏，可能整個 “N×N” 的塊沒有任何三角面，在這種情況下就不存儲它。如果是有的話，我們會計算塊中對應的每個體素到三角面的距離。

另外，它的更新也是完全用 GPU 去實時更新，不同于物體空間 SDF 至少物體的 SDF 是預計算的。剛才說的 froxel 是實時生成，但如果物體是預計算的話，會影響我們動畫物體渲染，無法做到完全實時；如果是用 GPU 全動態距離場的話就能做到。

它是怎么更新的呢？首先在 CPU 端對物體的移動、增加、修改、刪除進行收集，得到列表，列表放到 GPU compute buffer 里，然后傳送到 GPU 端，用 compute shader 進行處理，compute shader 會把這些物體對應的 instant ID 更新到 GPU scene 場景中，里面每個物體會對應一些三角面，這些三角面會對應到每一個體素，就會獲取到每個體素塊對應的三角面列表。

進行 GPU 實時計算和更新的時候，我們獲得列表以后，對于每個塊會發射一組 compute shader，每個 shader 的 thread 對應一個體素，整個 compute work group 就對應整個體素塊，每個 work thread 會判斷距離三角面的距離。通過 shared memory 進行最小值的計算，能得到實際要存儲的最小值，也就是存儲在距離場的數值。

這個結構是分層的結構。首先是 Cascade，一共 4 級到 8 級，每級 Cascade 比上一級 Cascade 覆蓋范圍多一倍，每個 Cascade 是一個帶有 mipmap 的層級，每個 mipmap 用來索引體素塊。一般來說是三級，每級是 16 個體素塊，體素塊層級最后的葉子節點是稀疏存儲的，有可能這個層級沒有體素塊，就不記錄體素塊的 ID，如果記錄了體素塊 ID 會索引到一個大的 atlas，把每個體素塊里所有距離的數值進行存儲更新，所有體素化完的數據會更新到 atlas 上，atlas 的分配是在 GPU 端計算好的。

我們在進行追蹤的時候，是從 cascade 出發，沿著 mipmap 層級最終到體素塊，在體素塊里面進行距離的步長檢測。在 mipmap 階段，每個 mipmap 元素記錄了元素的 AABB，也是為了加速計算。

還有一種情況是攝像機的移動，我們采用3D 卷軸策略，在攝像機移動之后，它的 cascade 范圍有一部分體素層級會移出可見范圍，因為總會有對應數量體素移進來，我們就會把這部分更新為移進來的。因為 mipmap 是對下一級 mipmap 進行索引，可以復用舊的 GPU 存儲空間。

再介紹一下Attribute buffer。我們說射線檢測命中以后會得到世界空間坐標點，屬性緩沖 attribute buffer 就是指通過坐標點能獲取到一些數據。因為我們知道 3D 場景中的三角面是比較稀疏的，如果把整體所有的三角面存儲到一個地方，一定有一種方式能把材質屬性還有 lighting 信息以比較緊湊的方式存在 GPU 端。這與剛才的 GPU DF 不一樣的點在于，GPU DF 還需要有一部分不緊湊的地方，因為需要去做 mipmap，但是它的數據不緊湊，有可能有些地方沒有存體素，但一定要能索引它，所以要有一定的空間占位。

Attribute Buffer 中就不存在這個，我們有多種方式去存儲。首先是分頁方法，它有兩種，一種是線性分頁，把一個物體占用多個頁面，這個頁面位置是預計算的，頁面有對應的 AABB；還有一種方式是物理空間哈希，這也是比較流行的方法，物體空間也是一個 3D 空間，物體三角面每個點如果以一定的分辨率進行體素化，每個體素 3D 空間點可以映射到 2D 空間點。因為我們知道在分頁模式下 Attribute buffer 是一個 2D atlas，需要把 3D 空間映射到 2D 空間。物體空間哈希把物體空間三維坐標帶入以后要進行線性同余計算和偏移，這個偏移是直接加上去的，不同的體素加的偏移可能不一樣，絕大部分是連續的。也就是說，我們能保證在物體空間哈希中相鄰的 3D 空間體素點能對應到 2D 空間點，如果有碰撞的話才會進行偏移，大部分的偏移比較小。我們對 3D 映射到 2D 空間并不能完美利用 2D 空間，但是能做到占用率 95% 以上，這是物體空間哈希分頁方法。

Attribute buffer 還支持世界哈希空間方法，這是大概 2022 年以后流行的方法。這個方法還是把世界空間分成體素，但并不是連續存儲，而是根據體素坐標進行一個哈希計算。一般進行兩次哈希計算保證不碰撞，對于體素周圍一定空間范圍內的體素合并到一個哈希格子，采用 “8×8×8” 的范圍，這個范圍之內所有的格子是連續存儲的，在格子之外是離散存儲的。

世界空間哈希表方法相對于分頁方法完全不需要預處理，但是有一個問題是占用存儲空間多一些。我們在整個系統中分了多個不同的抽象接口，包括射線檢測、Attribute buffer、final gather，每個都有不同的實現方式，也會去平衡存儲量和動態性，往往是預計算多一些的方法能更有效利用空間。在一些更高端的平臺上，我們會采用更加不需要預處理的方法。

我們會看到線性分頁無論是去劃分 AABB，還是對物體進行空間哈希都需要進行預處理，空間哈希主要計算每個點的偏移量。

最終聚集

最后介紹一下最終聚集過程。我們說到最終從 G-Buffer 出發，打出光線去采樣剛才說的粗粒度場景表示。因為 G-Buffer 存了屏幕上的高頻場景信息，包括每個像素的深度以及法線，還有一些材質信息，我們從屏幕空間出發進行 Screen Space Ray Marching，跟正常的 SSRT 走的流程是一樣的，只是說反映的范圍有限。如果超出范圍以外，我們才會去使用粗粒度場景。如果粗粒度場景用了 GPU 的 SDF，比正常物體會大一圈，因為知道 UDF 對于比較薄的物體是可以正常表示的，但是 SDF 不知道比較薄的物體處于哪一面，無法正常表示。UDF 的問題在于如果按照正常采樣出的距離步長來算，可能打不到這個物體，會把距離加上偏移值。導致 distance field 比三角面表示的物體會更大一圈，采用 screen space GI 能得到更精確的結果。

距離場比物體大一圈，會導致渲染結果產生過度遮擋 over occlusion，使畫面對應部分偏暗。但因為不可能每個 G-buffer 像素都發出光線，實際上發出光線少于屏幕像素數，會有 under occlusion，這兩者不能完全抵消，但是能使畫面更加自然。得到的結果雖然不完全符合物體，但是二者的效果會達到平衡。這是最終聚集的過程。

我們看一下運算過程。最終聚集有多種實現方式，有FullScreen ReSTIR和基于 Probe 的方式，基于 Probe 是把屏幕劃分成像素塊，每個像素塊是 8、16 個像素，對應是一個八面體投影的體積，有點類似于 light probe，只是這個 probe 是在屏幕空間。如果直接對它從像素出發，需要的發射光線數量很多，但如果是 16×16 probe，只發出 “8×8” 的光線，會減少總光線發射數量。

我們再看一下 FullScreen ReSTIR 的方式。我們把每個像素之前位置、速度、上一幀光照信息進行存儲，對相鄰的像素和上一幀像素進行復用，會進行多次時間、空間復用。因為我們知道屏幕上每個像素只發出一根光線的話，不能累計其他方向的數據，但相鄰的像素是有這個數據的，我們只需要復用周圍的像素信息，就可以實現提升整體效果。

對于 Screen Probe 來說，它也有一個 ReSTIR 累計方式。我們可以看到相鄰的 screen probe，也可以有一定的數據復用。另外對于 screen probe，如果沒有采用 ReSTIR 方式，會進行兩步過濾，首先是 probe 級別的過濾，用到相鄰的像素，但并沒有存儲 ReSTIR 一樣多的信息，所以復用的結果更差一些。但是第二步還會進行像素級別的過濾，像素級別會復用上一幀的數據。進行 Probe 級別的過濾之后噪點會降低一部分，不能完全消除，進行像素級別的過濾后，噪點是完全消除掉的，這是兩步過濾。

還有歷史信息積累不足的問題，我們也有world radiance cache，這是世界空間體素的數據結構，這個數據結構是累計了之前 screen probe 的計算結果，不足的時候會進行補充，也就是從 world radiance cache 出發采樣光線，分辨率很低就足以實現對 screen probe 的補充。ReSTIR 這些算法已經很多用到實時渲染中。

未來工作

我們現在兼容性支持了HDRP，URP 還在支持中。我們對于材質支持了 HDRP lit 材質和 shader graph 材質，現在對于 alpha test 是支持的，透明材質也是在支持中。

另外，我們目前支持 Windows 平臺，計劃繼續支持移動平臺，并針對 URP 進行足夠優化。移動平臺主要硬件是 Vulkan 1.1，我們在 Vulkan 1.1 硬件特性上是完全能實現之前的方法。但是之前的方法有一定的問題，就是 GPU SDF 更新是比較慢的，也會很占帶寬，需要進一步優化。現在有更多的把場景進行體素化的方法，比如說 ROMA 之類的方法，它利用二進制的運算去體素化場景，這些方法對帶寬的占用更低。我們會開放更多的接口，包括粗粒度的場景表示，還有 final gather，讓用戶自定義去實現。我們也會盡量地去優化 GPU SDF 在移動平臺的表現。

最后是我們用到參考文獻。謝謝大家！

團結引擎是 Unity 中國的引擎研發團隊基于 Unity 2022 LTS 版本為中國開發者定制的實時 3D 引擎；基于 Unity 的核心能力，團結引擎團隊傾聽中國開發者的聲音和需求，為團結引擎加入了一些中國開發者需要的定制化功能，并會在未來持續不斷為中國開發者量身定制需要的功能。團結引擎 1.3.0 版本現已上線，歡迎點擊閱讀原文下載體驗。

[1]團結引擎官網：

https://unity.cn/tuanjie/tuanjieyinqing

[2]團結引擎問答專區：

https://developer.unity.cn/plate/tuanjie-engine?tab=ask

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發技能

每一個“在看”，都是我們前進的動力