可编程渲染管线(SRP)已经支持很久了，但项目里用到的还是很少。此前项目优化时都是较多的使用CommandBuffer绘制。其实CommandBuffer也算是可编程管线里的内容，只是CommandBuffer的粒度很粗，而URP(LWRP)则粒度细化到了方便控制整个渲染管线。

开始升级一个已有的工程：

1，清理干净工程；

2，安装Universal RP: Window -> Unity Packages: 找到并安装 Universal RP和URP Core;

3，新建一个管线配置：

4，把新建的管线配置托到Project Setting -> Graphics的Scriptable Render Pipleline Setting;

5，然后可以看到很多Shader报错，主要分为两类：

1)ASE Shader报错： failed to open source file: 'Packages/com.unity.render-pipelines.lightweight/ShaderLibrary/Core.hlsl' ...

2)其他shader都是手写的，也是粉色的了

修复错误：

1，开始我强制设置Shader Include Path还是报错；

3，安装了最新的unity2020.2.0f1版本，重新打开URP Demo不再报错；

4，使用unity2020.2.0f1打开自己的工程，很多报错。原因是我之前把UniversalRender RP

拷贝一份在Asset下。删除后备份，而且把Library\PackageCache也一并删除。

5，升级Shader，就没有报错了。shader还是粉色的。

1)需要将CG字样修改为HLSL。 将CGPROGRAM-ENDCG 修改为 HLSLPROGRAM - ENDHLSL; 将CGINCLUDE-ENDCG修改为HLSLINCLUDE - ENDHLSL；

最终放弃修改自定义PBR渲染，我的PBR渲染和Unity Standard Buildin流程嵌入太多。在URP中lit(PBR-M/R)把整个流程重写了一边，核心的光照处理，以及光照衰减，和BRDF实现都优化了。升级改动基本就是重新写一套了，我原先的PBR走的还是unity的PBR框架，改进的是BRDF(Hair-kajiayaKay,DissneyPBR,Skin-SSS)，以及去掉了宏编译开关，将多光源在同个pass计算。综合考虑下来还是放弃原先Unity PBR各种实现，转而重新改URP版本PBR嵌入自己的流程。

URP 特性梳理：

0，URP管线流程：

ForwardRenderData -> UniversalRenderPipelineAsset -> UniversalRenderPipeline -> Render

ForwardRendererData：设置后处理资源(shader,texture资源索引)，以及RenderFeature配置；

UniversalRenderPipelineAsset：配置ForwardRendererData UniversalRenderPipeline工作的一系列配置

UniversalRenderPipeline：使用UniversalRenderPipelineAsset初始化管线；

Render开始渲染：

1)每帧设置shader全局常量；

2)按照Priority渲染每个相机；先渲染base camera，再依次渲染camera stack；

初始化相机数据，这里URP写了两个API：InitializeStackedCameraData和InitializeAdditionalCameraData，这么做是因为Camera还是以前我们熟悉的BuildinRendererPipleLine里的camera,URP额外的数据走的是UniversalAdditionalCameraData处理的；所以初始化时需要把这两部分数据合并起来。最后按照顺序调用RenderSingleCamera渲染每个相机；

3)RenderSingleCamera：裁剪；设置渲染数据(光照；阴影；后处理)；提交渲染；

UniversalRenderPipelineCore里主要是一些核心的数据结构，和一系列对核心数据结构的处理函数。

1，光照实现：

URP中灯光的实现(ForwardLights)，AOI计算动态光源，并且保证同屏生效的光源数量限制，这个AdditionalLight 数量是自己控制的。

在传入GPU中时，urp对不同硬件做了不同兼容。

1)当前非手机平台走structured buffer：存储在_AdditionalLightsBuffer，相当于把一个light的position,color,attenuation,spotDirection信息存储在一个struct里。

其他平台lights的position,color,attenuation,spotDirection存储在_AdditionalLightsPosition，_AdditionalLightsColor，_AdditionalLightsAttenuation，_AdditionalLightsSpotDir；

2)mobile：gles2.0 光源数量限制：除了主光源外，最多额外支持4栈存储

3)mobile：非gles2.0 光源数量限制：除了主光源外，最多额外支持8栈存储

URP MainLight：如果没有设置sun light，URP会采用强度最大的方向光来当作主光源；详见UniversalRenderPipleline:GetMainLightIndex

此外MainLight和BuildinPipleline在shader中的相关变量也不一样：

URP：_MainLightPosition.xyz; _MainLightColor.rgb;

BuildinRendererPipeline:_WorldSpaceLightPos0.xyz;_LightColor0.rgb;

阴影部分：主光源生成阴影，额外的光源里只有聚光灯生成阴影(这个具体原因暂时还未深挖)。

2，Pass实现

起初我并没有理解到URP关于自定义的ScriptableRendererFeature和ScriptableRendererPass的精髓所在。对CommandBuffer比较熟悉，此前CommandBuffer操作后处理一般都是需要把Camera的colorBuffer或者DepthBuffer拷贝回来，然后在用CommandBuffer进行Blit操作，最后再Blit回FrameBuffer。或者直接使用CommandBuffer drawMesh或者DrawMeshInstance。

简单看了下ScriptableRendererPass的绘制还是使用了CommandBuffer，于是就纳闷这个ScriptRendererPass的高效率来自于哪里？于是我周一【20201228】细看了，发现原来CommandBuffer并不是直接操作RenderTexture了，而是操作RenderTargetHandle，RenderTargetHandle是类似shader propertry ID一样。这样CommandBuffer操作的只是id，并不需要gpu回传后处理的纹理等信息，因此提升了效率。

3，Camera stack实现：URP的开始的版本不支持Camera Stack，不太清楚从哪个版本开始起支持了。

URP的Camera和以前BuitinRendererPipeline的Camera还是同一个，差异在于URP的额外强制绑定了UniversalAdditionalCameraData用于记录camera的一些配置，比如camera stack references 和一些区别于RenderPipelineAsset的全局设置。

base camera 排序按照Priority排序，和以前的Depth含义一样；但是如果是overlay camera，则没有Priority属性，overlay camera的渲染顺序是按照先渲染其挂载的base camera，再依次渲染挂载在camera stack上的相机；

4，SRP Batch：结合使用constant buffer使用，类似在gpu中对使用同个shader的物件进行for循环处理。原先的内置渲染管线可以使用CommandDrawMeshInstanced绘制同个mesh同个材质，并使用gpu instance来优化

总结：

URP新管线实现和BuildinRendererPipleline两者是完全不一样的实现，不能兼容。项目开始制定了采用哪种渲染管线，后续改动可能会很痛苦。从URP改回BuildinRendererPipeline可能还好点。从BuildinRendererPipeline改到URP可能就更痛苦了，项目中期在抽调人去处理这块的东西可能又导致其他开发进度滞后，而招人未必就能立马找到合适的。所以项目立项之初就要考虑使用哪种管线。

建议制作对性能要求比较高得项目尽可能采用URP，比如跑图类RPG游戏，大规模3d单位战斗的SLG，赛车竞速类的，开放世界类的，以及一些对后处理要求较高的游戏。其他则采用URP和BuildinRendererPipeline都可以，看个人意愿。

抛砖引玉，欢迎拍砖交流。