Modern Graphics Pipelines（當(dāng)前主流的圖形管線）

在開始之前芒篷，我們必須要知道一點(diǎn)現(xiàn)代可編程圖形管線的一些知識盗胀。早些時候忌栅，我們被顯卡的功能限制徘六，不能去改變每個像素的繪制方式内边，除了發(fā)送一些不同的紋理外，不能去修改頂點(diǎn)的數(shù)據(jù)〈猓現(xiàn)在時代已經(jīng)改變假残，我們能夠基于顯卡的圖形管線進(jìn)行編程。我們能夠發(fā)送代碼到顯卡去改變像素的外觀（顏色）炉擅，使用法線紋理(normal maps)改變它們外觀使其變的突起辉懒，也可以添加反射。

這個代碼是以geometry,vertex, fragment shaders的形式存在的，從本質(zhì)上來說奕枝，它們是控制顯卡如何去渲染對象恩袱。

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

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

這是一個線性的流程窃判，每個幾何對象分別通過渲染管線一步步的處理下去并產(chǎn)生最終的圖像钞楼。

Deferred Rendering

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

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

Deferred lighting is a modification of deferred rendering that reduces the size of the G-buffer by using more passes on the scene.

Lighting Performance（光照性能）

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

如果你在場景中有100個幾何對象，并且每個幾何對象有1000個頂點(diǎn)，你大約就有100000多變形（非常粗略的計算）红伦。顯卡還能夠很輕松的處理介陶，但是當(dāng)這些多邊形被發(fā)送到片元著色器時， 昂貴的對燈光消耗會使性能急劇下降色建。開發(fā)者可以嘗試放置光照計算到頂點(diǎn)著色器減少片元著色器對光照的計算哺呜。
不管它是不是此像素上最頂層的片元，還是被遮擋的片元箕戳，昂貴的光照計算都會在每個多邊形的每個可見片元上執(zhí)行某残。如果屏幕的分辨率是1024x768，你有將近800000個像素需要被渲染陵吸。你能很輕易的就達(dá)到每幀百萬級的片元操作玻墅。并且大多數(shù)的片元還會被剔除（深度測試階段），那么對于此片元的光照就算就白費(fèi)了壮虫。

如果你要對這樣一個達(dá)到百萬級片元的場景的每一燈光進(jìn)行渲染澳厢，那么你在每一幀將躍升的一個燈光數(shù)量x1000000個片元的操作上！想象一下你有一個小鎮(zhèn)的街道上面布滿點(diǎn)光源Ｇ羲啤ＪＢ！！Ｈ幕健徐伐！

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

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

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

延遲渲染（Deferred Rendering）是一個減少光照著色對象數(shù)量有趣的方法。尤其是對于總的片元對象來說绊含，執(zhí)行光照的片元數(shù)量直接由屏幕的分辨率決定。
延遲渲染（Deferred Rendering）的復(fù)雜性炊汹，在big O notation中是O(screen_resolution * num_lights)躬充。

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

The Guts of Deferred Rendering（延遲渲染的細(xì)節(jié)）

每個幾何對象被渲染伴找，但是沒有使用光照盈蛮，使用多目標(biāo)渲染（multiple render targets），繪制出多個屏幕空間大小的Buffer技矮。深度抖誉，法線和顏色分別寫入各自的buffers(圖像)。然后衰倦，這些Buffers和每個燈光像的素顏色進(jìn)行合成袒炉，最后生成最終的圖像。
下圖分別是：Color,Depth和Normals

下圖是最終生成的圖片：

選擇哪一個呢樊零？

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

• 這個處理需要顯卡支持多目標(biāo)渲染，老的顯卡是不支持的驻襟，所有不能在上面工作夺艰，對于這個是沒有變通的方案的，除非強(qiáng)制要求客服換顯卡沉衣。
• 它需要高帶寬的顯卡劲适，你要發(fā)送大的Buffer數(shù)據(jù)，老大的顯卡可能處理不了厢蒜。對于這個也沒有變通的方案的霞势，除非強(qiáng)制要求客服換顯卡。
• 你不能使用透明對象斑鸦。（除非你聯(lián)合 使用deferred rendering 和Forward Rendering ）愕贡。
• 沒有抗鋸齒。
• 僅有一個類型的材質(zhì)被允許巷屿，除非你使用了被叫做Deferred Lighting的延遲渲染修改固以。
• 陰影依賴于光照的數(shù)量，延遲渲染沒有解決任何陰影的問題嘱巾。

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

總結(jié)

我希望擺脫一些光照的主題篙螟。在這里你的選擇是解決渲染問題，但是在游戲開始之前就做出正確的選擇是非常重要的问拘，因?yàn)榭梢员苊馊蘸蟮男薷摹?/p>