正向渲染和延遲渲染的區別
如果你是一個遊戲開發者，在你使用的圖形引擎中或多或少都聽說過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）並且替換你的燈光使用靜態光照貼圖。這個結果看起來還是令人吃驚的。
總結
我希望擺脫一些光照的主題。在這裡你的選擇是解決渲染問題，但是在遊戲開始之前就做出正確的選擇是非常重要的，因為可以避免日後的修改。
原文：https://gamedevelopment.tutsplus.com/articles/forward-rendering-vs-deferred-rendering--gamedev-12342
權威發布有關Imagination公司CPU，GPU以及連接IP、無線IP最新資訊，提供有關物聯網、可穿戴、通信、汽車電子、醫療電子等應用信息，每日更新大量信息，讓你緊跟技術發展，歡迎關注！伸出小手按一下二維碼我們就是好朋友！
