選擇一種光照技術（Lighting Technique）
廣義上說，Unity中的光照可以被認爲是“實時（Realtime）”或“預先計算（Precomputed）”，這兩種技術可以組合使用來創建身臨其境的場景光照。
在本節中，我們將簡要介紹不同技術提供的機會（Opportunities ），相對優勢和個性化特徵。
實時光照（Realtime Lighting）
默認情況下，Unity 中的燈光——方向光（Directional Light）、點光（Point Light）、聚光燈（Spotlight）都是實時的。 這意味着它們可以直接向場景做直接光照，並在每一幀中更新。 隨着燈光和GameObjects 在場景中移動，光照會立即更新， 這在場景和遊戲視圖中可以觀察到。
這是實時燈光（ Realtime light ）單獨作用的效果。 注意，陰影是完全黑色的，因爲沒有反射過來的光。 只有落在聚光燈（Spotlight）錐體內的表面纔會受到影響。
實時光照（Realtime Lighting）是在場景中照明物體的最基本的方法，對於照亮人物或其他可移動幾何物體是很有用的。
但不幸的是，Unity 中的實時燈光（Realtime lights）的光線（Light rays）在只有它們自己時是不會反射的。爲了使用全局光照等技術創造更逼真的場景，我們需要啓用 Unity 的預先計算（Precomputed）的光照解決方案。
烘焙全局光照（Baked GI Lighting）
當“烘焙（Baking）”一個“光照貼圖（Lightmap）”時，會計算場景中光線對靜態物體的影響，並將結果寫入疊加在場景幾何頂點上的紋理（Textures），以產生照明效果。
左：一個簡單的使用光照貼圖的場景。 右：Unity 生成的 Lightmap 紋理。 注意如何陰影和光照信息是如何捕獲的。
這些“光照貼圖”可以包括撞擊表面的直接光以及從場景中其他物體或表面反射的“間接”光。這種光照紋理可以通過與物體材質（Material）相關聯的“着色器（Shader）”與表面信息如顏色（反照率）和浮雕（法線）一起使用。
使用烘烤光照，這些光照紋理（即光照貼圖 Lightmap）在遊戲過程中不能改變，因此被稱爲“靜態（static）”。實時燈光可以疊加在一個使用光照貼圖的場景之上，而不能自動地交替地改變光照貼圖。
通過這種方式，我們可以給予遊戲中的燈光效果一個潛在的性能提升，從而適應不那麼強大的硬件平臺，如移動平臺。
預計算實時全局光照（Precomputed Realtime GI Lighting）
雖然傳統的靜態光照貼圖無法對場景內光照條件的變化作出反應，但預計算實時全局光照（也稱預計算實時GI）爲我們提供了交互式的實時更新複雜場景光照的技術。
通過這種方式，可以創建具有豐富的全局光照的光環境，並具有反射光，實時響應光照變化。一個很好的例子就是 time of day system —— 燈光的位置和顏色隨着時間的推移而變化。使用傳統的烘烤光照，這是不可能做到的。
一個簡單的例子，實現了一天中隨着時間的變化燈光角度和顏色也在變化，使用了預計算全局光照
爲了在可接受的幀速率中提供這些效果，我們需要將一些特大數量的數字計算從實時過程轉移到“預計算”。
預計算將計算複雜的光線行爲這一負擔，從遊戲進行時轉移到時間不那麼重要的時候，我們稱之爲“離線”。
那麼這是如何進行的？
當我們想給場景創造更具真實感的光照時，最常見的是，我們把間接的（反射的）光線存儲在我們的光照貼圖上。幸運的是，顏色的變化是輕緩的，帶有很少的尖銳或“高頻”的地方。Unity 的預計算實時GI這一解決方案利用了間接光照的這些“Diffuse”特徵，轉化爲我們的優勢。
較亮的光照細節，如清晰的陰影，通常可以通過實時光照實現，而不是將其烘焙成光照貼圖。假設我們不需要捕捉這些複雜的細節，我們可以大大降低我們全局光照解決方案的分辨率（Resolution）。
通過在預計算中進行這種簡化，我們有效地減少了在遊戲過程中更新我們的GI光照所需要的計算次數。 如果我們要改變燈光的屬性，例如顏色，旋轉或強度，甚至改變場景中的曲面，這一點便很重要。
爲了進一步加速預計算，Unity 不會直接在 Lightmap 貼圖的紋理元素（Texel）上工作，而是在世界中創建了一個稱爲“簇（Cluster）”的靜態幾何體的低分辨率近似值。
（texel 是紋理元素的簡寫，是紋理圖形的基本單位，用於定義三維對象的曲面。3D 對象曲面的基本單位是紋理，而 2D 對象由像素組成。）
左：將場景視圖設置爲“反照率（Albedo）”，可以清楚地看到Unity預計算實時GI產生的紋素（Texel）。默認情況下，此視圖中的紋素（Texel）大致爲簇（Cluster）的大小。右圖：光照被計算，其結果被轉化爲光照貼圖應用後的遊戲中的場景
傳統上，當計算全局光照時，我們會在光線在靜態場景反彈時，對光線進行“光線跟蹤（Ray trace）”。這種處理是十分複雜的，要求太高，以至於不能夠進行實時處理。
因此，Unity 使用光線跟蹤來預計算這些表面簇之間的關係 - 在預計算的“光傳輸（Light Transport）”階段。
通過將世界簡化成一個關係網絡，我們在追求性能的遊戲運行過程中消除了對昂貴的光線跟蹤的需求。
我們已經有效地創建了世界的簡化數學模型，它可以在遊戲運行過程中接受不同的輸入。 這意味着我們可以對場景中的燈光或表面顏色進行修改，並且可以快速查看場景光照更新中GI造成的影響。我們的光照模型產生的輸出可以轉化爲光照貼圖紋理，用於在GPU上渲染，與其他光照和表面貼圖混合，處理效果，並最終輸出到屏幕。
效益和成本（Benefits and Costs）
雖然可以同時使用烘焙GI和預計算實時GI，但要注意的是，同時渲染兩個系統的性能成本恰好是它們的總和。 我們不僅必須在視頻存儲器（Video memory）中存儲兩套光照貼圖，而且還支付在着色器（Shader）中解碼的處理成本。
您可能希望選擇一種光照方法的情況，取決於您的項目的性質和您的預期硬件的性能。 例如，在視頻存儲器和處理能力更受限制的移動設備上，可能會使烘焙GI方法更加有效。 在具有專用圖形硬件的獨立計算機或最新的遊戲機上，很可能使用預計算實時GI或甚至同時使用這兩個系統。
根據您的特定項目的性質和所期望的目標平臺，將對使用哪種方法進行評估。記住，當面對一系列不同的硬件，通常這是最高效的，將決定哪些方法是必需的。
啓用烘焙GI或預計算實時GI（Baked GI or Precomputed Realtime GI）
默認情況下，在Unity的 Lighting 面板（Lighting> Scene）中啓用了預計算實時GI和烘焙GI。
同時啓用，使用哪種技術可以由每個燈光單獨控制（Inspector> Light> Baking）。
在場景中同時使用烘焙GI和預計算實時GI可能會對性能造成不利影響。 一個好的做法是確保一次只能使用一種方案，通過禁用其他方案。 這可以通過取消選中Unity的 Lighting 面板（Lighting> Scene）中預計算實時GI或烘焙GI旁邊的框來實現。 現在只有已選中的選項將出現在您的場景中，並且將覆蓋每個燈光的設置。
每盞燈光的設置（Per-Light Settings）
每個燈的默認烘焙模式是“Realtime”。 這意味着所選擇的燈光仍然可以爲您的場景提供直接光照，由Unity的預計算實時GI系統處理間接光照。
然而，如果烘焙模式設置爲“Baked”，則該燈將僅向 Unity 的烘焙GI系統貢獻光照。 所選擇的這些燈的直接和間接光照將被“baked”成光照貼圖，並且在遊戲過程中不能改變。
選擇“Mixed”烘焙模式時，標記爲靜態的 GameObjects 仍將在其烘焙GI光照貼圖中包含此燈。 然而，與標記爲“Baked”的燈光不同，標記爲“Mixed”的燈光仍然會爲您的場景中的非靜態 GameObjects 提供實時，直接的光照。這在您在靜態環境中使用光照貼圖，但您仍然希望角色使用這些相同的光線將實時陰影投射到使用光照貼圖的幾何體上的情況下可能非常有用。