在Unity裡，可以用兩種不同的技術來計算全域光照GI或光源反射，就是烘焙全域光照(Baked GI)和預計算即時全域光照(Precomputed Realtime GI)。
當啟用PRGI時，一個光照預計算就是用來計算靜態幾何物件周圍光的反射，並存成資料給Runtime執行使用的一個過程。這個過程減少了原本必須在Runtime執行時的光照計算數量，讓專案得以在保持FPS的穩定之下還能計算光的反射。
當啟用烘焙GI(Baked GI)時，預計算的過程會計算並產生傳統的光照貼圖(Lightmap)，這些貼圖會以資源(Assets)的形式存在專案中，而且無法再Runtime執行時更改。PRGI並非用一樣的方法產生光照貼圖，相反的，PRGI算好的結果會被存成一個光照資料檔(Lighting Data Asset)，這個資料檔存的資料能讓專案在Runtime執行時能即時產生一組低解析度的光照圖。
Realtime Resolution的值可以由你的遊戲規模來制定，例如，是否你的場景是一個小小的，卻有豐富光照變化的室內環境? 在這種情況下，高一點的值比如2-3，可以捕捉更詳細或"高頻"的光照。
如果你的場景是一個世界規模較大的大型戶外環境。可能有著幾千或幾百個物件表面幾乎不會去修改光照反射顏色。在這樣的情況下，把適合計算複雜室內場景的設定用在有大量相同特徵的室外環境是很浪費的。我們會浪費寶貴的CPU時間和記憶體儲存/更新那些對整體外觀貢獻不大的光照貼圖。為了教學目的，我們會提高PRGI期間必須考慮貼圖像素的量，這會對預計算的時間造成很大的影響。
在場景裡有大物件的室外環境情況下，合適的設定可以設在0.5-1之間，針對地形可以設定0.1-0.5之間。
場景與Realtime Resolution值對照表
室內:2-3 像素/單位
戶外:0.5-1 像素/單位
地形:0.1-0.5 像素/單位
Unity PRGI所需要的Realtime Resolution值比傳統光照貼圖密度要小好幾個等級，這是因為我們只從這些光照圖裡擷取間接光源資料，這些資料通常解析度都很低。所以使用PRGI時，清晰的陰影通常都是即時運算而非從高解析度的光照圖來提供。
在這裡使用傳統光照慣用的值，例如:30 texels，可能會導致預計算失敗或無法計算。
當設定場景即時解析度時，Unity會指定給場景內的靜態物件。帶有Mesh Renderer且標有靜態光照標籤(Lightmap Static)的物件，會引用這個值一直到它被外力修改。
除了幫場景加上解析度設定外，我們還能針對每個物件調整光照貼圖的解析度，在需要高解析度來提供更高真實感的情況下，我們可以選擇性的提高這個值。通常是將場上最多的物件解析度設為預設值，然後手動調高需要更多照明細節物件的值。
runtime resolution 0.5
runtime resolution 1
runtime resolution 2
我們已經理解場景裡的圖表數量對預計算時間的影響，這樣我們就能從預計算流程裡想辦法降低一些物件計算來讓光照效能大躍進，同時也會減少圖表產生的數量．取而代之的，我們可以對這些物件做光照探測(Probe Lighting)處理，它是一種讓物件接收場景間接照明的好方法，雖然被光照探針指定的物件無法計算場景的光照反射，但通常影響不大。這種方法非常適合用在場景裡的小物件，因為小物件對光照反射計算幾乎沒什麼影響。
光照探測技術是一個能在遊戲裡讓即時光照更逼真的快速演算法，通常會用在處理遊戲世界的人物角色或是動態物件的光照，它的優點在於Runtime處理效能佳而且還能預先計算好。
使用光照探測是有些限制的，其中一個限制是在不提高探針數量的前提下很難在球型範圍上表現出高頻或斑駁的光照，但精度和消耗成本成正比，代表在效能的前提下，我們必須限制較低階的球諧函數。
實際上一個3D座標只能用一個球體來紀錄照明資料，所以光照探測不適合用在有大量光照投射在大物件的狀況。另外一個限制是當用球諧函數在一個球體上編碼時，通常不擅於處理用有廣大平面的物件或帶有很深的凹洞的物件．如果你正計畫要把光照探測技術用在大型物件上，Unity有提供另一個光照探測代理體(Light Probe Proxy Volumes,LPPV)的技術可以參考手冊說明。
儘管有這些限制，光照探測還是很適合和符合條件的小物件一起搭配使用，產生成本低廉效果卓越的結果。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。