本篇為Unity官方文檔的摘抄集合，為方便后續翻看。

1、渲染路徑

????????Unity 的內置渲染管線支持不同渲染路徑。渲染路徑是與光照和陰影相關的一系列操作。不同的渲染路徑具有不同功能和性能特征。應根據項目類型以及目標硬件，選擇渲染路徑。

????????可在 Graphics 窗口中選擇項目使用的渲染路徑，并可為每個攝像機覆蓋該路徑。

????????如果運行項目的設備上的 GPU 不支持所選的渲染路徑，則 Unity 將自動使用較低保真度的渲染路徑。例如，在無法處理延遲著色的 GPU 上，Unity 使用前向渲染。

1.1 前向渲染

????????前向渲染是內置渲染管線中的默認渲染路徑。這是通用的渲染路徑。

1.1.1 簡介

????????采用前向渲染方式渲染實時光源會非常消耗資源。為了抵消此成本，可以選擇 Unity 在任何一個時間應該為每個像素渲染的光源數量。Unity 會以較低保真度渲染場景中的其余光源：每個頂點或每個對象。

????????如果項目沒有使用大量實時光源，或者光照保真度對項目而言不重要，則此渲染路徑可能是這個項目的不錯選擇。

????????前向渲染根據影響對象的光源在一個或多個通道中渲染每個對象。光源本身也可以通過前向渲染進行不同的處理，具體取決于它們的設置和強度。

1.1.2 實現詳細信息

????????在前向渲染中，影響每個對象的一些最亮的光源以完全逐像素光照模式渲染。然后，最多 4 個點光源采用每頂點計算方式。其他光源以球諧函數 (SH) 計算，這種計算方式會快得多，但僅得到近似值。

光源是否為每像素光源根據以下原則而定：

• Render Mode 設置為 Not Important 的光源始終為每頂點或 SH 光源。
• 最亮的方向光始終為每像素光源。
• Render Mode 設置為 Important 的光源始終為每像素光源。
• 如果上述情況導致光源數少于當前的 Pixel Light Count 質量設置，則按照亮度降低的順序，更多光源采用每像素渲染方式。

每個對象的渲染按如下方式進行：

• 基礎通道應用一個每像素方向光和所有每頂點/SH 光源。
• 其他每像素光源在額外的通道中渲染（每個光源對應一個通道）。

例如，如果某個對象受到許多光源的影響（下圖中的圓形受光源 A 到 H 的影響）：

????????讓我們假設光源 A 到 H 具有相同的顏色和強度，并且所有光源都具有自動渲染模式，因此它們將嚴格按照此對象的以下順序排序。最亮的光源將以每像素光照模式渲染（A 到 D），然后最多 4 個光源以每頂點光照模式渲染（D 到 G），最后其余光源以 SH 進行渲染（G 到 H）：

????????光源組會重疊，例如，最后一個每像素光源混合到每頂點光照模式，因此當對象和光源移動時，“光射量”(light popping) 較少。

1.1.3 基礎通道

????????基礎通道使用一個每像素方向光和所有 SH/每頂點光源來渲染對象。此通道還會添加著色器中的所有光照貼圖、環境光照和發射光照。在此通道中渲染的方向光可以具有陰影。請注意，光照貼圖的對象不會從 SH 光源獲得光照。

?????????在著色器中使用“OnlyDirectional”通道標志時，前向基礎通道僅渲染主方向光、環境光/光照探針和光照貼圖（SH 和頂點光源不包括在通道數據中）。

1.1.4 其他通道

????????對于影響此對象的每個額外的每像素光源，需要額外的渲染通道。默認情況下，這些通道中的光源沒有陰影（因此在結果中，前向渲染支持一個帶陰影的方向光），除非使用 multi_compile_fwdadd_fullshadows 變體快捷方式。

1.1.5 性能注意事項

????????球諧函數光源的渲染速度_很_快。這些光源的 CPU 成本很低，并且使用 GPU 的_成本基本為零_（也就是說，基礎通道始終會計算 SH 光照；但由于 SH 光源工作方式的原因，無論 SH 光源有多少，成本都完全相同）。

SH 光源的缺點：

• 按對象的頂點而不是按像素計算。這意味著它們不支持光照剪影和法線貼圖。
• SH 光照的頻率很低。SH 光源無法實現快速的光照過渡。它們也只影響漫射光照（頻率對鏡面高光而言太低）。
• SH 光照不是局部光照；SH 點光源或聚光燈在靠近某種表面時“看起是錯誤的”。

總的來說，SH 光源通常足以達到小型動態對象的光照要求。

1.2 延遲著色

1.2.1 簡介

????????延遲著色是內置渲染管線中具有最大光照和陰影保真度的渲染路徑。??

????????延遲著色需要 GPU 支持，并且有一些局限性。這種著色方式不支持半透明對象（Unity 使用前向渲染來渲染這些對象）、正交投影（Unity 對這些攝像機使用前向渲染）或硬件抗鋸齒（但可以使用后期處理效果來獲得類似結果）。延遲著色對剔除遮罩的支持有限，并會將 Renderer.receiveShadows 標志始終視為 true。

????????如果項目具有大量的實時光源并需要高級別的光照保真度，而目標硬件支持延遲著色，那么此渲染路徑對于該項目而言可能是一個不錯的選擇。

1.2.2 概述

????????使用延遲著色時，可影響游戲對象的光源數量沒有限制。所有光源都按像素進行評估，這意味著它們都能與法線貼圖等正確交互。此外，所有光源都可以有剪影和陰影。

????????延遲著色的優點是，光照的處理開銷與接受光照的像素數成正比。這取決于場景中的光量大小，而不管接受光照的游戲對象有多少。因此，可通過減少光源數量來提高性能。延遲著色還具有高度一致和可預測的行為。每個光源的效果都是按像素計算的，因此不會有在大三角形上分解的光照計算。

????????在缺點方面，延遲著色并不支持抗鋸齒，也無法處理半透明游戲對象（這些對象使用前向渲染進行渲染）。此外，它也不支持網格渲染器 (Mesh Renderer) 的接受陰影 (Receive Shadows) 標志，并且僅在有限程度上支持剔除遮罩。最多只能使用四個剔除遮罩。也就是說，剔除層遮罩必須至少包含所有層減去四個任意層，即必須設置 32 個層中的 28 個層。否則，會產生圖形瑕疵。????????

1.2.3 要求?????

????????延遲著色要求顯卡具有多渲染目標 (MRT)、著色器模型 3.0（或更高版本）并支持深度渲染紋理。從 GeForce 8xxx、Radeon X2400、Intel G45 開始，2006 年以后制造的大多數 PC 顯卡都支持延遲著色。

????????所有至少運行 OpenGL ES 3.0 的移動設備都支持延遲著色。

注意：使用正交投影 (Orthographic projection) 時不支持延遲渲染。如果攝像機的投影模式設置為正交模式，則攝像機將回退到前向渲染。

1.2.4 性能注意事項

????????延遲著色中的實時光源的渲染開銷與接受光照的像素數成比例，并_不_依賴于場景復雜度。所以小型點光源或聚光燈的渲染成本非常低，如果它們被場景游戲對象完全或部分遮擋，那么成本甚至更低。

????????當然，有陰影的光源比沒有陰影的光源的成本高得多。在延遲著色中，對于每個陰影投射光源，仍然需要將投射陰影的游戲對象渲染一次或多次。此外，應用陰影的光照著色器的渲染開銷高于禁用陰影時的渲染開銷。

1.2.5 實現詳細信息

????????如果對象的著色器不支持延遲著色，則會在延遲著色結束后使用前向渲染路徑來渲染這些對象。

????????下面列出了 G 緩沖區中渲染目標 (RT0 - RT4) 的默認布局。數據類型放置在每個渲染目標的各個通道中。使用的通道顯示在括號內。

• RT0，ARGB32 格式：漫射顏色 (RGB)，遮擋 (A)。
• RT1，ARGB32 格式：鏡面反射顏色 (RGB)，粗糙度 (A)。
• RT2，ARGB2101010 格式：世界空間法線 (RGB)，未使用 (A)。
• RT3，ARGB2101010（非 HDR）或 ARGBHalf (HDR) 格式：發射 + 光照 + 光照貼圖 + 反射探針緩沖區。
• 深度+模板緩沖區。

????????因此，默認的 G 緩沖區布局為 160 位/像素（非 HDR）或 192 位/像素 (HDR)。

????????如果混合光照模式為 Shadowmask 或 Distance Shadowmask，則使用第五個目標：*RT4，ARGB32 格式：光照遮擋值 (RGBA)。

????????因此，G 緩沖區布局為 192 位/像素（非 HDR）或 224 位/像素 (HDR)。

????????如果硬件不支持五個并發渲染目標，則使用陰影遮罩的對象將回退到前向渲染路徑。 當攝像機不使用 HDR 時，發射+光照緩沖區 (RT3) 采用對數編碼，因此提供的動態范圍高于 ARGB32 紋理通常可能提供的范圍。

????????當攝像機使用 HDR 渲染時，不會為發射 + 光照緩沖區 (RT3) 創建單獨的渲染目標；而是將攝像機渲染到的渲染目標（即傳遞給圖像效果的渲染目標）用作 RT3。????????

1.2.6 G緩沖區通道

????????G 緩沖區通道將每個游戲對象渲染一次。漫射和鏡面反射顏色、表面平滑度、世界空間法線和發射+環境+反射+光照貼圖都將渲染到 G 緩沖區紋理中。G 緩沖區紋理設置為全局著色器屬性供著色器以后訪問（_CameraGBufferTexture0 .._CameraGBufferTexture3 指定）。

1.2.7 光照通道????

????????光照通道根據 G 緩沖區和深度來計算光照。光照是在屏幕空間內計算的，因此處理所需的時間與場景復雜性無關。光照將添加到發射緩沖區。

????????不與攝像機近平面相交的點光源和聚光燈將渲染為 3D 形狀，并會啟用 Z 緩沖區對場景的測試。因此，部分或完全遮擋的點光源和聚光燈的渲染成本很低。方向光以及與近平面相交的點光源/聚光燈將渲染為全屏四邊形。

????????如果光源啟用了陰影，那么也會在此通道中渲染并應用陰影。請注意，陰影并非是“無成本”的；需要渲染陰影投射物，并且必須應用更復雜的光照著色器。

????????唯一可用的光照模型是標準 (Standard) 光照模型。如果需要不同的模型，可修改光照通道著色器，方法是將內置著色器中的 Internal-DeferredShading.shader 文件的修改版本放入“Assets”文件夾中名為“Resources”的文件夾內。然后打開 Graphics 設置（菜單：Edit > Project Settings，然后單擊 Graphics 類別）。將“Deferred”下拉選單改為“Custom Shader”。然后，更改當前使用的著色器對應的著色器 (Shader) 選項。

?1.3 舊版延遲 (Legacy Deferred)

????????舊版延遲（光照預通道）類似于延遲著色，只是采用不同的技術并進行不同的折中。它不支持 Unity 5 基于物理的標準著色器。

????????從 Unity 5.0 開始，舊版延遲渲染路徑被認為是舊版功能，因為它不支持某些渲染功能（例如標準著色器、反射探針）。新項目應考慮改用延遲著色渲染路徑。使用正交投影 (Orthographic projection) 時不支持延遲渲染。如果攝像機的投影模式設置為正交模式，則攝像機將始終使用前向渲染。

1.3.1 概述

????????使用延遲光照時，可影響對象的光源數量沒有限制。所有光源都按像素進行評估，這意味著它們都能與法線貼圖等正確交互。此外，所有光源都可以有剪影和陰影。

????????延遲光照的優點是，光照的處理開銷與接受光照的像素數成正比。這取決于場景中的光量大小，而不管接受光照的對象有多少。因此，可通過減少光源數量來提高性能。延遲光照還具有高度一致和可預測的行為。每個光源的效果都是按像素計算的，因此不會有在大三角形上分解的光照計算。

????????在缺點方面，延遲光照并不支持抗鋸齒，也無法處理半透明對象（這些對象將使用前向渲染進行渲染）。此外，它也不支持網格渲染器 (Mesh Renderer) 的接受陰影 (Receive Shadows) 標志，并且僅在有限程度上支持剔除遮罩。最多只能使用四個剔除遮罩。也就是說，剔除層遮罩必須至少包含所有層減去四個任意層，即必須設置 32 個層中的 28 個層。否則，將產生圖形瑕疵。

1.3.2 要求

????????延遲光照要求顯卡具有著色器模型 3.0（或更高版本）、支持深度渲染紋理以及具有雙面模板緩沖區。 2004 年以后制造的大多數 PC 顯卡都支持延遲光照，包括 GeForce FX 及更高版本、Radeon X1300 及更高版本、 Intel 965/GMA X3100 及更高版本。在移動端，所有支持 OpenGL ES 3.0 的 GPU 都支持延遲光照，而一部分 支持 OpenGL ES 2.0 的 GPU 也支持延遲光照（即支持深度紋理的 GPU）。

1.3.3 性能注意事項

????????延遲光照中的實時光源的渲染開銷與接受光照的像素數成比例，并_不_依賴于場景復雜度。所以小型點光源或聚光燈的渲染成本非常低，如果它們被場景對象完全或部分遮擋，那么成本甚至更低。

????????當然，有陰影的光源比沒有陰影的光源的成本高得多。在延遲光照中，對于每個陰影投射光源，仍然需要將投射陰影的對象渲染一次或多次。此外，應用陰影的光照著色器的渲染開銷高于禁用陰影時的渲染開銷。

1.3.4 實現詳細信息

????????使用延遲光照時，Unity 中的渲染過程在三個通道中進行：

??????? （1）基礎通道：渲染對象以生成具有深度、法線和鏡面反射能力的屏幕空間緩沖區。

??????? （2）光照通道：將先前生成的緩沖區用于計算光照以進入另一個屏幕空間緩沖區。

??????? （3）最終通道：再次渲染對象。它們會獲取計算出的光照，將其與顏色紋理相結合，并添加環境/發射光照。

????????如果對象的著色器無法處理延遲光照，則會在此過程結束后使用前向渲染路徑來渲染這些對象。

1.3.5 基礎通道

????????基礎通道將每個對象渲染一次。視圖空間法線和鏡面反射能力將渲染到單個 ARGB32 渲染紋理中（法線位于 RGB 通道中，而鏡面反射強度位于 A 通道中）。如果平臺和硬件允許將 Z 緩沖區作為紋理讀取，則不會顯式渲染深度。如果無法將 Z 緩沖區作為紋理訪問，則會使用著色器替換在另外的渲染通道中渲染深度。

????????基礎通道的結果是填充了場景內容的 Z 緩沖區以及包含法線和鏡面反射能力的渲染紋理。

1.3.6 光照通道

????????光照通道根據深度、法線和鏡面反射能力來計算光照。光照是在屏幕空間內計算的，因此處理所需的時間與場景復雜性無關。光照緩沖區是單個 ARGB32 渲染紋理，其中在 RGB 通道中包含漫射光照，而在 A 通道中包含單色鏡面光照。光照值采用對數編碼，因此提供的動態范圍高于 ARGB32 紋理通常可能提供的范圍。如果攝像機啟用了 HDR 渲染，則光照緩沖區為 ARGBHalf 格式，并且不執行對數編碼。

????????不與攝像機近平面相交的點光源和聚光燈將渲染為 3D 形狀（的正面），并會啟用對場景的深度測試。與近平面相交的光源也用 3D 形狀進行渲染，但作為背面并進行反向深度測試。因此，部分或完全遮擋的光源的渲染成本很低。如果光源同時與攝像機的遠平面和近平面相交，則不能使用上述優化，而光源會被繪制為緊密四邊形并且不進行深度測試。

????????以上說明不適用于方向光；方向光總是渲染為全屏四邊形。

????????如果光源啟用了陰影，那么也會在此通道中渲染并應用陰影。請注意，陰影并非是“無成本”的；需要渲染陰影投射物，并且必須應用更復雜的光照著色器。

????????唯一可用的光照模型是 Blinn-Phong。如果需要不同的模型，可修改光照通道著色器，方法是將內置著色器中的 Internal-PrePassLighting.shader 文件的修改版本放入“Assets”文件夾中名為“Resources”的文件夾內。然后，選擇 Edit > Project Settings > Graphics 窗口。將“Legacy Deferred”下拉選單改為“Custom Shader”。然后，更改當前使用的光照著色器對應的著色器 (Shader) 選項。

1.3.7 最終通道

????????最終通道將產生最終渲染的圖像。在此階段將再次使用著色器渲染所有對象，這些著色器會獲取光照，將其與紋理相結合，并添加發射光照。在最終通道中還會應用光照貼圖。在靠近攝像機的位置將使用實時光照，并且僅添加烘焙間接光照。因此會交叉淡入遠離攝像機的完全烘焙光照。

1.4 舊版頂點光照

????????舊版頂點光照 (Legacy Vertex Lit) 是具有最低光照保真度且不支持實時陰影的渲染路徑。這是前向渲染路徑的子集。

????????頂點光照路徑通常在一個通道中渲染每個對象，并為每個頂點計算所有光源的光照。

????????頂點光照路徑是最快的渲染路徑，具有最廣泛的硬件支持。

????????由于所有光照都是在頂點級別計算的，因此該渲染路徑不支持大多數每像素效果：陰影、法線貼圖、光照剪影和高度細節化的鏡面高光都不受支持。

1.5 渲染路徑比較

延遲前向舊版延遲頂點光照

功能
每像素光照（法線貼圖、光照剪影）	是	是	是	-
實時陰影	是	帶有警告	是	-
反射探針	是	是	-	-
深度和法線緩沖區	是	其他渲染pass	是	-
軟粒子	是	-	是	-
半透明對象	-	是	-	是
抗鋸齒	-	是	-	是
光照剔除遮罩	受限	是	受限	是
光照保真度	全部每像素	部分每像素	全部每像素	全部每頂點
性能
每像素光照的成本	照射像素數量	像素數量 * 照射對象數量	照射像素數量	-
正常渲染對象的次數	1	每像素光照的數量	2	1
簡單場景的開銷	高	無	中	無
平臺支持
PC (Windows/Mac)	Shader Model 3.0+ 和 MRT	所有	Shader Model 3.0+	所有
移動端 (iOS/Android)	OpenGL ES 3.0 和 MRT、Metal（在搭載 A8 或更高版本 SoC 的設備上）	所有	OpenGL ES 2.0	所有
游戲主機	XB1、PS4	所有	XB1、PS4、360	-

2、使用 CommandBuffer 來擴展內置渲染管線

????????包含有關在內置渲染管線中使用 CommandBuffer 的信息。有關在渲染管線中基于可編程渲染管線使用 CommandBuffer 的信息，請參閱在可編程渲染管線中調度和執行渲染命令。

2.1 CommandBuffer 基礎知識

CommandBuffer? 保存渲染命令列表（例如設置渲染目標或繪制給定網格）。可以指示 Unity 在內置渲染管線中的各個點安排和執行這些命令，因此，您可以自定義和擴展 Unity 的渲染功能。

使用 CommandBuffer 進行模糊折射

????????可以使用 Graphics.ExecuteCommandBuffer API 立即執行 CommandBuffer，也可以進行安排，讓它們在渲染管線中的給定點執行。要安排它們，請使用 Camera.AddCommandBuffer API 與CameraEvent 枚舉，以及 Light.AddCommandBuffer API 與 LightEvent 枚舉。要查看 Unity 何時執行以這種方式安排的 CommandBuffer，請參閱 CameraEvent 和 LightEvent 的執行順序。

????????有關可以使用 CommandBuffer 執行的命令的完整列表，請參閱 CommandBuffer API 文檔。請注意，一些命令僅在某些硬件上受支持。例如，與光線追蹤有關的命令僅在 DX12 中受支持。

2.2 Command Buffer 示例

標題使用 Command Buffers 貼花

????????Unity 博客文章擴展 Unity 5 渲染管線：CommandBuffer 介紹了內置渲染管線中的 CommandBuffer，并包含示例項目和示例代碼。它介紹如何使用 CommandBuffer 來實現幾種不同的效果，并包含一個示例項目和示例代碼。項目是為 Unity 的舊版本創建的，但原理相同。

2.3 CameraEvent 事件的執行順序

????????CameraEvents 執行順序取決于項目使用的渲染路徑。

2.3.1 延遲渲染路徑

• BeforeGBuffer
• Unity 渲染不透明幾何體
• AfterGBuffer
• Unity 解析深度。
• BeforeReflections
• Unity 渲染默認反射和反射探針反射。
• AfterReflections
• Unity 將反射復制到 G 緩沖區的 Emissive 通道。
• BeforeLighting
• Unity 渲染陰影。請參閱 LightEvent 執行順序。
• AfterLighting
• BeforeFinalPass
• Unity 對最終通道進行處理。
• AfterFinalPass
• BeforeForwardOpaque（僅當存在無法以延遲方式渲染的不透明幾何體時調用）
• Unity 渲染無法以延遲方式渲染的不透明幾何體。
• AfterForwardOpaque（僅當存在無法以延遲方式渲染的不透明幾何體時調用）
• BeforeSkybox
• Unity 渲染天空盒。
• AfterSkybox
• Unity 渲染光環。
• BeforeImageEffectsOpaque
• Unity 應用僅不透明的后期處理效果。
• AfterImageEffectsOpaque
• BeforeForwardAlpha
• Unity 渲染透明幾何體以及具有 Screen Space - Camera 渲染模式的 UI 畫布。
• AfterForwardAlpha
• BeforeHaloAndLensFlares
• Unity 渲染鏡頭光暈。
• AfterHaloAndLensFlares
• BeforeImageEffects
• Unity 應用后期處理效果。
• AfterImageEffects
• AfterEverything
• Unity 對渲染模式不是 Screen Space - Camera 的 UI 畫布進行渲染。

2.3.2 前向渲染路徑

• BeforeDepthTexture
• Unity 渲染不透明幾何體的深度。
• AfterDepthTexture
• BeforeDepthNormalsTexture
• Unity 渲染不透明幾何體的深度法線。
• AfterDepthNormalsTexture
• Unity 渲染陰影。請參閱 LightEvent 執行順序。
• BeforeForwardOpaque
• Unity 渲染不透明幾何體。
• AfterForwardOpaque
• BeforeSkybox
• Unity 渲染天空盒。
• AfterSkybox
• Unity 渲染光環。
• BeforeImageEffectsOpaque
• Unity 應用僅不透明的后期處理效果。
• AfterImageEffectsOpaque
• BeforeForwardAlpha
• Unity 渲染透明幾何體以及具有 Screen Space - Camera 渲染模式的 UI 畫布。
• AfterForwardAlpha
• BeforeHaloAndLensFlares
• Unity 渲染鏡頭光暈。
• AfterHaloAndLensFlares
• BeforeImageEffects
• Unity 應用后期處理效果。
• AfterImageEffects
• AfterEverything
• Unity 對渲染模式不是 Screen Space - Camera 的 UI 畫布進行渲染。

2.4 LightEvent 執行順序

在上面的“渲染陰影”階段，對于每個投射陰影的光源，Unity 執行以下步驟：

• BeforeShadowMap
• BeforeShadowMapPass
• Unity 渲染當前通道的所有陰影投射器
• AfterShadowMapPass
• Unity 對每個通道重復最后三個步驟
• AfterShadowMap
• BeforeScreenSpaceMask
• Unity 將陰影貼圖收集到屏幕空間緩沖區中并執行過濾 *AfterScreenSpaceMask

3、內置渲染管線的硬件要求

3.1 摘要 (Summary)

	Win/Mac/Linux	iOS/Android	游戲主機
延遲光照	SM3.0、GPU 支持	-	是
前向渲染	是	是	是
頂點光照渲染	是	是	-
實時陰影	GPU 支持	GPU 支持	是
圖像效果	是	是	是
可編程著色器	是	是	是
固定函數著色器	是	是	-

3.2?實時陰影

????????實時陰影 (Realtime Shadows) 適用于大多數 PC、游戲主機和移動平臺。在 Windows (Direct3D) 上，GPU 還需要支持陰影貼圖功能；自 2003 年以后，大多數獨立 GPU 都支持這些功能，而自 2007 年以后，大多數集成 GPU 也支持這些功能。從技術上講，在 Direct3D 9 上，GPU 必須支持 D16/D24X8 或 DF16/DF24 紋理格式；在 OpenGL 上，必須支持 GL_ARB_depth_texture 擴展。

????????移動端陰影 (iOS/Android) 要求具備 OpenGL ES 2.0 和 GL_OES_depth_texture 擴展或者 OpenGL ES 3.0。最需要注意的是，該擴展在基于 Tegra 3 和 Tegra 4 的 Android 設備上不存在，因此陰影在這些設備上不起作用。

3.3 后期處理效果

????????后期處理效果要求有渲染到紋理功能；此功能通常在本世紀以來制造的硬件產品上都是受支持的。

3.4 著色器

????????可以編寫可編程著色器或固定函數著色器。可編程著色器在所有平臺上都受支持，默認為 Shader Model 2.0（桌面端）和 OpenGL ES 2.0（移動端）。如果想要更多功能，可定位更高版本的著色器模型。固定函數著色器在除游戲主機外的所有平臺上都受支持。

總結

以上是生活随笔為你收集整理的Unity-TA 成长之路（二）内置渲染管线-官方篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。