開發自定義ScriptableRenderPipeline，將DrawCall降低180倍

0x00 前言

大家都知道，Unity在2018版本中正式推出了Scriptable Render Pipeline。我們既可以通過Package Manager下載使用Unity預先創建好的LightWeight Render Pipeline和High Defination Render Pipeline，也可以自己動手創建自定義的Render Pipeline，實現一些符合自己心意的渲染策略。

下面我們先簡單介紹一下自定義SRP的使用方法，之後利用自定義的Render Pipeline來優化一個常見的情景，即渲染半透時由於渲染順序被打亂，從而導致的合批失敗。

0x01 一個簡單的SRP流水線實現

如何自定義一個Scriptable Render Pipeline，Unity有一篇博客[1]已經做了簡單的介紹。
根據這篇博客，我們知道，首先要定義一個繼承自UnityEngine.Experimental.Rendering.RenderPipeline的類，並且覆寫其中的Render方法，在該方法中實現自己的渲染邏輯。

//定義渲染管線邏輯
using UnityEngine;
using UnityEngine.Rendering;
using UnityEngine.Experimental.Rendering;

public class BasicPipeInstance : RenderPipeline
{
    private Color m_ClearColor = Color.black;

    public BasicPipeInstance(Color clearColor)
    {
        m_ClearColor = clearColor;
    }

    public override void Render(ScriptableRenderContext context, Camera[] cameras)
    {
        // does not so much yet :()
        base.Render(context, cameras);

        // clear buffers to the configured color
        var cmd = new CommandBuffer();
        cmd.ClearRenderTarget(true, true, m_ClearColor);
        context.ExecuteCommandBuffer(cmd);
        cmd.Release();
        context.Submit();
    }
}

這個腳本的邏輯十分簡單，即使用純色來清屏。ScriptableRenderContext 類的實例context即當前的渲染上下文，保存了當前的渲染狀態。
有了渲染管線的邏輯，之後我們要做的就是調用AssetDatabase.CreateAsset將這個渲染管線保存爲一個Asset，儲存在硬盤上，並將這個Asset賦值給Graphics Setting以激活該管線。

所以，我們接下來就需要一個能夠被Unity創建出Asset並被序列化保存的類，在SRP中這個類叫做RenderPipelineAsset。

[ExecuteInEditMode]
//定義渲染管線Asset
public class BasicAssetPipe : RenderPipelineAsset
{
    public Color clearColor = Color.blue;

    protected override IRenderPipeline InternalCreatePipeline()
    {
        return new BasicPipeInstance(clearColor);
    }
}

這樣，我們就能很方便的創建出一個渲染管線的Asset，和傳統的Scriptable Object一樣，我們可以直接通過Asset來修改其字段的內容，這裏我們只定義了一個名字是clearColor的字段。

當然，我們可以創建完Asset之後，再手動給Graphics Setting賦值，也可以直接在腳本中給Graphics Setting賦值，只需要訪問GraphicsSettings.renderPipelineAsset即可。

using UnityEngine;
using UnityEditor;
using UnityEngine.Rendering;
public class MySRPCreate
{
    [MenuItem("Assets/Create/MySRP")]
    public static void CreateSRP()
    {
        var instance = ScriptableObject.CreateInstance<BasicAssetPipe>();
        AssetDatabase.CreateAsset(instance, "Assets/MyScriptableRenderPipeline.asset");
        GraphicsSettings.renderPipelineAsset = instance;
    }
}

ok，打開相關的菜單，點擊按鈕，整個Unity的傳統渲染管線就被替換成了我們剛剛自定義的渲染管線——簡單的說，就是一個純色清屏。

0x02 自定義管線，讓DC從3700到20

OK，接下來我們來看一個有趣的場景。這個場景中，我們通過腳本來生成2種角色，每一種角色的數量有1500名——需要渲染的當然還包括她們的影子。爲了儘量減少DrawCall的數量，自然會想到開啓GPU Instance。

這個是Unity的默認渲染管線的渲染成果，可是打開Frame Debugger我們可以發現渲染的成本高的嚇人，DrawCall數量達到了3700次左右——在打開了GPU Instance的情況下。

查看一下某次DrawCall的GPU Instance失敗原因，是由於"Objects have different materials"。而查看相關的DrawCall數據，可以發現2種角色和陰影出現了交替渲染的情況，這樣便導致了materials 不同造成的GPU Instance失敗。

所以接下來我們要做的事情，就是能否自己來對這個場景內的對象進行渲染排序，因爲我們希望的是角色和陰影的渲染不要交替出現，所以理想狀態是先把所有的角色面片渲染出來，接下來再來渲染陰影。

在自定義渲染流水線中實際調用繪製指令時，我們還會遇到一些別的類型和方法。例如，我們需要先對場景進行裁剪，選出需要被渲染的對象。
在這裏我們會遇到CullResults結構體，以及ScriptableCullingParameters結構體。通過這兩個結構體以及它們所定義的方法，我們可以獲取經過裁剪之後需要被渲染的對象以及燈光數據——分別保存在CullResults的visibleLights字段以及visibleRenderers字段中。
獲取了visibleLights也就是光照信息之後，我們就可以爲我們的管線設置光照數據了。

例如，我們把方向光的顏色傳入到shader的LightColor0變量中，把方向光的方向傳入到shader的WorldSpaceLightPos0變量中。

    foreach( var visibleLight in visibleLights)
    {
        if (visibleLight.lightType == LightType.Directional)
        {
            Vector4 dir = -visibleLight.localToWorld.GetColumn(2) ;
            Shader.SetGlobalVector(ShaderNameHash.LightColor0, visibleLight.finalColor);
            Shader.SetGlobalVector(ShaderNameHash.WorldSpaceLightPos0, new Vector4(dir.x,dir.y,dir.z,0.0f) );
            break;
        }
    }

而visibleRenderers中保存的則是需要被渲染的對象。涉及到對象的渲染，我們顯然需要確定一些渲染設置，在自定義管線中保存這些設置的是DrawRendererSettings結構體。

一些常見的渲染設置，例如最常見的便是設置所使用的shader——更具體的說是使用的pass，這裏Unity也對Shader的pass名字做了一個簡單封裝，即ShaderPassName結構體，它用來指定我們所使用的shader pass，正確設置後，Unity會在Renderer所使用的shader中尋找指定的pass。

除此之外，如果需要被渲染的對象不是一個，那麼顯然會涉及到一個排序的問題。同樣我們也可以設置DrawRendererSettings結構體的sorting.flags來確定排序規則。可以設置的排序規則，可以查看這個文檔：
https://docs.unity3d.com/ScriptReference/Experimental.Rendering.SortFlags.html
其中有一個叫做SortFlags.OptimizeStateChanges的規則，看上去這個很適合我們的需求，因爲它的技能描述是：

Sort objects to reduce draw state changes.

此時visibleRenderers中包括的待渲染對象不僅有角色、還包括四周的牆體、以及角色腳下的陰影面片，所以爲了達到先把所有的角色面片渲染出來，接下來再來渲染陰影的目的——也就是說爲了規避所謂的穿插問題——我們接下來先把需要渲染的角色過濾出來。此時我們需要另一個結構體來實現過濾的需求——FilterRenderersSettings。FilterRenderersSettings可以按照待渲染對象所在的RenderQueue和layer來篩選真正需要被渲染的對象。

可以看到，角色的渲染隊列設置的3000，也就是transparent。所以我們可以用RenderQueue來進行一次篩選，再使用layer篩選出角色——角色所在的layer叫做Chara。

Ok，到這裏，我們就篩選出了需要被渲染的角色，並且設置好了角色的渲染狀態。最後，我們直接調用Draw指令，並把這些設置作爲參數傳入Draw即可。
把以上的邏輯封裝爲一個方法，在Render中調用該方法就可以渲染出所有的角色了。

private void DrawCharacter(ScriptableRenderContext context, Camera camera, ShaderPassName pass,SortFlags sortFlags)
{
    var settings = new DrawRendererSettings(camera, pass);
    settings.sorting.flags = sortFlags;

    var filterSettings = new FilterRenderersSettings(true)
    {
        renderQueueRange = RenderQueueRange.transparent,
        layerMask = 1 << LayerDefine.CHARA
    };
    context.DrawRenderers(cull.visibleRenderers, ref settings, filterSettings);
}

這樣，我們就渲染出了3000多個角色——在只用了8個DrawCall的情況下。

第一個小目標達成。

背景牆體，和陰影其實也大同小異，因爲我們已經對可能產生穿插渲染的對象做出了區分，先全部渲染角色，再渲染陰影。重點在於分組渲染。渲染牆體、陰影面片的代碼要做的也便是將牆體、陰影對象過濾出來，進行單獨渲染。

private void DrawBg(ScriptableRenderContext context, Camera camera)
{
    var settings = new DrawRendererSettings(camera, basicPass);
    settings.sorting.flags = SortFlags.CommonOpaque;

    var filterSettings = new FilterRenderersSettings(true)
    {
        renderQueueRange = RenderQueueRange.opaque,
        layerMask = 1 << LayerDefine.BG
    };
    context.DrawRenderers(cull.visibleRenderers, ref settings, filterSettings);
}

private void DrawShadow(ScriptableRenderContext context, Camera camera)
{
    var settings = new DrawRendererSettings(camera, basicPass);
    settings.sorting.flags = SortFlags.CommonTransparent;

    var filterSettings = new FilterRenderersSettings(true)
    {
        renderQueueRange = RenderQueueRange.transparent,
        layerMask = 1 << LayerDefine.SHADOW
    };
    context.DrawRenderers(cull.visibleRenderers, ref settings, filterSettings);
}

之後，我們只需要再在Render方法中依次調用DrawBg和DrawShadow即可。

public override void Render(ScriptableRenderContext context, Camera[] cameras)
{
    base.Render(context, cameras);
    if (cmd == null)
    {
        cmd = new CommandBuffer();
    }
    foreach (var camera in cameras)
    {
        if (!CullResults.GetCullingParameters(camera, out cullingParams))
            continue;
        CullResults.Cull(ref cullingParams, context,ref cull);

        context.SetupCameraProperties(camera);

        cmd.Clear();
        cmd.ClearRenderTarget(true, true, Color.black,1.0f);
        context.ExecuteCommandBuffer(cmd);

        SetUpDirectionalLightParam(cull.visibleLights);

        //Draw
        DrawCharacter(context, camera, zPrepass, SortFlags.OptimizeStateChanges);
        DrawBg(context, camera);
        DrawShadow(context, camera);


        context.Submit();
    }
}

渲染的結果便是：

角色、背景、陰影分別渲染，互不干擾，而DrawCall也從Unity默認的管線中的3700次降低到了使用我們自定義管線的20次。

0x03 小結

利用SRP，我們可以根據項目自身的特點來定製很多有趣的內容，從這個小的演示中我們應該可以體驗到這種靈活性所帶來的性能上的提升。

好了，如果有技術討論的需求，歡迎加羣：
Unity官方中文社區羣：470161914
Unity官方中文社區②羣：629212643

Ref

[1]https://blogs.unity3d.com/cn/2018/01/31/srp-overview/
[2]https://github.com/wotakuro/CustomScriptRenderPipelineTest