为什么感觉Unity的技美们花很多时间纠结于管线自定义和使用"适合"的管线？
为什么感觉Unity的技美们花很多时间纠结于管线自定义和使用"适合"的管线？ 因为这块Unity就是完爆UE，看了一堆回答是真看不下去。要是说比资源加载，比多线程，比内置管线，你骂Unity，那我绝对跟你一起骂，甚至长篇大论的骂（最近刚骂完），但是要是有事没事往渲染管线上开团，这个可就得理论理论了。在渲染管线这方面，Scriptable Rendering Pipeline在设计思想上秒杀UE的老管线50条街，以至于上层脚本开发者连源码都不需要就能让渲染效率秒掉UE，而UE还在一边Compiling。就拿不透明物体的渲染阶段说一下，截止到本人目前电脑上使用的UE4.23，GBuffer的分布：
Memo of GBuffer
GBufferA : Normal(rgb), PerObjectGBufferData(a)
GBufferB : Metallic(r), Specular(g), Roughness(b), ShadingModelID(a&0xF),
SelectiveOutputMask(a&0xF0)
GBufferC : BaseColor(rgb), IndirectIrradiance(a)
GBufferD : CustomData(rgba)
GBufferE : PrecomputedShadowFactors(rgba)
SceneDepth
CustomNativeDepth : depth
CustomStencilTexture
GBufferVelocity : rg(16 bit)
Emissive: rgba (hdr)
Dbuffer
DBufferA : PreMultColor(rgb), ColorOpacity(a)
DBufferB : PreMulWorldNormal(rgb), NormalOpacity(a)
DBufferC : PreMulRoughness(r ), RoughnessOpacity(g)
这么一堆东西，加入没有特殊需求，不使用Custom GBuffer，就纯粹的做写实画风渲染，带宽消耗大致为：
GBufferA(4 byte)
GBufferB(4 byte)
GBufferC(4 byte)
GBufferE(4 byte)
SceneDepth(4 byte)
GBuffer Velocity(4 byte)
Emissive (8 byte)
DBufferA: (4 byte)
DBufferB: (4 byte)
DBufferC: (2 byte)
这一套下来，每个像素的带宽占用是：42 bytes
我们尝试用SRP优化成Tile Base/Cluster Base Forward+管线，同时还要保证UE现有的保证效果的后处理（如AO，SSR，SSGI等）必须用到的GBuffer信息，那么以上的信息有这些可以缩减：
GBufferB.a: 直接光的着色发生在Base pass中，不需要输出材质信息
GBufferC.a：同上
GBufferE: 同上
DBufferABC: 通过Cluster Culling或Tile Culling，将Decal信息提前输出到屏幕位置，在Base pass完成计算，不需要输出。
其他部分是后期管线必需的信息，不可省略，各自少一个通道的GBufferB和GBufferC可以组成一个4通道和一个2通道的RT。
这样，就可以在带宽占用上，让每个像素少了16 bytes，如果渲染规格是2560 * 1440分辨率，如果目标渲染帧数是60FPS，那么每秒带宽将会节约：3.296G，目标渲染帧数是144FPS，那么每秒带宽将会节约：7.910G，大家可以对比一下自己显卡的IO数据，感受一下这个提升是多么显著。
免喷声明：
虽然Unreal Engine官方团队一直在积极开源并解决用户的问题，关于这些管线的问题本人也和Unreal官方的大佬友好交流过，但是遗憾的是似乎国内开源(tuan)社区的风气并没有那么好，各种饭圈操作频出，起码本人经常受到一些无端而可笑的攻击，这里直接把几个经常遇到的提问给答了：
问：你说的这么轻巧，有用SRP写过这套实现吗？
答：有，在专栏里。
问：这套方案是你脑补的还是有项目验证的？
答：可以关注历年Siggraph和GDC的分享，感觉大厂讲解人为了宣传嘴皮子都磨破了。既然有分享说明已经是面向市场的成功的大型项目，并不是只有某些人认为的手里的要让市面上Top200手机都跑得起来的“项目”才叫项目。
问：改不动UE源码就是你菜，就是你C++水平差，就是你不会写Graphics API。
答：您确定您不是在往铁板上踢？？
问：答主有没有项目经验？
答：本人是已经参加工作的开发者，正在正面参与大型游戏的开发。 你的想法没错，技美确实应该把更多的时间放在美术工作流，固有功能应用，性能优化等方面，把大部分时间都放在渲染管线上的人员更应该被称作图形程序员 这是中国游戏行业的特殊性，在这种语境下TA几乎等同于图形程序，大部分TA缺乏必要的审美修养和美术技能。
另外unity对图形API的封装足够（过于）抽象，没有太多底层编程基础的TA也可以参与到管线的开发 因为UE4底层和内置渲染足够强大，强大到做项目只需要做减法或者在其渲染基础上进行定制化修改。
Unity的强项在于精简，以前是，现在还是。但游戏环境已经发生了改变。
这是我之前的一次分享中，阐述的一个观点。
“UE4内置完善的各种渲染管线(经典、PBR、半透、剪切、3S、各向异性……)，各种常见材质实例(玻璃、清漆、塑料……)，完善的后处理(泛光、景深、光晕、SSAO、SSR……)，各种环境效果(大气、体积雾，体积云、粒子光照……)……，而且这些打开UE4就有，你要做的就是选择你需要的，关闭你不需要的。把需要的做一下优化、精简。就算什么都不做，打开引擎，随便拖个模型进去，默认材质一丢，都很高大上。Unity呢？一开始，只有很简单的效果，很简单的光照。无光照材质还能用用，随便一个光照材质，性能就堪忧。没有效果很好的复杂材质，也没有很棒的默认环境效果，甚至连个像样的后处理都没有。所以这就导致了两个结果：
1、很多年以前，对画面要求不高的年代，Unity以其精简的规模，获得了青睐(UE瘦身，工作量和难度都太大)。
2、最近开始，对画面要求越来越高，PBR标准开始逐渐成为主流的年代，UE以其内置效果的全面而获得了青睐(Unity全都要自己想办法实现，工作量和难度都太大)。”
所以，为什么？当然是因为Unity精简到用它自己的东西根本做不出个像样的游戏。给你举个简单的例子：
做水的边缘透明过渡，你需要获取水面深度和背景深度差吧？UE4多简单，材质编辑器里俩节点一拖，一减，OK了。
Unity里面呢？先不说到最近才有的shadergraph那个东西，以前连个材质编辑器都没有。这些数据哪儿来？就算你拿到了，你可知到，用unity的默认渲染管线，获取深度这个操作有多耗？性能不行咋办？要么自己想其他办法获取，要么改他的渲染管线。
不是Unity技美"想"，而是"不得不"。 Unity现在处在的阶段是SRP出来一段时间，可以选择URP、HDRP和Built-in三个管线。Built-in管线，预计未来就不维护了，URP最近这段时间感觉有点感觉了，HDRP做手机游戏暂时还不靠谱。
直接使用URP，感觉又不够屌，咋办？要不从HDRP中挪点东西过来？
所以，Unity的技术美术会有这种纠结。
其实，对于UE也有这样的纠结，只是不在技美这块。如果使用UE开发游戏，不改改UE源码显得自己都不够牛！当然，对于技美来说，可能真的改不动，所以，这个事就交给引擎组干了。Unity吗，相对还简单，技美觉得我也可以啊，所以，就都试着改改呗。
另外一个就是，unity确实没有UE那么强大，一些好的效果想实现出来，还是会比较耗的。那效果是上去了，但是，游戏跑不起来了。技美也好，图形也好，肯定要解决性能问题啊，所以，就又回到了题主的问题。 1 Unity在2017为了缓解庞大的用户需求和乏力的渲染标准化建设，想出了自定义渲染管线作为业务层解决方案的功能。说白了就是官方推荐你不仅仅只是编写着色器，还可以在定义渲染管线上玩花活。所以，怎么在Unity里用管线和怎么在Unreal里用尼尔加拉，工作性质有部分类似。
2 Unreal凭借蓝图和大规模业务模块系统化，让很多程序工作看似可以让“Artist“用引擎功能和蓝图完成。相对的，Unity的业务模块系统化也是处处离不开C#脚本扩展。这种设计区别，使得在两个引擎做同样的职能分工，有一种Unreal在做功能研究而Unity在写代码的感觉（哪边的抽象维度更高再议）。
3 国内近6年的Unity项目环境，完成了手游向次世代pbr的跃迁，渲染工作成为一门显学，大面积所谓的TA都是由学习色器代码入手，偏向于渲染工作。再之前的业内图形程序，借由这个东风，完成了TA的职业定义。鹅猪米等厂的“技美”在自定义管线上完成了很多业务落地，风高声远，一时无两，加上Unity后续功能多也绑定可编程管线，总是会碰到的。
4 字面上狭义的TA，要么成为创造内容的美术和工程内容的程序之间的胶水，要么兼而有之，本来也是一个模糊的定义。国内有DCC工具开发，引擎工具开发，美术资源制作处理使用预研之类的工作，或者叫工具组，也有叫TA组的。并不是只有图形引擎程序才会叫TA，很多做渲染的也不一定碰过管线，只是在大环境下，显得比较落寞。
目前国内游戏项目以手机为主。
那么在性能和效果之间，有巨大的优化余地。不光是在管线上。
事实上，如果你打算用ue4按照现在一线手游的标准做项目的话。肯定也是要 改＋自己做很多东西的。 因为Unity build in 管线极其简陋啊，这是为了兼容尽可能多的设备以及支持尽可能多的特性，你不改改的话，用起来贼难受。也得益于他本身简单，并且现在有了SRP，改起来也挺方便。虽然也就改改command buffer而已，渲染的真正逻辑，你还是碰不到，毕竟没有C++层的代码。不过作为一个小公司的小TA，能改改这些就不错。再深入的，我没能力改，也不敢改，即便又有能力也敢改，公司也不敢用啊，万一后面有坑呢？
看到很多回答都在比较UE，UE确实强，但是这个强是指他的效率和效果好，并不是指完美。代价就是你只能在他的框架内实现效果，一旦要脱离他的框架的话，就得改源码。这是很多人诟病的地方。人们总想要设备兼容性好，框架还要简单，方便扩展，能支持的特性多，最后效率还要好，但是世上没有完美的引擎啊！要真的有这种引擎，UE和Unity就可以死了，绝大多数的TA也跟着失业。所以Unity和UE不过是个选择的问题，不存在对错。 因为UE4的技美没得选。