Unity3D中Rendering Paths及LightMode的示例分析

這篇文章將為大家詳細講解有關Unity3D中Rendering Paths及LightMode的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

簡述

Unity supports different Rendering Paths. You should choose which one you use depending on your game content and target platform / hardware. Different rendering paths have different performance characteristics that mostly affect Lights and Shadows. See render pipeline for technical details.

U3D支持不同的Rendering Path(渲染路徑)，開發者應該根據游戲內容和目標平臺，硬件等來選擇使用哪個Rendering Path。不同的Rendering Path具有不同的表現效果，這些不同之處多體現在光照和陰影方面。查閱Render Pipeline獲取更多的細節。

The rendering Path used by your project is chosen in Player Settings. Additionally, you can override it for each Camera.

可以在Player Setting中設置默認的Rendering Path，也可以針對單獨的Camera進行設置。

If the graphics card can’t handle a selected rendering path, Unity will automatically use a lower fidelity one. For example, on a GPU that can’t handle Deferred Shading, Forward Rendering will be used.

如果目標平臺的顯卡不能處理所選擇的硬件，那么Unity會自動過渡至低保真檔次Rendering Path去。比如有的GPU不能處理Deferred Shading，那就會自動采用Forward Rendering。

下面按從高效果至低效果的順序開始講解不同的Rendering Path。

Deferred Shading Rendering Path

概述

由于在移動開發中并不常用Deferred Shading，故本節不細述。

Shader中使用的LightMode Pass Tag: Deferred

Deferred Shading擁有最佳的光照和陰影效果。當場景中存在許多的實時光照時，使用Deferred Shading也是最佳的方案。當然Deferred Shading對硬件的要求稍高。

Deferred Shading是一種屏幕空間著色技術，之所以叫做Deferred（延遲的，延期的），是因為Shading的時機不是發生在第一個Pass的Vertex和Pixel/Fragment函數內，而是存在延遲，直到第二Pass的時候才執行。

Deferred Shading對影響物體的光源數量沒有限制，所有的光源都是Per-Pixel（逐像素）光照，即所有光源都可以正確的和法線貼圖得到正確的計算結果。另外，所有的光源都可以有Light Cookie和陰影。其性能開銷與光源數量成正比，這意味著可以通過控制光照面積，減少單個物體受到光照影響的數量來獲得性能方面的提升。Deferred Shading的另一個優點是結果能夠很方便的預測，被個光源都是逐像素光照，具有一致的光照計算過程。

缺點在于，其不能真正的支持抗鋸齒以及半透明物體（半透明物體是用 Forward Rendering 渲染路徑）。同時也不支持Unity3D中的Mesh Renderer組件的Receive Shadows功能，對Culling Masks的支持也不完善，最多能使用四個Culling Mask。

Q： 什么是Light Cookie？
A： Light Cookie又被稱作Cucoloris。是一種應用在電影攝制時的小技巧，如下兩張圖，具體的解釋可以查看Wiki，Unity3D中的應用可以查看Unity3D Cookies手冊或Unity3d Spot Light Cookie，Unity3D中的實現視頻過程可以點擊這里：

要求

顯卡應支持Multiple Render Targets(MRT)，Shader Model 3.0（及更高），Depth Render Textures。大多數產于2006年以后的PC顯卡都支持本功能。
因為對MRT功能支持的缺失，本功能在移動端不受支持。（有的GPU支持，但是支持的程度也非常有限。）
注意：當使用Orthographic projection（正交投影）時Deferred rendering不適用。當使用正交投影時會降至 Forward Rendering。

性能方面

性能方面的影響取決于物體受光源影響的數量，而不是場景的復雜度。小面積的點光源或聚光燈，或光源被部分或完全摭擋，可以在很好的降低性能開銷。

有陰影的光源開銷更大，在Deferred rendering中，受到投影光源影響的，且可投影的物體依然是要對影響其的每個投影光源都進行計算。具有陰影的光照Shader也肯定比沒有陰影的開銷更大。

Forward Rendering Rendering Path

概述

Shader中使用的LightMode Pass Tag: ForwardBase和ForwardAdd
當Forward不可以用時會以Legacy Vertex Lit Rendering Path的效果進行渲染

Forward是傳統渲染路徑。支持所有的Unity圖形特性。在默認情況下，只有少數最亮的光源得以成為Per-Pixel光源。其他的光源則視為Per-Vertex。

取決于影響物體的光源數量，Forward 在單個或多個Pass內渲染物體。需要注意的是，光源根據設置或強度的不同，本身也會具有不同的特性。

使用指南

Forward下，一些（視Quality Setting里面的設置而定）最亮的光源渲染物體時以Per-Pixel的方式進行。緊接著可有四個光源為Per-Vetex光源。其余的光源都以球諧函數（SH：Spherical Harmonics）進行計算，可以高效但是粗略的得到計算結果。無論光源是不是Per-Pixel的都依賴以下規則：

• 光源的Render Mode設為Not Important的，則不是Per-Pixel光源

• 最亮的平行光是Per-Pixel光源

• 光源的Render Mode設為Important的，則為Per-Pixel光源

• 如果場景中的per-pixel光源數量少于Quality Setting中的Pixel Light Count設置的數量，則會按光照強度從強至弱的順序，將更多的光源設置為per-pixel。

渲染每個物體時會依以下規則：

• Base Pass只會用到一個per-pixel光源，以及所有其它Per-Vertex光源或SH光源

• 其它的per-pixel光源則在Additional Pass中渲染，并且每個Pass對應一個per-pixel光源

例如有物體受到如下A-H光源的影響：

假設所有光源都有相同的強度和顏色，并且Render Mode都設為Auto。最亮的4個光源A-D則為per-pixel光源，接著是四個per-vertex光源，D-G，最后余下的光源則是SH球諧光源，G-H。

注意上圖中光源分組的重疊部份。例如最后一個既可以成為per-pixel光源也可以成為per-vertex光源，因此當物體或光源移動時，產生Light Popping（因光照導致的畫面不正常）的可能性更小。

關于Light Popping問題的實例，點擊這里 ，提問者最后通過調整光照亮度得以解決。

Light Popping現象

Base Pass

Base Pass只用一個per-pixel光源和所有的SH/Vertex 光源來渲染物體。在這個pass內也能通過shader加入光照貼圖(Lightmaps)，環境光(ambient)，自發光(Emissive)等。平行光在這個Pass內產生陰影。

注意：

• 使用LightMaps的物體（烘培過的物體）不會受到SH光源的光照。

• 當在Shader中使用Passflag tag “OnlyDirectional”時，forward base pass只會渲染主平行光，環境光照探頭(Ambient/Light Probe)和光照貼圖，SH和vertex光源沒有被包含在此pass的數據內。

Additional Passes

Additional Passes用于渲染每個額外的per-pixel光源。在這些pass中的光源默認是不會產生陰影的（也就是說，Forward Rendering默認只支持一個光源可以產生陰影）。除非使用multi_compile_fwdadd_fullshadows宏。

性能相關

Spherical Harmonics lights（球諧光照）非常高效。對CPU的消耗極其微小，對于GPU來說不會有額外的負擔（因為base pass原本就會一直計算SH Lighting；和球諧光照的機制有光，無論有多少球諧光的存在，消耗都是一樣的）。

擴展閱讀，Enlighten的簡化球諧光照文檔，《球諧照明：細節》，《球諧照明：細節》講義，球諧照明原理

SH光照的缺點：

• 利用物體的vertices(Vertex單詞的復數形式，Vertex的復數有三種寫法: vertexes，vertices ，vertexs）進行計算，而不是pixels。因此不支持法線貼圖和Light Cookies。

• SH光照函數是種非常低頻的照明函數，不會有非常銳利的照明過渡，另外也只會響應Diffuse Lighting（漫反射），對于Specular Highlight（鏡面高光）而言其頻率太低了。

• SH lighting is not local; point or spot SH lights close to some surface will “look wrong”. 球諧照明不是局部的（？局部坐標系？），點光源或聚光燈形式的SH Light在靠近一些表面時看上去會不正常。

總結，SH Light適用于小型動態物體。

Legacy Deferred Lighting Rendering Path

概述

Shader中使用的LightMode Pass Tag: PrepassBase和PrepassFinal

Legacy Deferred (light prepass) 類似于Deferred Shading，但是和其運用了不同的技術，有不同的側重。不支持Unity5的Physically Based Standard Shader。關于Legacy Deferred的原理可以查看RTR（Real-Time Rendering）網站的文章《Deferred lighting approaches》

Deferred Lighting從Unity 5.0起被視為傳統特性，因為其無法支持諸如Stander Shader，Reflection Probes等特性。新工程可以考慮直接使用 Deferred Shading（不適用于移動平臺）。

注意：當使用Orthographic projection時Deferred Rendering Path 不適用。當使用正交投影時會降至 Forward Rendering Path。
注意：Legacy Deferred Lighting Rendering Path 和 Deferred Shading Rendering Path 都是Deferred rendering。

Deferred Lighting對影響物體的光源數量沒有限制，所有的光源都是Per-Pixel光照，即所有光源都可以正確的和法線貼圖得到正確的計算結果。另外，所有的光源都可以有Light Cookie和Shadow。其性能開銷與光源數量成正比，這意味著可以通過控制光照面積，減少單個物體受到光照影響的數量來獲得性能方面的提升。Deferred Lighting的另一個優點是結果能夠很方便的預測，被個光源都是逐像素光照，具有一致的光照計算過程。

其缺點在于不能真正的支持抗鋸齒以及半透明物體（半透明物體采用 Forward Rendering 渲染路徑）。同時也不支持Unity3D中的Mesh Renderer組件的Receive Shadows功能，對Culling Masks的支持也不完善，最多能使用四個Culling Mask。

要求

顯卡應支持Shader Model 3.0（或更新的版本），Depth Render Textures，Two-sided Stencil Buffers。大多數產于2004年以后的PC顯卡都支持本功能。
在手機端，所有支持OpenGL ES 3.0r GPU都支持Deferred Lighting. 部份OpenGL ES 2.0的GPU也能支持（因為支持Depth Textures）。
注意：當使用Orthographic projection（正交投影）時Deferred rendering不適用。當使用正交投影時會降至 Forward Rendering。

性能方面

性能方面的影響取決于物體受光源影響的數量，而不是場景的復雜度。小面積的點光源或聚光燈，或光源被部分或完全摭擋，可以在很好的降低性能開銷。

有陰影的光源開銷更大，在Deferred Rendering中，受到投影光源影響的，且可投影的物體依然是要對影響其的每個投影光源都進行計算。具有陰影的光照Shader也肯定比沒有陰影的開銷更大。

使用指南

使用Deferred Lighting， 渲染過程發生在三種Pass內。

1. Base Pass：物體產生screen-space buffers, 包含depth, normals, specular power等信息。

2. Lighting Pass：前一階段生成的Scree-space buffers用來計算光照，并放入另一個screen-space buffers。

3. Final Pass：物體再次被處理，取得前一階段計算的光照信息，結合色彩紋理，并添加ambient/emissive Lighting。

如果物體使用了不適用于Deferred Lighting Rendering Path的Shader，會使用Forward rendering path

Base Pass

Base pass會對物體進行一次處理。View sapce normals（視野空間法線）和Specular Power(高光強度)被處理為一張ARGB32格式的Render Texture(RGB值為normals， A為Specular Power)。如果目標平臺和硬件允許Z buffer以紋理的形式讀取，則不用再進行額外的渲染流程。反之，則要在另一個Pass使用Shader Replacement的Shader中進行處理。

Lighting Pass

lighting passs根據Depth，Normal和Specular power來計算光照。光照計算發生在Screen Space（屏幕空間）中，因此時間消耗取決與場景的復雜程度。Lighting Buffer是一張ARGB32的Render Texture，Diffuse Lighting使用其RGB通道，Specular Lighting使用其A通道。

Final Pass

處理紋理，自發光等其它內容，另外，光照貼圖也在這里完成。

Legacy Vertex Lit Rendering Path

Shader中使用的 使用的LightMode Pass Tag: Vertex,VertexLMRGBM和VertexLM

效果最差，不支持實時陰影。屬于Forward Rendering Path的子集。是性能最高，受支持度最多的Rendering Path（但是主機上不適用）。
所有的光照計算在Vertex層面完成，因此無法支持大多數的per-pixel效果，比如，陰影，法線貼圖，Light Cookies，精細的高光效果。

LightMode Tags

LightMode tag defines Pass’ role in the lighting pipeline. See render pipeline for details. These tags are rarely used manually; most often shaders that need to interact with lighting are written as Surface Shaders and then all those details are taken care of.

Possible values for LightMode tag are:

Always: Always rendered; no lighting is applied.
ForwardBase: Used in Forward rendering, ambient, main directional light, vertex/SH lights and lightmaps are applied.
ForwardAdd: Used in Forward rendering; additive per-pixel lights are applied, one pass per light.
Deferred: Used in Deferred Shading; renders g-buffer.
ShadowCaster: Renders object depth into the shadowmap or a depth texture.
PrepassBase: Used in legacy Deferred Lighting, renders normals and specular exponent.
PrepassFinal: Used in legacy Deferred Lighting, renders final color by combining textures, lighting and emission.
Vertex: Used in legacy Vertex Lit rendering when object is not lightmapped; all vertex lights are applied.
VertexLMRGBM: Used in legacy Vertex Lit rendering when object is lightmapped; on platforms where lightmap is RGBM encoded (PC & console).
VertexLM: Used in legacy Vertex Lit rendering when object is lightmapped; on platforms where lightmap is double-LDR encoded (mobile platforms).

Rendering Paths Comparison

關于“Unity3D中Rendering Paths及LightMode的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。