隨著各大計算平臺的算力穩步增長，特別是GPU技術的不斷進化，原先可望而不可及的技術比如實時光線追蹤技術開始逐步走入玩家的視野。一些先鋒廠商甚至已經超出Demo的範疇，開始正式推出支持實時光追的遊戲。
不過目前的實時光追技術還只能在配備了最新Nvidia RTX 20系列顯卡的PC機上才能實現（前一代Nvidia 10系列顯卡，比如GeForce 1080，1070，甚至1060也可以用軟體實現實時光追，但是總體效果不佳）。
大多數玩家所在的移動平臺上，目前並沒有實時光追技術被正式推出。雖然有廠商如Imagination Technologies推出了移動端實時光追的架構設計和演示Demo（可查看Imagination官網：https://www.imgtec.com/powervr-ray-tracing/），但是這些技術要在主流手機廠商如華為，蘋果，三星，小米等那裡得到實際應用，還有一段不短的路程要走。
因此我們今天來聊一下一項「老」技術：光照貼圖烘焙。雖然實時光追非常誘人非常好，目前來說要想實現好的光照效果，我們還是要依賴光照貼圖烘焙技術來實現。
本文將以問答的方式來講解Unity 2019.4版本中的Progressive Lightmapper（Unity 2018等之前版本中的Enlighten已在2019.4中正式棄用）。之所以選擇問答的形式原因如下：
大家閱讀時可以看完一個問題的解答隨時停下來。
便於大家事後查找相關內容。
如果本文中遺漏了什麼問題，大家可以在留言區留言，我們可以下次通過文章或者B站視頻（B站搜索「Unity官方」）的方式集中回答。
什麼是光照貼圖（Lightmap）？
為什麼要用光照貼圖？
場景中的光照信息大致可以分成兩類：直接光照和間接光照。
只有直接光照的情況
直接光照+間接光照的情況
如果沒有間接光照，那麼整個場景就沒有真實性可言。但是間接光照的實時計算在目前的硬體條件下，只有支持實時光線追蹤的硬體才能實現，比如Nvidia的RTX系列顯卡。在普通的計算設備上，特別是移動端設備上目前還沒有實時光線追蹤的解決方案出現。因此我們必須依賴預先計算好的光照貼圖來提供這些間接光照信息。
光照貼圖本質上就是一張或者多張應用在場景模型上的貼圖。它們包含的是通過光照貼圖烘焙方式進行預計算所獲得的間接光照，陰影等信息（可以在烘焙時選擇只烘焙間接光照，不烘焙陰影）。使用光照貼圖可以避免在遊戲運行時進行實時的光照和陰影計算，提高遊戲的運行性能，特別適合用於性能較弱的計算平臺比如移動平臺上。
要在Unity中預計算（或者說烘焙）獲得光照貼圖，我們使用的是Unity官方研發的Progressive Lightmapper（漸進式光照貼圖烘焙）。在Unity 2018版本之前，Unity中集成的光照烘焙模塊是一套第三方解決方案Enlighten。由於第三方廠商Geomerics不再維護Englighten，所以從Unity 2019版本開始Enlighten被標記為棄用狀態（Deprecated）。Unity 2021.1版本開始將完全移除Englighten模塊。
ProgressiveLightmapper基於AMD的Radeon Rays技術（https://gpuopen.com/radeon-rays/）開發。RadeonRays是一套支持跨平臺的ray intersection庫（如大家對Radeon Rays技術感興趣，可以參考網址：https://gpuopen.com/radeon-rays/）。
漸進式光照貼圖烘焙
對場景中模型的要求是什麼？
使用漸進式光照烘焙對模型有以下幾個要求：
1. 模型上不能有重疊的UV。
2. UV之間要有足夠的間距以避免「滲色」現象的發生。
3. 因為光照貼圖只能烘焙靜態物體，所以我們要把需要參與烘焙的物體標記為Static。
以下為具體說明：
1. 模型上不能有重疊的UV。我們可以嘗試使用Unity的ImportSettings窗口中的Generate Lightmap UVs來生成第二套UV（記得在勾選複選框以後點擊Apply按鈕）：
但是通常建議大家在建模軟體中製作第二套UV，因為光照貼圖烘焙用的UV與普通紋理貼圖的UV有所不同。
Unity中並沒有內置的模型UV查看功能，這裡介紹一個Unity資源商店中的小工具UV Inspector，如下圖所示：
下面兩張圖是在Unity中使用UV Inspector的界面。在Scene窗口選中模型以後，UV Inspector界面就會顯示當前模型包含的所有UV。左側為第一套UV用於紋理貼圖；右側為第二套UV用於光照貼圖烘焙：
2. UV之間要有足夠的間距以避免「滲色」現象的發生。「滲色」的發生因為兩塊UV之間的間隔不足，導致一塊UV上的顏色「滲透」到了相鄰的UV上。
3. 因為光照貼圖只能烘焙靜態物體，所以我們要把需要參與烘焙的物體標記為Static，如下圖所示：
如上圖所示，我們習慣上直接在Game Object上勾選右上角的Static複選框，然後把層級中所有物體標記為Static。不過對於光照貼圖烘焙有意義的兩項是Contribute GI和Reflection Probe Static，因此你也可以只勾選這兩項。
上圖中的Contribute GI（貢獻全局光照）選項和Mesh Renderer中的Contribute Global Illumination（貢獻全局光照）是聯動的。如果我們勾選右上角的Contribute GI，Mesh Renderer組件中的Contribute Global Illumination也會被勾選，Receive GlobalIllumination（接受全局光照）則會被設置為Lightmaps，意指當前Game Object會使用光照貼圖獲取間接光照。
我們也可以把Receive Global Illumination設置成Light Probes，這時間接光照信息就會來自相關的光照探針（Light Probes）。
漸進式光照貼圖烘焙對硬體的要求是什麼？支持Unity的哪些渲染管線？
硬體要求：
1. 至少需要一塊支持OpenCL 1.2的顯卡
2. 至少2GB的顯存
3. CPU支持SSE4.1指令
支持的渲染管線：
1. 內置渲染管線（Built-in Render Pipeline）：支持Baked Indirect，Subtractive和Shadowmask光照模式。
2. 通用渲染管線（Universal Render Pipeline，簡稱URP）：支持Baked Indirect，Subtractive和Shadowmask光照模式。
3. 高清渲染管線（High Definition Render Pipeline，簡稱HDRP）：支持Baked Indirect和Shadowmask光照模式。
因為用於烘焙測試的兩個場景都是基於HDRP來製作的，所以接下去的講解我們將會圍繞HDRP的光照烘焙模塊來進行。
漸進式光照貼圖烘焙出來的是什麼？
光照貼圖烘焙出來的是光照貼圖（Lightmaps），光照探針（Light Probes）和反射探針（Reflection Probes）。
按照不同的Lighting Mode（光照模式），光照貼圖烘焙出來的結果是不同的。
HDRP下Lighting窗口的光照模式支持Baked Indirect和Shadowmask兩種（內置渲染管線和通用渲染管線請參考文檔）。
1. Baked Indirect模式：
如果場景中的燈光模式設置為Mixed，那麼這些燈光會給場景提供直接光照，間接光照信息則被烘焙到光照貼圖和光照探針中。此選項適合中高端的平臺，比如PC，主機。
2. Shadowmask模式：
如果場景中的燈光模式設置為Mixed，燈光會給場景提供直接光照，間接光照烘焙到光照貼圖和光照探針中。Shadowmask和光照探針遮擋信息會被烘焙到陰影信息中。你可以在Project Settings > Quality窗口設置Shadowmask的模式（Shadowmask或者Distance Shadowmask兩種模式可選）。此選項在遊戲運行時比Baked Indirect模式性能更好，因為光照貼圖中已經預先烘焙了陰影信息。
3.Subtractive模式：（在內置和通用渲染管線中支持）
場景中的直接光照，間接光照和陰影信息都會烘焙到光照貼圖中。適合對性能敏感的平臺比如移動端平臺。
如果場景中光源設置為Mixed模式，在三種光照模式下動態和靜態物體的行為可參考以下列表：
註：上述總結自Unity文檔：https://docs.unity.cn/2019.4/Documentation/Manual/lighting-mode.html
以上對比中的Shadow Distance在三種不同渲染管線中設置的方式是不一樣的，以下為設置詳解。
（1）內置渲染管線：
打開Edit > Project Settings > Quality> Shadows > Shadow Distance。
（2）URP通用渲染管線：
打開Edit > Project Settings > Graphics中選擇UniversalRenderPipelineAsset進行設置。
（3）HDRP高清渲染管線：
通過在場景中使用的Volume進行設置。
界面操作（HDRP示例）：打開Window > Rendering > Lighting Settings窗口，在Mixed Lighting區域勾選Baked Global Illumination複選框，然後在Lighting Mode中選擇光照模式：
註：HDRP中不支持Subtractive光照模式
漸進式光照貼圖烘焙的CPU版本和GPU版本有什麼區別？
CPU和GPU兩個版本所用的底層技術相同，唯一的區別是：CPU版本使用CPU和內存進行計算；GPU版本使用顯卡和顯存進行計算。
1. 如果使用CPU版本進行烘焙，影響烘焙效率的是CPU的速度和內存的大小。
2. 如果使用GPU版本進行烘焙，影響烘焙效率的則是顯卡的速度和顯存的大小。
界面操作（HDRP示例）：打開Window > Rendering > Lighting Settings窗口，在Lightmapping Settings區域可以選擇使用哪個版本的ProgressiveLightmapper：
Lighting界面上那一堆參數理解一下？
選擇好Lighting Mode和Lightmapper，我們來看一下具體的烘焙參數。確保打開Window > Rendering > Lighting Settings窗口。
在HDRP中進行光照烘焙時可以為整個場景指定一個用於烘焙的天空盒作為環境光，如下圖所示：
我們可以在這裡使用當前HDRP場景中使用的天空盒設置，也可以使用不同的天空盒設置。當然，如果你使用相同的天空盒，那麼烘焙所得的光照貼圖將會擁有與當前場景一樣的環境光。
內置和通用渲染管線的環境光設置參數：
註：上圖中的設置不在此詳細講解，可以參考中文文檔中的具體描述：https://docs.unity.cn/cn/current/Manual/GlobalIllumination.html
接著我們來看具體的烘焙參數。如下圖所示，光照貼圖烘焙窗口中Lightmapping Settings區域的這些參數在UI上目前是放在一起的，這麼多密集擺放的參數對於新用戶來說一眼看上去會有不知所措的感覺，下文會一一進行介紹：
1Prioritize View：
啟用此選項，如果Scene窗口打開，系統會逐步烘焙Scene窗口看到的畫面，然後再繼續烘焙Scene畫面之外的場景區域。
如果你在Scene窗口移動場景中物體，改變物體和燈光屬性或者改變Scene窗口畫面等操作，烘焙會及時調整，快速逐步烘焙改變後的畫面。
通過這個方式，我們可以快速預覽Scene窗口當前畫面的間接光照信息，及時做出相應修改，加快迭代速度，而不必像之前使用Enlighten時需要等待烘焙全部完成以後才能看到結果。
在使用此選項時記得打開Auto Generate（自動生成）複選框。
2採樣設置相關：
此區域的設置跟烘焙時所用的採樣方式和採樣數值相關。
Multiple ImportanceSampling：（默認是禁用狀態）這是針對環境光採樣的設置。如果開啟，可以縮短光照貼圖的生成時間，但是在場景中某些較暗的地方會產生明顯的噪點。
Direct Samples：用於設置從每一個紋素（Texel）射出的採樣路徑數（針對直接光照）。數值越大效果越好，烘焙時間也越長。
Indirect Samples：用於設置從每一個紋素（Texel）射出的採樣路徑數（針對間接光照）。數值越大效果越好，烘焙時間也越長。針對戶外場景，指導數值為100。室內場景（包含自發光物體），可以按需增加採樣路徑數直到看到效果。
Environment Samples：針對環境光的採樣數。數值越大效果越好，烘焙時間也越長。默認數值為500。
Light Probe SampleMultiplier：如要使用此功能，必須在Project Settings > Editor> Graphics中禁用Use legacy Light Probe sample counts，如下圖所示：
此數值會被用於分別乘以Direct Samples，Indirect Samples和Environment Samples這三個數值。這三個數值會被應用於LightProbes採樣。數值越大效果越好，烘焙時間也越長。
Bounces：此數值用於控制計算光子彈射時的反彈次數，一般2次可以滿足普通場景的需求。
3降噪設置相關：
Filtering區域的設置用於光照貼圖的降噪操作。降噪操作本質上是一個針對已經烘焙好的光照貼圖做後處理的過程。
如果啟用Filtering功能，系統會在把光照貼圖的Direct，Indirect和AmbientOcclusion這三部分信息結合之前，分別為這三個部分應用降噪算法。
我們可以選擇Auto（自動）或者Advanced（高級）兩種方式。
自動：Progressive Lightmapper會自動選擇一個當前機器支持的降噪算法應用到光照貼圖上（因為規則是固定的，所以具體規則請參考Unity文檔）。
高級：可以為Direct，Indirect和Ambient Occlusion分別選擇降噪算法（Denoiser）或者降噪濾鏡（Filter）。如果你有支持Nvidia Optix降噪算法的GPU，可以選擇Optix；如果有支持RadeonPro降噪算法的GPU，可以選擇RadeonPro；在任何情況下，都可以選擇基於CPU的降噪算法OpenImageDenoise。
關閉降噪設置
關閉降噪設置烘焙結果
打開降噪設置
打開降噪設置烘焙結果
除了使用Optix，Radeon Pro和OpenImage Denoiser這一類具備AI功能的降噪算法之外，我們也可以進一步使用降噪濾鏡，比如以下配置：
這裡的Guassian（高斯）濾鏡會在降噪算法之後在光照貼圖上做進一步的模糊處理，以減少光照貼圖中的噪點。
註：內置渲染管線和通用渲染管線還支持A-Trous濾鏡。此濾鏡會在儘量減少光照貼圖中噪點的同時降低模糊的效果，因此通常比高斯濾鏡的效果更好。
4光照貼圖解析度和大小相關：
這裡涉及三個參數：Lightmap Resolution，Lightmap Padding和Lightmap Size。
Lightmap Resolution（光照貼圖解析度）：數值單位為texelsper unit（每單位面積的紋素）。
Texel（紋素）有別於Pixel（像素）。像素是圖片的基本單位，如果我們在圖片編輯軟體中把圖片放大到足夠大，可以看到這些圖片由許多正方形的像素組成，所以像素是屏幕空間的概念。紋素則是紋理貼圖的基本單位，紋理貼圖是應用於模型上的，所以並不是屏幕空間的概念。
在模型被繪製到屏幕上時，紋素會被轉換成屏幕上的像素展現出來。我們可以通過網絡上找到的這張圖來理解像素和紋素之間的對應關係：
像素和紋素最大的區別是：像素其實就是圖片數據；但是紋素可以代表很多類型的數據，它可以是紋理貼圖，也可以是用於計算陰影的深度圖。
光照貼圖本質上是紋理貼圖，因此Progressive Lightmapper在這裡用紋素而不是像素來代表光照貼圖的解析度。
Lightmap Padding（光照貼圖間距）：數值單位為texel（紋素），默認值為2。烘焙好的光照貼圖中包含很多Charts。這些Charts可以理解成對應模型上包含烘焙光照信息的UV色塊。在遊戲運行時，這些色塊會與模型網格進行映射，完成最終效果的計算（在模型原先的紋理上疊加烘焙的光照信息）。但是這些「色塊」之間必須保持一定的距離才能確保模型上一個部位的顏色不會「滲色」到另一個部位。
Lightmap Size（光照貼圖大小）：數值單位為像素，默認值為1024。根據Lightmap Resolution和Lightmap Padding的參數設定，烘焙出來的光照貼圖數量會相應的變化。這裡的大小其實代表的是每張光照貼圖的最大尺寸。按照實際需求，即使設置了2048，某些光照貼圖的尺寸也有可能是1024或者512。
接下去我們用一組測試數據來說明上述三個參數的關係（使用的項目是上面的夜間場景）：
從上述測試數值可以總結如下：
Lightmap Resolution越大，烘焙時間越長，光照貼圖越精細。
Lightmap Padding越大，光照貼圖的數量越多，但是可能可以減少提示UV重疊的模型數量。
Lightmap Size越大，光照貼圖的數量越少，光照貼圖越精細。
以下截圖是配置-6的烘焙參數和結果：
從上圖中可以看到，在提高了Lightmap Resolution，增加了Lightmap Padding數值和Lightmap Size數值以後，從原先的119個UV重疊的物體下降到了94個UV重疊的物體。
那麼UV重疊到底是什麼意思？是因為我們在製作模型解UV的時候沒有做到UV之間保持足夠距離嗎？
出現這個黃色警告信息的原因有以下幾種（我們也列出了可能的解決方法）：
模型上用於光照烘焙的UV確實存在重疊：
在Console界面我們可以看到警告UV重疊的信息中包含了具體哪個模型有這個問題。我們可以具體看一下這些模型的UV（這是用於光照貼圖烘焙的第二套UV。如果沒有這套用於光照烘焙的UV，我們需要手動生成或者用Unity的模型導入界面來生成這套UV）。
如果模型的原始UV確實存在重疊，我們可以通過外部建模工具來修復。
模型上用於光照烘焙的UV不存在重疊：
如果看下來其實所有模型的原始UV都不存在問題，在實際烘焙好光照貼圖的場景中也看不出有什麼「滲色」的情況，我們可以忽略這個警告。
當然我們可以嘗試提高Lightmap Resolution和增加Lightmap Padding的方式來提高光照貼圖的精度，從而減少出現在警告中提示UV重疊的物體數量。不過要注意這會影響烘焙所需的時長，以及增加的光照貼圖的大小。
5Compress Lightmaps：
默認啟用，對光照貼圖進行壓縮操作。雖然壓縮過的光照貼圖可以減少內存佔用，但是也會導致光照貼圖質量下降。
6Ambient Occlusion相關：
環境光遮蔽用於為場景中的某些區域比如裂縫，孔洞，牆面的交界處，或者任何兩個物體相鄰的區域添加類似於陰影的效果。它會讓這些地方變得比其他地方更暗一些。此處的設置會把這些環境光遮蔽信息烘焙入光照貼圖中。
在HDRP中，我們可以在Volume中設置Ambient Occlusion，不過那是針對當前攝像機看到的區域來計算的基於屏幕空間的實時環境光遮蔽，屬於實時計算的範疇。Volume中設置的實時環境光遮蔽效果，可以通過Window > RenderPipeline > Render Pipeline Debug窗口，把Lightings設置的Full Screen Debug Mode設置為SSAO（Screen Space Ambient Occlusion），就能看到基於屏幕空間的環境光遮蔽效果（紅色箭頭區域為部分AO效果）：
Max Distance（最大距離）：
為了計算出一個物體是否被另一個物體擋住從而算出相應的環境光遮蔽效果，系統需要使用射線來做偵測之用。此參數用於控制射線的長度。
射線的長度越長，光照貼圖中由環境光遮蔽產生的陰影區域越多，反之越少（只有相鄰很近的物體之間才會有環境光遮蔽產生的陰影）。
如果設置為0，意味著此射線為無限長；默認數值為1。因為數值0代表射線長度無限長，所以畫面中的環境光遮蔽明顯暗很多。
左滑查看效果對比
Indirect Contribution（間接光貢獻）：數值在0到10之間，默認數值為1。此參數用於控制間接光強度對環境光遮蔽的影響。
下面三張圖比較了不同Indirect Contribution數值對畫面整體的環境光遮蔽造成的影響，可以看到IndirectContribution越大，環境光遮蔽越暗（紅色線條標出的區域最明顯）。
左滑查看效果對比
Direct Contribution（直接光貢獻）：數值在0到10之間，默認數值為0。此參數用於控制直接光強度對環境光遮蔽的影響。
7Directional Mode（方向模式）：
Directional：此模式下會生成第二套光照貼圖，專門用於保存入射光的主要方向信息。使用法線貼圖的材質可以利用這張光照貼圖上的方向信息，在計算法線貼圖時加入光照貼圖中保存的全局光照信息。不過此模式下生成的光照貼圖通常比Non-Directional模式下生成的光照貼圖大一倍。（此模式下生成的光照貼圖無法在SM2.0和GLES2.0硬體上解碼使用。在這些硬體上會回退到Non-Directional模式）。
Non-Directional：禁止烘焙時生成第二套用於保存入射光主要方向信息的光照貼圖。
8Indirect Intensity和Albedo Boost：
Indirect Intensity（間接光強度）：用於控制光照貼圖中保存的間接光強度。數值限定在0到5之間。默認數值為1。數值大於1會增強間接光強度，小於1會減弱間接光強度。
Albedo Boost（反射率增強）：用於控制物體表面之間光子彈射的數量。默認數值為1。數值限定在1到10之間。數值越大，物體表面的反射率越趨向於白色。
9Lightmap Parameters：
用於控制各項烘焙相關的參數。你可以使用預設的參數也可以自行創建參數並保存下來以便復用。
除了在烘焙窗口可以全局指定這些預設的參數，你也可以為場景中參與烘焙的模型的Mesh Renderer組件單獨指定預設的參數，示例如下圖所示：
不同顯卡對GPU版本的烘焙效率有什麼影響？
為了讓大家更好地理解不同顯卡配置和顯存大小條件下，對GPU版本光照貼圖烘焙效率的影響，我們專門配置了三臺機器做烘焙測試。三臺機器的配置信息如下：
感謝Nvidia中國和攀升為這次測試提供相關測試機器（IPASON D 系列設計師電腦，官網：http://ipason.com/）。
以下是不同配置下6組光照烘焙參數配置所用的烘焙時長。
1辦公室場景烘焙測試
左滑查看烘焙結果對比
2斯蓬扎場景夜間場景烘焙測試
左滑查看烘焙結果對比
總結：用於測試的三塊顯卡Nvidia GeForce 2060s，2070s和2080Ti的區別是它們的CUDA核心和顯存大小。可以看到無論是什麼樣的參數配置：CUDA核心越多，顯存越大，烘焙時間越短。所以我們可以說：不差錢的直接上2080Ti，畢竟烘焙這塊可以給你節省很多迭代時間；入門級可以考慮2060s，因為性能也不差。
相同場景使用CPU烘焙需要多長時間？
使用斯蓬扎夜間場景，烘焙參數和烘焙時長如下。與GPU版本相比，CPU版本所需的烘焙時間明顯偏長。
可能大家會問：既然GPU版本那麼快，為什麼還要CPU版本？
答案是：進行光照貼圖烘焙時，GPU版本使用的是顯存。就目前的顯卡來說，顯存總是有限的，我們也無法像添加內存那樣可以自行添加（內存也相對便宜很多）。如果當前場景在烘焙時所需的顯存空間超出了當前顯卡具備的顯存大小，那麼GPU版本就會停止工作。這時我們就需要一個後退的方法，那就是CPU版本來救場了：在烘焙過程中，如果Unity發現顯存耗盡，Unity會把GPU版本自動切換到CPU版本。
為什麼GPU版本開始烘焙以後，
有時候會自動切換成CPU版本？
GPU版本自動切換到CPU版本的原因是當前系統的可用顯存不足，GPU版本無法繼續進行正常的烘焙操作。
從GPU版本到CPU版本的切換會發生在準備烘焙階段。在Unity編輯器的Console窗口可能會出現兩段黃色的警報信息（第一段必出），示例圖如下：
OpenCL報錯：後退到CPU光照烘焙。後面一段的意思就是顯存不足了。
（可能出現）這一段是說降噪處理失敗。請嘗試警用降噪處理或者降低光照貼圖大小。
我們在使用GPU烘焙的時候，需要注意的是：等待Prepare Baking…這個階段結束，開始Baking的時候看是否會切換到CPU版本，如下圖所示：
如果看到Baking…[ETA: xx:xx:xx]，觀察到沒有切換到CPU版本的話，你可以放心之後會繼續用GPU版本進行烘焙了。否則如果這時候你離座去幹個別的事情，可能回來一看烘焙時間翻了10倍：因為自動切換到CPU版本。
如何避免GPU烘焙自動切換成CPU烘焙？
因為場景中參與烘焙的資源量大小是不一樣的，所以完全避免切換是不可能的。
通過前面不同型號的GPU烘焙測試，可以知道確保能夠在場景中使用GPU烘焙的前提條件是當前系統可用顯存的大小。因此能否使用GPU烘焙就看我們的系統能否省出足夠的顯存給漸進式光照烘焙這個模塊用。以下是一些節省系統顯存的方法：
1. 如下圖所示，通過頂部菜單Edit > Project Settings打開項目設置界面，在烘焙開始之前將Texture Quality調整為Eighth Res，意思是在Scene窗口和Game窗口只使用紋理貼圖的1/8尺寸進行顯示。（默認為Full Res：意思為使用完整尺寸的紋理貼圖進行顯示）。烘焙結束之後調整回Full Res。具體設置界面如下圖所示：
2. 在烘焙過程中如果不需要查看漸進式的烘焙過程，可以隱藏Scene窗口和Game窗口，比如像下圖一樣將Project Settings窗口覆蓋在最上層：
3. 將場景切分成多個小場景，使用多場景的方式進行加載。這樣可以針對各個小場景進行烘焙。
結語
漸進式光照貼圖烘焙系統為我們提供了快速迭代的工作流和整個烘焙時長的預估，完全改變了之前使用Enlighten系統時對所需烘焙時長完全靠猜，以及光照貼圖烘焙效果要等到烘焙完成以後才能看到的問題。這大大加快了光照烘焙的速度，也讓燈光美術師有了更多的自由度獲得自己想要的效果。
不過要想用好這個系統，除了需要深入了解每個參數背後的意義，使用不同的場景（戶外，室內，或者像斯蓬扎這種既有室內部分也有戶外部分的場景）針對不同的參數做各種測試是非常關鍵的。通過這些測試練習，我們可以增加對這些參數以及這些參數之間如何配合的直觀感受，有助於我們日常工作中在面對不同類型的場景時，能夠在保證速度的情況下，烘焙出高質量的光照貼圖。
每一個「在看」，都是我們前進的動力