本文翻譯自Catlike Coding，原作者：Jasper Flick。

本文經(jīng)原作者授權(quán)，轉(zhuǎn)載請(qǐng)說明出處。

原文鏈接在下：

https://catlikecoding.com/unity/tutorials/scriptable-render-pipeline/custom-pipeline/catlikecoding.com

---

自定義管線?控制渲染

創(chuàng)建pipeline asset 和 instance.

剔除、過濾、排序、渲染.

保持內(nèi)存清潔.

提供良好的編輯體驗(yàn).

這是Unity scriptable render pipeline系列教程的第一部分。本教程假設(shè)你首先通過了Basics系列教程和Procedural Grid教程。Rendering系列的頭幾部分也很有幫助。

本教程使用Unity 2018.3.0f2完成。

創(chuàng)建一個(gè)Pipeline

渲染任何東西Unity都需要明確哪些形狀、何處、何時(shí)以及使用什么設(shè)置。這些可以變得非常復(fù)雜取決于涉及到多少效果。光源、陰影、半透明、圖像效果、體積效果以及等等都需要用正確的順序處理，以獲得最終的圖像。這個(gè)過程被稱之為渲染管線。

Unity 2017 支持兩種預(yù)定義渲染管線，一種是前向渲染，另一種是延遲渲染。也仍然支持Unity 5中引入的舊延遲渲染方法。這種管線是固定的。你可以開啟、關(guān)閉或者覆蓋管線中某些部分，但不可以徹底偏離它的設(shè)計(jì)。

Unity 2018 添加了可編程渲染管線的支持，使得從頭設(shè)計(jì)管線成為可能，盡管你仍然需要依賴Unity來完成許多單獨(dú)的步驟，例如剔除。Unity 2018引入了兩種使用這種新方法的管線，輕量級(jí)渲染管線和高分辨率渲染管線。兩種管線仍處于預(yù)覽階段并且可編程渲染管線API依然被標(biāo)記為實(shí)驗(yàn)技術(shù)。但是在這一點(diǎn)上對(duì)我們來說足夠穩(wěn)定可以繼續(xù)創(chuàng)建并創(chuàng)建我們自己的管線。

在這個(gè)教程中我們會(huì)設(shè)置一個(gè)繪制Unlit圖形的最小渲染管線。一旦起作用了，我們可以在之后的教程中擴(kuò)展我們的管線，添加光照、陰影、以及更多的高級(jí)特性。

1.1?項(xiàng)目設(shè)置

打開Unity 2018并創(chuàng)建一個(gè)新項(xiàng)目。我使用的是Unity 2018.2.9f1，但是任何2018.2版本或者更新版應(yīng)該也可以使用。創(chuàng)建一個(gè)Standard 3D項(xiàng)目并禁用analytics。我們會(huì)創(chuàng)建我們自己的管線，所以不選擇任何管線選項(xiàng)。

項(xiàng)目打開后，由Window/Pakage Manager打開包管理器，并且移除所有默認(rèn)包含的包，因?yàn)槲覀儾恍枰鼈儭Ｖ槐Ａ舨豢梢员灰瞥腜ackage Manager UI。

初始的項(xiàng)目

我們要在線性色彩空間下工作，但是Unity 2018依然默認(rèn)使用gamma空間。所以由Edit/Project Setting/Player到player setting中，然后將Other Setting部分中的色彩空間切換到Linear。

線性色彩空間

我們需要幾個(gè)簡(jiǎn)單的材質(zhì)去測(cè)試我們的管線。我創(chuàng)建了四種材質(zhì)。第一種，默認(rèn)的standard opaque材質(zhì)帶有紅色albedo。第二種，一樣的材質(zhì)但是Rendering Mode設(shè)置為Transparent以及藍(lán)色的albedo帶有減少的alpha。第三種，使用Unlit/Color shader并且顏色設(shè)置為黃色的材質(zhì)。最后一種使用Unlit/Transparent shader并不做任何改變，因此顯示為純白色。

測(cè)試材質(zhì)

使用一些object填充場(chǎng)景，讓它們用完所有的四種材質(zhì)。

場(chǎng)景顯示四種材質(zhì)

1.2?Pipeline Asset

現(xiàn)在，Unity使用默認(rèn)的前向渲染管線。要使用自定義管線，我們需要在grahics settings中選擇，可以由Edit/Project Setting/Graphics找到。

使用默認(rèn)管線

要設(shè)置我們自己的管線，我們需要分配一個(gè)pipeline asset到Scriptable Render Pipeline Settings字段。這類asset需要擴(kuò)展RenderPipelineAsset，這是一種ScriptableObject類型。

為我們的自定義pipeline asset創(chuàng)建一個(gè)新腳本。我們將簡(jiǎn)單地命名我們的管線為My Pipeline。這個(gè)asset類型將因此成為MyPipelineAsset并且需要擴(kuò)展RenderPipelineAsset，它被定義在UnityEngine.Experimental.Rendering命名空間中。

using UnityEngine;using UnityEngine.Experimental.Rendering;public class MyPipelineAsset : RenderPipelineAsset {}它會(huì)一直在experimental命名空間中嗎？
它會(huì)在某個(gè)時(shí)刻被移出experimental命名空間，到UnityEngine.Rendering或者其他命名空間。當(dāng)這種情況發(fā)生時(shí)，只需要更新using語句，除非API也發(fā)生了改變。

pipeline asset的主要目的是給Unity一個(gè)途徑去獲取負(fù)責(zé)渲染的管線對(duì)象實(shí)例。asset它本身只是一個(gè)句柄和存放管線設(shè)置的地方。我們目前還沒有任何設(shè)置，所以我們要做的是給Unity一個(gè)途徑去獲取我們的管線對(duì)象實(shí)例。這個(gè)通過重載InternalCreatePipeline方法來實(shí)現(xiàn)。但是我們還沒有定義我們的管線對(duì)象，所以此時(shí)我們將僅返回null。

InternalCreatePipeline返回值類型是IRenderPipeline。類型名的I前綴表示它是接口類型。

public class MyPipelineAsset : RenderPipelineAsset { protected override IRenderPipeline InternalCreatePipeline () { return null; }}什么是接口？
接口就像一個(gè)類，除了定義一個(gè)功能合同且不提供它的實(shí)現(xiàn)。它只定義屬性、事件、索引器和方法簽名，它們都是被定義公開的。任何擴(kuò)展接口的類型都要求包含接口定義的實(shí)現(xiàn)。慣例是在接口名前加個(gè)I前綴。
因?yàn)榻涌诓话唧w的實(shí)現(xiàn)，所以類甚至結(jié)構(gòu)體可以擴(kuò)展多個(gè)接口。如果多個(gè)接口碰巧定義了相同的東西，它們只是同意功能應(yīng)該存在。在類中是不可以的即使是抽象類，因?yàn)檫@個(gè)可能導(dǎo)致實(shí)現(xiàn)沖突。

現(xiàn)在我們需要為我們的項(xiàng)目添加一個(gè)這種類型的asset。要實(shí)現(xiàn)這點(diǎn)，添加CreateAssetMenu特性到MyPipelineAsset。

[CreateAssetMenu]public class MyPipelineAsset : RenderPipelineAsset {}

這在Asset/Create菜單中添加了個(gè)入口。讓我們整理一下，把他放到Rendering的子菜單中。我們通過設(shè)置特性的menuName屬性為Rendering/My Pipeline來完成。這個(gè)屬性在可以被直接設(shè)置在特性類型之后的圓括號(hào)中。

[CreateAssetMenu(menuName = "Rendering/My Pipeline")]public class MyPipelineAsset : RenderPipelineAsset {}

使用新菜單項(xiàng)添加這個(gè)asset到項(xiàng)目，命名為My Pipeline。

Pipeline asset及其腳本

然后把它分配到Scriptable Render Pipeline Settings。

使用中的Asset

我們現(xiàn)在已經(jīng)替換了默認(rèn)的管線，更改了一些東西。首先，graphics setting中的大量選項(xiàng)不見了，Unity也在信息面板中提到了這些設(shè)置。其次，我們繞過了默認(rèn)管線并不提供有效的替換，因此不會(huì)進(jìn)行任何渲染。盡管，場(chǎng)景窗口仍然顯示天空盒，但是游戲窗口、場(chǎng)景窗口和材質(zhì)預(yù)覽不再起作用，如果你由Window/Analysis/Frame Debugger打開幀調(diào)試器，并且啟用它，你會(huì)看見確實(shí)沒有在游戲窗口中繪制任何東西。

1.3?管線實(shí)例

創(chuàng)建一個(gè)有效的管線，我們需要提供一個(gè)實(shí)現(xiàn)IRenderPipeline并負(fù)責(zé)渲染流程的對(duì)象實(shí)例。所以為此創(chuàng)建一個(gè)類將其命名為MyPipeline。

using UnityEngine;using UnityEngine.Experimental.Rendering;public class MyPipeline : IRenderPipeline {}

盡管我們可以實(shí)現(xiàn)由自己IRenderPipeline，但是更方便的是擴(kuò)展RenderPipeline類。這個(gè)類型已經(jīng)提供一個(gè)IRenderPipeline我們可以自己構(gòu)建的實(shí)現(xiàn)。

public class MyPipeline : RenderPipeline {}

現(xiàn)在我們可以在InternalCreatePipeline中返回一個(gè)MyPipeline的新實(shí)例。這意味著我們?cè)诩夹g(shù)上有了一個(gè)有效的管線，盡管這依然不能渲染任何東西。

protected override IRenderPipeline InternalCreatePipeline () { return new MyPipeline(); }

2.?渲染

管線對(duì)象負(fù)責(zé)渲染每一幀。Unity會(huì)根據(jù)上下文以及激活的相機(jī)調(diào)用管線的Render方法。這是針對(duì)游戲窗口的，也適用于場(chǎng)景窗口和編輯器中的材質(zhì)預(yù)覽。這需要我們適當(dāng)?shù)嘏渲?#xff0c;找到需要渲染的內(nèi)容，并且按正確的順序處理每個(gè)操作。

2.1?上下文

RenderPipeline包含了定義在IRenderPipeline接口中的Render方法的實(shí)現(xiàn)。它第一個(gè)參數(shù)是渲染上下文，這是ScriptableRenderContext結(jié)構(gòu)，作為native code的外在表現(xiàn)。這第二個(gè)參數(shù)是一個(gè)包含所有需要渲染的相機(jī)的數(shù)組。

RenderPipeline.Render不繪制任何東西，但是會(huì)檢查管線對(duì)象是否有效用于渲染。如果無效，則會(huì)引發(fā)一個(gè)異常。我們會(huì)重載這個(gè)方法并調(diào)用基類的實(shí)現(xiàn)，來保證這個(gè)檢測(cè)。

public class MyPipeline : RenderPipeline { public override void Render ( ScriptableRenderContext renderContext, Camera[] cameras) { base.Render(renderContext, cameras); }}

通過渲染上下文我們可以向Unity引擎發(fā)出指令去渲染和控制渲染狀態(tài)。一個(gè)最簡(jiǎn)單的例子是繪制天空盒，它可以通過調(diào)用DrawSkybox方法來完成。

base.Render(renderContext, cameras); renderContext.DrawSkybox();

DrawSkybox要求相機(jī)作為參數(shù)，我們會(huì)簡(jiǎn)單的使用cameras中的第一個(gè)元素。

renderContext.DrawSkybox(cameras[0]);

我們?cè)谟螒虼翱谥幸廊豢床灰娞炜蘸酗@示。這是因?yàn)槲覀儼l(fā)到上下文的指令在緩沖。實(shí)際的工作發(fā)生在我們由Submit方法提交執(zhí)行之后。

renderContext.DrawSkybox(cameras[0]);??renderContext.Submit();

天空盒最終呈現(xiàn)在游戲窗口，你也可以看見它出現(xiàn)在frame debugger中。

幀調(diào)試器顯示天空盒被繪制

2.2?相機(jī)

我們提供了一系列相機(jī)，因?yàn)閳?chǎng)景中會(huì)可以存在多個(gè)相機(jī)，它們都會(huì)被渲染。例如利用多相機(jī)設(shè)置多人分屏，小地圖以及后視鏡。每個(gè)相機(jī)都需要單獨(dú)處理。

現(xiàn)在我們不用擔(dān)心多個(gè)相機(jī)支持我們的管線。我們將簡(jiǎn)單地創(chuàng)建一個(gè)另一種渲染方法其作用于單個(gè)相機(jī)。用它來繪制天空盒并提交。所以我們要提交每個(gè)相機(jī)。

void Render (ScriptableRenderContext context, Camera camera) { context.DrawSkybox(camera); context.Submit(); }

為camers數(shù)組的每個(gè)元素調(diào)用新方法。這個(gè)例子中我使用一個(gè)foreach循環(huán)，因?yàn)閁nity的管線也是用這個(gè)方法來循環(huán)相機(jī)數(shù)組。

public override void Render ( ScriptableRenderContext renderContext, Camera[] cameras) { base.Render(renderContext, cameras); //renderContext.DrawSkybox(cameras[0]); //renderContext.Submit(); foreach (var camera in cameras) { Render(renderContext, camera); } }foreach循環(huán)是是如何工作的？
foreach (var e in a) { ... }相當(dāng)于
for (int i = 0; i < a.Length; a++) { var e = a[i]; ... }假設(shè)a是一個(gè)數(shù)組。唯一的功能性區(qū)別在于我們不可以獲取迭代器變量i。
當(dāng)a不是一個(gè)數(shù)組而是其他可枚舉類型，迭代器會(huì)起作用并且最后會(huì)創(chuàng)建臨時(shí)對(duì)象，這最好是要避免的。但是使用foreach對(duì)數(shù)組是安全的。
使用var定義元素變量是常見的，所以我使用它。它的類型是a的元素類型。

注意當(dāng)前相機(jī)朝向不影響天空盒的渲染。我們傳遞相機(jī)到DrawSkybox，但是它只決定天空盒是否會(huì)被渲染，這是由相機(jī)的clear flag控制的。

要正確渲染天空盒以及整個(gè)場(chǎng)景，我們需要設(shè)置view-projection矩陣。這個(gè)變換矩陣組合了相機(jī)的位置和朝向的view矩陣，以及相機(jī)是透視或正交投影的projection矩陣。你可以在frame debugger中看見這個(gè)矩陣。它就是unity_MatrixVP，當(dāng)有東西被繪制時(shí)所使用的shader屬性之一。

目前，unity_MatrixVP矩陣總是相同的。我們需要使用SetupCameraProperties方法設(shè)置相機(jī)的屬性到上下文中。這會(huì)設(shè)置矩陣以及其他的屬性。

void Render (ScriptableRenderContext context, Camera camera) { context.SetupCameraProperties(camera); context.DrawSkybox(camera); context.Submit(); }

現(xiàn)在天空盒被正確的渲染了，在游戲窗口和場(chǎng)景窗口中都考慮到了相機(jī)屬性。

2.3?命令緩存

上下文會(huì)推遲實(shí)際的渲染直到我們提交它。在這之前，我們對(duì)其配置并添加命令以供之后執(zhí)行。有些任務(wù)像是繪制天空盒可以由專用的方法發(fā)出，但是其他的指令必須要由獨(dú)立的命令緩存間接地發(fā)送。

命令緩沖可以被實(shí)例化一個(gè)新的CommandBuffer對(duì)象所創(chuàng)建，這個(gè)被定義在UnityEngine.Rendering名稱空間中。在可編程渲染管線加入之前命令緩存就已經(jīng)存在了，所以它不是實(shí)驗(yàn)性的。在我們繪制天空盒之前創(chuàng)建這樣的一個(gè)緩存。

using UnityEngine;using UnityEngine.Rendering;using UnityEngine.Experimental.Rendering;public class MyPipeline : RenderPipeline { … void Render (ScriptableRenderContext context, Camera camera) { context.SetupCameraProperties(camera); var buffer = new CommandBuffer(); context.DrawSkybox(camera); context.Submit(); }}

我們可以使用ExecuteCommandBuffer方法命令上下文執(zhí)行緩存。再說明一下，上下文不會(huì)立即執(zhí)行命令，而是復(fù)制他們到上下文的內(nèi)部緩存中。

var buffer = new CommandBuffer(); context.ExecuteCommandBuffer(buffer);

在Unity引擎的native level中，命令緩存聲明了資源用于儲(chǔ)存它們的命令。如果我們不再需要這些資源，那最好立即釋放他們。這個(gè)可以通過在調(diào)用ExecuteCommandBuffer之后直接調(diào)用緩存的Release方法完成。

var buffer = new CommandBuffer(); context.ExecuteCommandBuffer(buffer); buffer.Release();

執(zhí)行一個(gè)空命令緩存沒有任何作用。我們添加它以便我們清除render target，以確保渲染沒有被之前的繪制所影響。這可以由命令緩存執(zhí)行，但不可以直接由上下文執(zhí)行。

清除命令可以調(diào)用ClearRenderTarget來添加到緩存中。它要求三個(gè)參數(shù)：兩個(gè)booleans和一個(gè)color，并且如果使用了第三個(gè)參數(shù)的話，它是清除的顏色。舉例，讓我們清除清除深度數(shù)據(jù)，忽略顏色數(shù)據(jù)，并使用Color.clear作為清除顏色。

var buffer = new CommandBuffer(); buffer.ClearRenderTarget(true, false, Color.clear); context.ExecuteCommandBuffer(buffer); buffer.Release();

frame debugger現(xiàn)在會(huì)向我們顯示清除render target的命令緩存被執(zhí)行了。在這個(gè)案例中，它指定Z和stencil被清除了。Z指的是depth buffer，而stencil buffer始終被清除的。

清除depth和stencil緩沖

每個(gè)相機(jī)通過它們的clear flags和background color配置決定被清除的內(nèi)容。我們可以使用這些來代替硬編碼指定清除render target。

CameraClearFlags clearFlags = camera.clearFlags; buffer.ClearRenderTarget( (clearFlags & CameraClearFlags.Depth) != 0, (clearFlags & CameraClearFlags.Color) != 0, camera.backgroundColor );clear flag是如果工作的？
CameraClearFlags是一個(gè)枚舉類型，它可以被用來設(shè)置bit flags。它的值的每一個(gè)比特位被用來指定某些特性被開啟或是關(guān)閉。
要從整個(gè)值中提取bit flag，值與所需標(biāo)志位通過按位與(操作符 &)來組合。如果結(jié)果不為零，則設(shè)置這個(gè)標(biāo)志。

因?yàn)槲覀儧]有給命令緩存命名，調(diào)試器顯示的是默認(rèn)名字，即Unamed command buffer。讓我們相機(jī)名來代替，就是將它分配給緩存的name屬性。我們將使用對(duì)象初始化器語法來完成。

var buffer = new CommandBuffer { name = camera.name };給命令緩存使用相機(jī)名對(duì)象初始化器語法是如何工作的？
我們不用再寫buffer.name = camera.name;作為獨(dú)立的語句在調(diào)用構(gòu)造函數(shù)之后。但是當(dāng)創(chuàng)建新的對(duì)象時(shí)，你可以在構(gòu)造函數(shù)指令中加一個(gè)代碼塊。然后你可以在塊中設(shè)置對(duì)象的字段和屬性，不用再顯式地引用對(duì)象實(shí)例。并且，它明確地指出只有這些字段和域被設(shè)置后實(shí)例才可用。除此之外，它可以只有一個(gè)單獨(dú)的語句的初始化，不再需要有許多參數(shù)變體的構(gòu)造函數(shù)。
注意，我們省略了構(gòu)造函數(shù)的空參數(shù)列表，這在使用對(duì)象初始化器語法時(shí)是被允許的。

2.4?剔除

我們可以渲染天空盒了，但是還不能渲染任何我們放在場(chǎng)景中的對(duì)象。我們只需要渲染相機(jī)能看見的而不是所有對(duì)象。從場(chǎng)景中的所有渲染器開始，然后剔除那些落在相機(jī)視錐體的之外的渲染器。

什么是渲染器？
它是一個(gè)組件附加在游戲?qū)ο笊?#xff0c;將他們轉(zhuǎn)變?yōu)榭梢载愪秩镜臇|西。比較典型的是MeshRenderer組件。

找出可以被剔除的渲染器需要我們追蹤多個(gè)相機(jī)的設(shè)置和矩陣，對(duì)于這個(gè)我們使用ScriptableCullingParameters結(jié)構(gòu)體?？梢杂梦徐o態(tài)CullResults.GetCullingParameters方法來替代自己填充結(jié)構(gòu)體。它需要一個(gè)相機(jī)作為輸入并生成剔除參數(shù)作為輸出。然而，他并不能返回參數(shù)結(jié)構(gòu)體。相反，我們需要提供結(jié)構(gòu)體作為第二個(gè)輸出參數(shù)，在結(jié)構(gòu)體前加上out。

void Render (ScriptableRenderContext context, Camera camera) { ScriptableCullingParameters cullingParameters; CullResults.GetCullingParameters(camera, out cullingParameters); … }我們?yōu)槭裁匆獙憃ut？
結(jié)構(gòu)體是值類型，所以他們被作為普通的值來對(duì)待。他們不是擁有身份的對(duì)象，帶有變量和僅保存對(duì)他們?cè)趦?nèi)存位置的引用的字段。所以參數(shù)傳遞結(jié)構(gòu)體會(huì)提供一個(gè)帶有值的拷貝的方法。這個(gè)方法可以改變拷貝，但是對(duì)被拷貝的值沒有影響。
當(dāng)結(jié)構(gòu)體參數(shù)被定義為輸出參數(shù)，他就扮演一個(gè)類似于對(duì)象的引用，但是指向的是參數(shù)所在的內(nèi)存棧。當(dāng)方法改變參數(shù)時(shí)，它影響的是值，而不是拷貝。
out關(guān)鍵字告訴我們這個(gè)方法負(fù)責(zé)給參數(shù)設(shè)置正確的值，代替以前的值。

除了輸出參數(shù)，GetCullingParameters也會(huì)返回它是否可以創(chuàng)建有效的參數(shù)。不是所有的相機(jī)設(shè)置都是有效的，結(jié)果就是退化，它不可以被用于剔除。所以如果它失敗了，我們沒有東西可以渲染并從Render中退出。

if (!CullResults.GetCullingParameters(camera, out cullingParameters)) { return; }

一旦我們有剔除參數(shù)了，就可以用于剔除。通過調(diào)用同時(shí)帶有剔除參數(shù)和上下文作為參數(shù)的靜態(tài)CullResults.Cull方法來完成。結(jié)果就是一個(gè)包含了可見內(nèi)容的信息的CullResults結(jié)構(gòu)體。

在這個(gè)案例中，我們需要通過在它前面添加ref提供剔除參數(shù)作為引用參數(shù)。

if (!CullResults.GetCullingParameters(camera, out cullingParameters)) { return; } CullResults cull = CullResults.Cull(ref cullingParameters, context);為什么我們要寫ref？
它就像out一樣，除了在這個(gè)案例中，這個(gè)方法不要求給值賦值。并且無論誰調(diào)用這個(gè)方法都負(fù)責(zé)首先正確初始化這個(gè)值。所以它可以被用來樹葉也可以用于輸出。
為什么ScriptableCullingParameters是結(jié)構(gòu)體？
這可能是一種優(yōu)化嘗試，這個(gè)想法是你可以創(chuàng)建多個(gè)參數(shù)結(jié)構(gòu)體而不必?fù)?dān)心內(nèi)存分配。但是，ScriptableCullingParameters是一個(gè)非常大的結(jié)構(gòu)體，這也是為什么引用參數(shù)被用在這里，再次出于性能的考慮。也許它開始時(shí)很小但是隨著時(shí)間膨脹成大的結(jié)構(gòu)體。現(xiàn)在，可復(fù)用的結(jié)構(gòu)體實(shí)例可能是更好的方法，但是我們只能用Unity技術(shù)所決定的。

2.5?繪制

一旦我們知道什么是可見的，我們就可以繼續(xù)渲染這些形狀。這是通過在上下文調(diào)用DrawRenderers，以cull.visibleRenderers作為參數(shù)，告訴它使用哪些渲染器來完成的。除此之外，我們還必須提供繪制設(shè)置和過濾設(shè)置。這者都是結(jié)構(gòu)體-?DrawRendererSettings和FilterRenderersSettings確切來說，我們初始時(shí)使用它們的默認(rèn)值。必須將繪圖設(shè)置作為引用傳遞。

buffer.Release(); var drawSettings = new DrawRendererSettings(); var filterSettings = new FilterRenderersSettings(); context.DrawRenderers( cull.visibleRenderers, ref drawSettings, filterSettings ); context.DrawSkybox(camera);為什么是FilterRenderersSettings而不是FilterRendererSettings呢？
不知道。也許是打錯(cuò)了。

我們還沒有看到任何對(duì)象，因?yàn)槟J(rèn)的過濾設(shè)置不包含任何內(nèi)容。我們可以通過給FilterRenderersSettings的構(gòu)造函數(shù)提供true參數(shù)來包含所有內(nèi)容。這告訴它初始化自己，所以它包括所有內(nèi)容。

var filterSettings = new FilterRenderersSettings(true);

此外，我們必須通過為其構(gòu)造函數(shù)提供相機(jī)和shader pass作為參數(shù)來配置繪制設(shè)置。相機(jī)用于設(shè)置排序和剔除圖層，而pass參數(shù)控制哪些shader pass用于渲染。

shader pass通過字符串來標(biāo)識(shí)，該字符串必須封裝在ShaderPassName結(jié)構(gòu)體中。由于在我們的管線中只支持unlit材料，因此我們將使用Unity默認(rèn)的unlit材質(zhì)，通過SRPDefaultUnlit字符串來識(shí)別。

var drawSettings = new DrawRendererSettings( camera, new ShaderPassName("SRPDefaultUnlit") );不透明球體現(xiàn)在可見了。

我們只看到不透明的unlit形狀出現(xiàn)，但是沒有透明的unlit。但是，幀調(diào)試器顯示unlit的形狀都被繪制了。

所有unlit渲染器都被繪制出來。

它們確實(shí)被繪制，但由于透明shader pass不會(huì)寫入深度緩沖區(qū)，因此它們最終會(huì)被天空盒覆蓋。解決方案是延遲繪制透明渲染器，直到天空盒被繪制之后。

首先，將天空盒之前的繪制限制為僅使用不透明的渲染器。這通過將過濾設(shè)置中的renderQueueRange設(shè)置為RenderQueueRange.opaque來完成的，該設(shè)置涵蓋了從0到2500(含2500)的渲染隊(duì)列。

var filterSettings = new FilterRenderersSettings(true) { renderQueueRange = RenderQueueRange.opaque };

只有不透明渲染器被繪制了。

接下來，改變隊(duì)列范圍至RenderQueueRange.transparent- 從2501到5000(含5000)-在渲染天空盒之后，然后再次渲染。

var filterSettings = new FilterRenderersSettings(true) { renderQueueRange = RenderQueueRange.opaque }; context.DrawRenderers( cull.visibleRenderers, ref drawSettings, filterSettings ); context.DrawSkybox(camera); filterSettings.renderQueueRange = RenderQueueRange.transparent; context.DrawRenderers( cull.visibleRenderers, ref drawSettings, filterSettings );不透明，天空盒然后透明。

我們?cè)谔炜蘸兄袄L制不透明的渲染器以防止重復(fù)繪制。由于形狀繪制總是在天空盒之前，所以我們先渲染形狀就避免多余的工作了。那是因?yàn)椴煌该鞯膕hader pass會(huì)寫入深度緩沖區(qū)，該緩沖區(qū)用于跳過稍后繪制的任何東西。

除了覆蓋部分天空，不透明的渲染器最終也會(huì)相互遮擋。理想情況下，對(duì)幀緩沖區(qū)中的每個(gè)fragment，只有最靠近攝像機(jī)的那個(gè)會(huì)被繪制。因此，為了盡可能減少重復(fù)繪制，我們應(yīng)該先繪制最近的形狀。這可以通過在繪制之前對(duì)渲染器進(jìn)行排序來完成，這是通過sorting flags來控制的。

繪制設(shè)置包含一個(gè)DrawRendererSortSettings類型的sorting結(jié)構(gòu)體，其中包含sorting flags。在繪制不透明形狀之前將它設(shè)置為SortFlags.CommonOpaque。這指示Unity按距離，從前到后以及其他一些標(biāo)準(zhǔn)對(duì)渲染器進(jìn)行排序。

var drawSettings = new DrawRendererSettings( camera, new ShaderPassName("SRPDefaultUnlit") ); drawSettings.sorting.flags = SortFlags.CommonOpaque;

然而，透明渲染的工作方式不同。它將繪制的顏色與已經(jīng)繪制的顏色相結(jié)合，因此結(jié)果顯得透明。這需要從后到前的反轉(zhuǎn)繪制順序。對(duì)于這種情況我們可以使用SortFlags.CommonTransparent。

context.DrawSkybox(camera); drawSettings.sorting.flags = SortFlags.CommonTransparent; filterSettings.renderQueueRange = RenderQueueRange.transparent; context.DrawRenderers( cull.visibleRenderers, ref drawSettings, filterSettings );

我們的管線現(xiàn)在能夠正確地同時(shí)渲染不透明和透明的unlit物體。

3.?完善

能夠正確地渲染只是擁有功能性管線的一部分。還有其他的東西需要去考慮，例如它是否足夠快，不分配不必要的臨時(shí)對(duì)象，以及與Unity編輯器更好的集成。

3.1?內(nèi)存分配

讓我們檢查管線在內(nèi)存管理方面是否表現(xiàn)良好，或者它在每一幀分配內(nèi)存，是否頻繁地觸發(fā)內(nèi)存GC。通過Window/Analysis/Profiler打開分析器并在Hierarchy模式下檢查CPU占用數(shù)據(jù)。雖然你可以在編輯器中在play模式下打開分析器，但是最好是分析構(gòu)建后的項(xiàng)目，通過創(chuàng)建一個(gè)development build并使它自動(dòng)附加到分析器中，但是在這種情況下沒法深度分析。

選擇GC Alloc排序，你會(huì)發(fā)現(xiàn)每幀確實(shí)都分配了內(nèi)存。其中有些不屬于我們的控制范圍，但是在管線的Render方法中分配了不少的字節(jié)。

最后的結(jié)果是剔除分配的內(nèi)存最多。這個(gè)原因是CullResults雖然是個(gè)結(jié)構(gòu)體，但是它包含了三個(gè)列表，它們都是對(duì)象。每次我們申請(qǐng)新的cull result時(shí)，最后都會(huì)為新的列表分配內(nèi)存。所以CullResults是個(gè)結(jié)構(gòu)體也沒多大的好處。

幸好，CullResults有另外的Cull方法，它接受一個(gè)結(jié)構(gòu)體作為引用參數(shù)，而不是返回個(gè)新的。這樣列表就可以重復(fù)使用。我們需要做的就是把cull變成字段并把它提供給CullResults.Cull作為增加的參數(shù)，而不是將返回值分配給他。

CullResults cull; … void Render (ScriptableRenderContext context, Camera camera) { … //CullResults cull = CullResults.Cull(ref cullingParameters, context); CullResults.Cull(ref cullingParameters, context, ref cull); … }

另一個(gè)持續(xù)的內(nèi)存分配原因是我們使用的相機(jī)的名字屬性。每次我們給它值時(shí)，它從native code中獲取名字?jǐn)?shù)據(jù)，它必須要?jiǎng)?chuàng)建一個(gè)字符串，而這是一個(gè)對(duì)象。所以讓我們將命令緩沖命名為Render Camera。

var buffer = new CommandBuffer() { name = "Render Camera" };

使用常量緩沖名。

最后，命令緩沖它自己也是一個(gè)對(duì)象。幸好，我們可以創(chuàng)建一次命令緩存并復(fù)用它。使用cameraBuffer字段來替換局部變量。感謝對(duì)象初始化器語法，我們可以創(chuàng)建一個(gè)命名了的命令緩沖作為默認(rèn)值。其他的改變就是我們需要清空命令緩沖而不是釋放它，這個(gè)可以使用它的Clear方法。

CommandBuffer cameraBuffer = new CommandBuffer { name = "Render Camera" }; … void Render (ScriptableRenderContext context, Camera camera) { … //var buffer = new CommandBuffer() { // name = "Render Camera" //}; cameraBuffer.ClearRenderTarget(true, false, Color.clear); context.ExecuteCommandBuffer(cameraBuffer); //buffer.Release(); cameraBuffer.Clear(); … }

完成這些更改后，我們的管線不再每幀創(chuàng)建臨時(shí)對(duì)象了。

3.2?幀調(diào)試器采樣

還有一件我們可以做的事是改進(jìn)frame debugger顯示的數(shù)據(jù)。Unity的管線顯示事件的嵌套層次結(jié)構(gòu)，但是我們的管線都在根一級(jí)。可以使用命令緩沖去開始和結(jié)束采樣來構(gòu)建一個(gè)層次結(jié)構(gòu)。

讓我們?cè)贑learRenderTarget之前調(diào)用BeginSample，立即在它之后調(diào)用EndSample。每次采樣必須都要包含開始和結(jié)束，而且都要提供完全相同的名字。除此之外，我發(fā)現(xiàn)最好使用和命令緩沖相同的名字來定義采樣?？傊?#xff0c;命令緩沖的名字經(jīng)常被使用。

cameraBuffer.BeginSample("Render Camera"); cameraBuffer.ClearRenderTarget(true, false, Color.clear); cameraBuffer.EndSample("Render Camera"); context.ExecuteCommandBuffer(cameraBuffer); cameraBuffer.Clear();采樣創(chuàng)建了一個(gè)層次結(jié)構(gòu)。

我們現(xiàn)在看見一個(gè)Render Camera層次內(nèi)嵌在命令緩沖的原生Render Camera中，而它又包含清空操作。但是可以更進(jìn)一步，內(nèi)嵌所有其他與相機(jī)有關(guān)的動(dòng)作。這要求我們延后調(diào)用結(jié)束采樣直到我們提交上下文之前。所以我們必須在此插入一個(gè)附加的ExecuteCommandBuffer，僅包含結(jié)束采樣的指令。為此使用相同的命令緩沖，并在完成后再次清空它。

cameraBuffer.BeginSample("Render Camera"); cameraBuffer.ClearRenderTarget(true, false, Color.clear); //cameraBuffer.EndSample("Render Camera"); context.ExecuteCommandBuffer(cameraBuffer); cameraBuffer.Clear(); … cameraBuffer.EndSample("Render Camera"); context.ExecuteCommandBuffer(cameraBuffer); cameraBuffer.Clear(); context.Submit();嵌套的采樣。

這看起來不錯(cuò)，除了清空動(dòng)作內(nèi)嵌在多余的Render Camera層級(jí)中，而所有其他的動(dòng)作都直接處于根層級(jí)之下。我不確定為什么會(huì)發(fā)生這種事，但是可以通過在清除之后開始采樣來避免它。

//cameraBuffer.BeginSample("Render Camera"); cameraBuffer.ClearRenderTarget(true, false, Color.clear); cameraBuffer.BeginSample("Render Camera"); context.ExecuteCommandBuffer(cameraBuffer); cameraBuffer.Clear();

沒有多余的的嵌套。

3.3?渲染默認(rèn)管線。

因?yàn)槲覀兊墓芫€只支持unlit shaders，使用其他著色器的對(duì)象就不會(huì)被渲染，進(jìn)而它們就不可見。雖然這是正確的，但是它隱藏了一些使用錯(cuò)誤著色器的對(duì)象。如果我們使用Unity的error shader讓它們可見的話，這會(huì)更好些。因此它們會(huì)顯示為明顯不正常的洋紅色形狀。為此，讓我們添加一個(gè)專門的DrawDefaultPipeline方法，帶有一個(gè)上下文和一個(gè)相機(jī)參數(shù)。我們會(huì)在最后調(diào)用它，在繪制了透明形狀之后。

void Render (ScriptableRenderContext context, Camera camera) { … drawSettings.sorting.flags = SortFlags.CommonTransparent; filterSettings.renderQueueRange = RenderQueueRange.transparent; context.DrawRenderers( cull.visibleRenderers, ref drawSettings, filterSettings ); DrawDefaultPipeline(context, camera); cameraBuffer.EndSample("Render Camera"); context.ExecuteCommandBuffer(cameraBuffer); cameraBuffer.Clear(); context.Submit(); } void DrawDefaultPipeline(ScriptableRenderContext context, Camera camera) {}

Unity的默認(rèn)surface shader有一個(gè)ForwardBase pass，它用來作為第一個(gè)前向渲染pass。我們可以使用它來識(shí)別那些擁有工作在默認(rèn)管線下的材質(zhì)的對(duì)象。通過新建繪制設(shè)置來選擇這個(gè)pass以及和新建的過濾設(shè)置一起作用于渲染。我們不關(guān)心排序或者分離不透明與透明渲染器，因?yàn)榉凑鼈兌际菬o效的。

void DrawDefaultPipeline(ScriptableRenderContext context, Camera camera) { var drawSettings = new DrawRendererSettings( camera, new ShaderPassName("ForwardBase") ); var filterSettings = new FilterRenderersSettings(true); context.DrawRenderers( cull.visibleRenderers, ref drawSettings, filterSettings ); }渲染前向pass。

現(xiàn)在使用默認(rèn)著色器的對(duì)象顯示出來了。它們?cè)趂rame debugger中也是可見的。

所有的對(duì)象都被渲染了。

因?yàn)槲覀兊墓芫€不支持forward base pass它們不會(huì)被正確地渲染。必要的數(shù)據(jù)沒有被設(shè)置，因此所有那些依賴光線的對(duì)象最后都是黑色的。然而，我們應(yīng)該用error shader來渲染它們。為此，需要一個(gè)error材質(zhì)。為它添加一個(gè)字段。然后，在DrawDefaultPipeline開始時(shí)，創(chuàng)建error材質(zhì)(如果它不存在的話)。這可以通過Shader.Find遍歷Hidden/InternalErrorShader來完成，然后創(chuàng)建一個(gè)新材質(zhì)使用此著色器。此外，將材質(zhì)的hide flags設(shè)置為HideFlags.HideAndDonSave讓它不會(huì)顯示在project窗口中并且也不會(huì)和其他的asset一起被保存。

Material errorMaterial; … void DrawDefaultPipeline(ScriptableRenderContext context, Camera camera) { if (errorMaterial == null) { Shader errorShader = Shader.Find("Hidden/InternalErrorShader"); errorMaterial = new Material(errorShader) { hideFlags = HideFlags.HideAndDontSave }; } … }

繪制設(shè)置的一個(gè)選項(xiàng)是覆蓋渲染時(shí)使用的材質(zhì)，通過調(diào)用SetOverrideMaterial。它的第一個(gè)參數(shù)是要使用的材質(zhì)。第二個(gè)參數(shù)是要用于渲染的材質(zhì)著色器的pass的索引。由于error shader只有一個(gè)pass，所以索引為0；

var drawSettings = new DrawRendererSettings( camera, new ShaderPassName("ForwardBase") ); drawSettings.SetOverrideMaterial(errorMaterial, 0);使用error shader。

使用不被支持的材質(zhì)的對(duì)象現(xiàn)在清楚地顯示為錯(cuò)誤的。但是這個(gè)只適用于Unity默認(rèn)管線的材質(zhì)，其著色器具有ForwardBase pass。我們可以使用不同的pass識(shí)別其他的內(nèi)置著色器，特別是PrepassBase，Always，Vertex，VertexLMRGBM和VertexLM。

還好，可以通過調(diào)用SetShaderPassName來添加多個(gè)pass到繪制設(shè)置中。這個(gè)方法的第二個(gè)參數(shù)是名字。它的第一個(gè)參數(shù)是一個(gè)索引用于控制pass被繪制的順序索引。我們不用關(guān)心這個(gè)，所以什么順序都是可以的。pass由構(gòu)造函數(shù)提供，它的索引總是為零，所以為添加的pass遞增索引值。

var drawSettings = new DrawRendererSettings( camera, new ShaderPassName("ForwardBase") ); drawSettings.SetShaderPassName(1, new ShaderPassName("PrepassBase")); drawSettings.SetShaderPassName(2, new ShaderPassName("Always")); drawSettings.SetShaderPassName(3, new ShaderPassName("Vertex")); drawSettings.SetShaderPassName(4, new ShaderPassName("VertexLMRGBM")); drawSettings.SetShaderPassName(5, new ShaderPassName("VertexLM")); drawSettings.SetOverrideMaterial(errorMaterial, 0);

這覆蓋了Unity到現(xiàn)在提供的所有著色器，它們應(yīng)該滿足在創(chuàng)建場(chǎng)景時(shí)指出使用不正確材質(zhì)了。但是我們只需要在開發(fā)期間這樣做，不是在構(gòu)建中。所以讓我們只在編輯器中調(diào)用DrawDefaultPipeline。一個(gè)辦法是給方法添加Conditional特性。

3.4?條件代碼執(zhí)行

Conditional特性定義在System.Diagnostics名稱空間中。我們可以使用這個(gè)名稱空間，但不幸的是它還包含一個(gè)Debug類型，與UnityEngine.Debug沖突。由于我們只需要這個(gè)特性，可以使用別名來避免沖突。不使用完整的名稱空間，我們使用指定的類型并分配一個(gè)有效的類型名。在這個(gè)情況下，我們將定義Conditional作為System.Diagnostics.ConditionalAttribute的別名。

using UnityEngine;using UnityEngine.Rendering;using UnityEngine.Experimental.Rendering;using Conditional = System.Diagnostics.ConditionalAttribute;

添加特性給我們的方法。它要求一個(gè)字符串參數(shù)來指定符號(hào)。如果在編譯期間定義了這個(gè)符號(hào)，那么這個(gè)方法調(diào)用將被正常地包含。但是如果符號(hào)沒有定義，則這個(gè)方法的調(diào)用(包括所有的參數(shù))都被忽略。就好像DrawDefaultPipelint(context, camera);代碼好像不存在于編譯期一樣。

要僅在Unity編輯器編譯時(shí)包含調(diào)用，需要依賴UNITY_EDITOR符號(hào)。

[Conditional("UNITY_EDITOR")] void DrawDefaultPipeline(ScriptableRenderContext context, Camera camera) { … }

我們可以再進(jìn)一步，還在development builds中包含調(diào)用，僅排除release builds。為此添加DEVELOPMENT_BUILD作為額外的條件。

[Conditional("DEVELOPMENT_BUILD"), Conditional("UNITY_EDITOR")] void DrawDefaultPipeline(ScriptableRenderContext context, Camera camera) { … }

3.5?場(chǎng)景窗口里的UI

到目前為止，還有一件我們沒有考慮到的事是Unity的游戲內(nèi)UI。要測(cè)試它，添加一個(gè)UI元素到場(chǎng)景中，例如一個(gè)按鍵，通過GameObject/UI/Button。它創(chuàng)建一個(gè)帶有button的canvas和一個(gè)event system。

結(jié)果是我們什么都不用做，UI就被渲染在游戲窗口。Unity替我們考慮到了。Frame debugger顯示UI被獨(dú)立地渲染了，以overlay的方式。

UI被繪制在屏幕空間中。

至少，當(dāng)canvas被設(shè)置渲染在屏幕空間中就是這樣的情況。當(dāng)設(shè)置渲染到世界空間中時(shí)，UI和其他的透明對(duì)象一起被渲染。

UI在世界空間中。

盡管UI在游戲窗口中起作用，但是它在場(chǎng)景窗口中不顯示。在場(chǎng)景窗口中UI總是存在于世界空間，但是我們需要手動(dòng)將它注入場(chǎng)景中。通過調(diào)用靜態(tài)ScriptableRenderContext.EmitWorldGeometruForSceneView方法來添加UI，當(dāng)前的相機(jī)作為一個(gè)參數(shù)。這必須在剔除前調(diào)用。

if (!CullResults.GetCullingParameters(camera, out cullingParameters)) { return; } ScriptableRenderContext.EmitWorldGeometryForSceneView(camera); CullResults.Cull(ref cullingParameters, context, ref cull);

但是它也會(huì)在游戲窗口中再次添加UI。為了避免這種情況，我們只在渲染場(chǎng)景窗口時(shí)發(fā)出UI幾何體。這種情況就是當(dāng)相機(jī)的cameraType等于CameraType.SceneView時(shí)。

if (camera.cameraType == CameraType.SceneView) { ScriptableRenderContext.EmitWorldGeometryForSceneView(camera); }

這僅在編輯器下起作用。條件編譯確保EmitWorldGeometryForSceneView不會(huì)在構(gòu)建編譯期存在，這意味著現(xiàn)在我們嘗試構(gòu)建的話會(huì)得到一個(gè)編譯錯(cuò)誤。為了使它再次起作用，我們必須讓代碼有條件地調(diào)用EmitWorldGeometryForSceneView。把代碼放在#if和#endif語句之間來實(shí)現(xiàn)。#if語句需要一個(gè)符號(hào)，就像Conditional特性。使用UNITY_EDITOER，代碼僅在編輯器的編譯期被包含。

void Render (ScriptableRenderContext context, Camera camera) { ScriptableCullingParameters cullingParameters; if (!CullResults.GetCullingParameters(camera, out cullingParameters)) { return; }#if UNITY_EDITOR if (camera.cameraType == CameraType.SceneView) { ScriptableRenderContext.EmitWorldGeometryForSceneView(camera); }#endif CullResults.Cull(ref cullingParameters, context, ref cull); … }

下個(gè)教程是自定義著色器。

本章教程項(xiàng)目倉庫?(bitbucket.org/catlikecodingunitytutorials/scriptable-render-pipeline-01-custom-pipeline/src/master/)

聲明：發(fā)布此文是出于傳遞更多知識(shí)以供交流學(xué)習(xí)之目的。若有來源標(biāo)注錯(cuò)誤或侵犯了您的合法權(quán)益，請(qǐng)作者持權(quán)屬證明與我們聯(lián)系，我們將及時(shí)更正、刪除，謝謝。

作者：飛鳥

來源：https://zhuanlan.zhihu.com/p/77641752

More：【微信公眾號(hào)】?u3dnotes

總結(jié)

以上是生活随笔為你收集整理的unity hub是什么东西_Unity可编程渲染管线（SRP）教程：一、自定义管线的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。