如果你是一個游戲開發者，在你使用的圖形引擎中或多或少都聽說過forward rendering和deferred rendering。通常你必須在你的游戲中選擇一種。但它們是什么，彼此之間有什么不同，我們又該如何選擇呢？

Modern Graphics Pipelines（現代圖形管道）

在開始之前，我們必須要知道一點現代可編程圖形管線的一些知識。早些時候，我們被顯卡的功能限制，不能去改變每個像素的繪制方式，除了發送一些不同的紋理外，不能去修改頂點的數據。現在時代已經改變，我們能夠基于顯卡的圖形管線進行編程。我們能夠發送代碼到顯卡去改變像素的外觀（顏色），使用法線紋理(normal maps)改變它們外觀使其變的突起，也可以添加反射（以及大量的現實主義）。

此代碼采用幾何，頂點和片段著色器的形式，從本質上來說，它們控制顯卡如何去渲染對象。

可編程圖形管道的簡化視圖

Forward Rendering（正向渲染/前向渲染）

Forward Rendering 是大多數渲染引擎使用的渲染技術。你給顯卡提供幾何對象，它將幾何對象分解成頂點送入頂點著色器，然后把這些頂點數據插值后分別送入片元/像素著色器，然后在它們被送入屏幕前做最終的渲染處理（模板測試，混合等）。

正向渲染：幾何著色器到頂點著色器來分割著色器

這是一個線性的流程，每個幾何對象分別通過渲染管線一步步的處理下去并產生最終的圖像。

Deferred Rendering（延遲渲染）

延遲渲染，從這個名字來看就意味著渲染是被延遲的，直到所有幾何對象都已經通過渲染管線處理后，在最后才應用著色（通過光照來決定最終的像素顏色）并產生最終的圖像。

那么為什么要這樣來處理呢？

延遲渲染：幾何到頂點到片段著色器。傳遞給多個渲染目標，然后用光照陰影。

延遲照明是對延遲渲染的修改，通過在場景中使用更多遍來減少G緩沖區的大小。

Lighting Performance（光照性能）

標準前向渲染（Forward Rendering）光照的性能消耗也是為什么要另辟蹊徑選擇其他渲染方式的主要原因。在標準前向渲染（Forward Rendering）管線流程中，每個燈光都會在每個頂點/或片元上執行光照計算，這也就是常說的逐頂點光照和逐片元/像素光照。

如果你在場景中有100個幾何對象，并且每個幾何對象有1000個頂點，你大約就有100000多變形（非常粗略的計算）。顯卡還能夠很輕松的處理，但是當這些多邊形被發送到片元著色器時， 昂貴的對燈光消耗會使性能急劇下降。開發者可以嘗試放置光照計算到頂點著色器減少片元著色器對光照的計算。

不管它是不是此像素上最頂層的片元，還是被遮擋的片元，昂貴的光照計算都會在每個多邊形的每個可見片元上執行。如果屏幕的分辨率是1024x768，你有將近800000個像素需要被渲染。你能很輕易的就達到每幀百萬級的片元操作。并且大多數的片元還會被剔除（深度測試階段），那么對于此片元的光照就算就白費了。

如果你要對這樣一個達到百萬級片元的場景的每一燈光進行渲染，那么你在每一幀將躍升的一個燈光數量x1000000個片元的操作上！想象一下你有一個小鎮的街道上面布滿點光源！！！！！

計算前向渲染（Forward Rendering）復雜度的公式參見：big O notatio，復雜度公式：O(num_geometry_fragments * num_lights)。你能看到這里的復雜度是和幾何對象數量和燈光數量直接相關的。

片元是一個最終可能在屏幕上成為像素的一個”待轉像素“，如果在深度測試階段不被剔除的話，它將在屏幕上成為屏幕的最終像素。現在一些引擎通過其他的方式優化了光照計算，比如：剔除非常遠的燈光，組合燈管或使用 Light maps(非常流行的，但是只能是靜態的物體)。如果你有大量的燈光需要動態光照的話，我們需要一個更好的解決方案。

Deferred Rendering to the Rescue（前向渲染的救星–延遲渲染）

延遲渲染（Deferred Rendering）是一個減少光照著色對象數量有趣的方法。尤其是對于總的片元對象來說，執行光照的片元數量直接由屏幕的分辨率決定。

延遲渲染（Deferred Rendering）的復雜性，在big O notation中是O(screen_resolution * num_lights)。

現在你能明白了，你有多少的光照數量是由你對燈光數量的使用來決定的。所以你能很高興的增加你的燈光數量。（這不意味著你可以有無限的幾何對象，它們還是要經過管線的及其他處理才能到G-Buffer中。）

The Guts of Deferred Rendering（延遲渲染的細節）

每個幾何對象被渲染，但是沒有使用光照，使用多目標渲染（multiple render targets），繪制出多個屏幕空間大小的Buffer。深度，法線和顏色分別寫入各自的buffers(圖像)。然后，這些Buffers和每個燈光像的素顏色進行合成，最后生成最終的圖像。

顏色，深度和正常緩沖區。（圖片由astrofa，通過維基共享資源。）

最終照明（陰影）使用三個緩沖區生成結果。（圖片由astrofa，通過維基共享資源。）

選擇哪一個呢？

一個最簡短的回答是：如果你使用了大量燈光那么你就該使用延遲渲染(Deferred Rendering)了。但是延遲渲染（Deferred Rendering）也有一些明顯的缺點：

? 這個處理需要顯卡支持多目標渲染，老的顯卡是不支持的，所有不能在上面工作，對于這個是沒有變通的方案的，除非強制要求客服換顯卡。

? 它需要高帶寬的顯卡，你要發送大的Buffer數據，老大的顯卡可能處理不了。對于這個也沒有變通的方案的，除非強制要求客服換顯卡。

? 你不能使用透明對象。（除非你聯合 使用deferred rendering 和Forward Rendering ）。

? 沒有抗鋸齒。

? 僅有一個類型的材質被允許，除非你使用了被叫做Deferred Lighting的延遲渲染修改。

? 陰影依賴于光照的數量，延遲渲染沒有解決任何陰影的問題。

如果你沒有大量的燈光或者你想能夠在比較老的顯卡上允許，你應該選擇使用前向渲染（Forward Rendering）并且替換你的燈光使用靜態光照貼圖。這個結果看起來還是令人吃驚的。

總結

我希望擺脫一些光照的主題。在這里你的選擇是解決渲染問題，但是在游戲開始之前就做出正確的選擇是非常重要的，因為可以避免日后的修改。