8321 条评论分享收藏感谢收起17222 条评论分享收藏感谢收起赞同 18810 条评论分享收藏感谢收起后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
Unity中正向渲染和延迟渲染对比
Unity重要特性之一就是可以选择渲染通道。对于那些不熟悉Unity的人来说（通常情况）在正向渲染通道和延迟渲染通道之间做选择就好比在“常”和“奇怪的样子并且感觉像是坏了一样”的渲染方法之间做选择。为了更好的理解为什么会有不止一个渲染通道，首先需要理解他们背后的机制，都是关于灯光照明。
〖 讲解 〗
灯光的开销很大，主要是因为当范围内有灯光时，大量的计算都要被完成以便获取像素点的有效光照颜色。在Unity中灯光可以被逐顶点、逐像素评估，或者作为球函数。这篇文章中我们只讨论前两个。
1.jpg (5.32 KB, 下载次数: 4)
10:28 上传
在逐像素灯光中，每一个像素点颜色都要单独进行计算（例如图中左边）。可以看到在这个案例中即使使用了低模的球体，灯光还是让它看起来是圆的。如果不是边缘的缘故，真的难以看出顶都在哪里。然后，是逐顶点光源。这个需要计算每个顶点的光照。其他位于顶点之间的像素使用常规的颜色混合算法来计算色值（没有进一步的光照计算）。这是光照最廉价的方法，也行，看起来廉价（那么像素光照和顶点光照在哪里转换呢，它隐藏在Light 组件中的Render Mode选项下。Important 选项对应像素光照，Not Important 对应顶点光照，Auto 使最强的光照成为像素光照）。
游戏开发者喜欢逐像素光照胜于逐顶点光照已经不是什么秘密了。然而，这还有一个显著的缺点。每一个光照都会引起范围内对象的额外的渲染通道。限制之一就是四个光照可以影响一个对象。还有一个限制就是阴影——基于Unity文档只有一个光照可以有阴影。（由于某些原因我在.3.4中实现了两个阴影，所以对此并不是很确定。）
〖 措施 〗
用延迟光照来拯救吧：有一个技巧允许将性能保持在合理水平的情况下在场景里尽可能多的使用灯光。它不会限制阴影的数量，如果场景物体在光照范围内也不会造成额外的绘制通道（物体投射阴影是异常的）。这个叫做延迟着色渲染通道。
2.jpg (5.68 KB, 下载次数: 4)
10:28 上传
为什么会如此不同，主要因为多数模型不需要光照计算而被渲染，并且当场景渲染接近完成时光照才被应用去渲染2D图片。这个地方的改变通常被称作在屏幕空间做一些事情。知道这个后，我们可以说光照非延迟渲染呈现在屏幕空间。为了更好的理解它，让我们看一下Frame Debugger。
〖 渲染 〗
场景渲染从渲染所有几何体开始：
3.jpg (4.26 KB, 下载次数: 2)
10:28 上传
这是一个平面图象，那么显卡如何知道怎样去应用光照和阴影？多亏了深度缓存！可以把深度缓存想象成另外一张看不到的图片，并且存储了关于每一个像素点位置距离相机距离的信息。当作为图像呈现出来时，它看起来是这样的：
4.jpg (5.18 KB, 下载次数: 0)
10:28 上传
只有深度信息不足以计算出光照如何应用到表面上。我们至少还需要另外一样东西——方向。3D空间中的定向通常被表示为法线。不寻常的是除了颜色缓存和深度缓存，还有应用到法线的缓存!
5.jpg (4.1 KB, 下载次数: 0)
10:28 上传
如何知道这些是法线？很简单！只需要看一下Scene Gizmo。
6.jpg (10.16 KB, 下载次数: 0)
10:28 上传
看出颜色相似了吗？红色视锥（x）指向左边，所以在之前的图片处理左侧面。绿色（y）是上边，蓝色（z）是右下方（从此透视图来看）。都匹配之前面的颜色。
基于这个信息，光照和阴影就可以被渲染。场景里有多少对象真的不重要。所有事物都在最终的图片中完成。
7.jpg (4.3 KB, 下载次数: 0)
10:28 上传
上图是光照通道倒置版本（1-color）的结果。最后通过混合第一个不透明图片得到了最终结果。看完上边内容你也许对使用新的渲染通道充满了热情，但是不要着急！延迟渲染并不是对所有问题都可以补救。它有一些——
这要是真的就太好了，不是吗？还是有一些局限性。
首先，延迟渲染不允许我们渲染半透明物体。因为如果有一些半透明物体存在于场景，就没有办法记录透过半透明物体可见的物体还有当前物体本身的深度和法线。Unity通过在整个过程的最后使用正向渲染来渲染半透明物体从而处理了这一局限性。这样运行的非常好，这些对象可以投射阴影，不过不幸的是不能接收其他对象的阴影。他们还会引起一些意外的问题，使用正向渲染不知道有没有这些问题。
第二个局限性是缺少反锯齿支持。原因和半透明对象的问题相似，不过unity并不想用什么办法解决这个问题。你可以用屏幕空间的AA算法（图片特效）来替代，不过视觉效果或许并不好看。
另外一个局限性是可以使用四个剔除遮罩。在文档中可以看到：你的剔除层遮罩必须至少包含所有层减掉四个任意层，所以32个层中有28个需要设置。否则将会得到图形构件。最后，没有对Mesh Renderer的ReceiveShadows标签的支持。
〖 需求 〗
这还不够，延迟渲染只能在有限的显卡上工作。对于PC机，可以很安全的假设不超过10年的显卡都可以支持它。对于移动设备来说，就不要假设什么了，不过这并不是什么大的问题，因为——
〖 性能 〗
最重要的是相比正向渲染，延迟渲染大多数情况下在移动设备中性能都会比较差。因为额外的通道需要每一帧都要完成。如果只使用了一个光照，这样做可能会有点儿不值得。
另一方面，添加额外的灯光很廉价，最坏情况下性能将会线性下降，和正向光照对比，这个依赖于场景中物体的数量。
8.jpg (9.4 KB, 下载次数: 0)
10:28 上传
城市：地平线（Unity制作）使用了延迟渲染通道。游戏中有很多的小光源，游戏依然表现的很好。
via：游戏蛮牛
关注我们官方微信公众号
下载我们官方APP-游戏行
关注手游动态微信公众号
百万销量的《空洞骑士》，地图是怎么设计出开发出成功游戏（过程）是世界上最难的工作回顾暴雪起诉刀塔传奇H5游戏渠道运营必读：现状，困境与未来贫穷中透着零基础的单人制作游戏手册之六：小游戏大能量，数据见证100天：2000＋款游
微信扫一扫关注我们→解决Unity引擎后期渲染的性能问题（转）
一问题Unity引擎里对渲染后期处理效果很多，如Bloom、运动模糊、景深等效果。实现过程是在作用的摄像机上加脚本并实现OnRenderImage方法，Graphics.Blit(source, destination, material)；使用材质material的shader处理帧缓存的数据，再拷贝回屏幕帧缓存。使用ImageEffect之后，发现在某些机型上（华为mate7、三星N7100），运行效率极低，明显卡顿。UnityProfiler查看真机渲染情况二调查分析Unity文档并没有相关的详细介绍，实现的细节也不得而知。论坛里Camera.AAResolve解释为与抗锯齿有关系，关闭全屏抗锯齿之后测试，确实不会卡顿了。目前主流移动
GPU 由三家公司生产，英国 Imagination 公司的 SGX 系列，美国高通公司的 Adreno 系列，以及著名显卡芯片商美国 NVIDIA 公司的移动 GeForce 系列。Arm的mali作为非主流，但在市场上有不小的份额，华为Mate7、三星N7100的GPU正是mali系列。使用Mali Graphics Debugger查看渲染如图：在前2个drawcall里都调用了glReadPixels接口在glReadPixels的最后个参数不为空，则表示数据从显存传输到系统内存，从CPU到GPU的逆向传输，这是非常缓慢的过程，并且是阻塞模式。看看其它机型渲染情况，下面是高通的gpu，使用adrenoprofiler查看。它并没有调用glReadPixels，而是使用了glBindFramebuffer。FBO(Frame
buffer object)在使用前需要绑定，void glBindFramebuffer(GLenum target, GLuint id)；第一个参数是指定绑定操作，读、写或可读可写。第二个参数指定绑定的对象，如果是0，则是默认的帧缓存对象。这是使用了改变渲染目标缓存的方法。由此可知不同硬件上处理的方式不一样，具体是因为Unity内部实现的原因或是硬件支持不够。查看opengl版本的版本历史和发展最大变化的版本是OPENGL3.0。其中正式把帧缓冲对象（framebuffer
object）划入core profile；帧缓冲对象之间可以互相拷贝像素到持有的不同的render target，是性能上的提升。在FBO中使用多重采样抗锯齿，在3.0版本才加入的特性，若渲染接口不支持，则用了比较低级的API来完成获取屏幕缓存数据，导致了卡顿。我们项目使用的是OPENGL2.0，而mali系列并没有很好的支持OPENGL2.0的接口。用OPENGL3.0导出apk运行在华为mate7(mali系列)上，是没问题的。同样使用了改变渲染目标缓存的方法，因为3.0版本的FBO支持多采样。三问题结论OPENGL2.0，ImageEffect屏幕后期处理时，改变渲染目标缓存，绑定FBO，若不在ProjectSettings里设置全屏抗锯齿是没问题的。若设置了全屏抗锯齿，不同硬件对不同版本OPENGL的支持不定。四解决方案1、关闭抗锯齿。2、提升OPENGL版本到3.0。3、不使用unity的OnRenderImage方法，直接使用渲染到纹理的方法。第一种方案效果有损失，不可取；第二种可行，但版本的提升可能会有些不可预估的问题，3.0版本也弃用了很多的特性；第三种最可行，渲染到纹理的方法在绝多数机型都支持。实现方法如下：1、摄像机上挂接一个脚本2、Start方法，temp = RenderTexture.GetTemporary获取渲染纹理3、Update方法，设置Camera.targetTexture =4、OnPostRender方法，设置Camera.targetTexture =Graphics.Blit(temp, null, material);运行结果：此证明我的mate7还是可以的，哈哈。
没有更多推荐了，[蛮牛译馆] Unity中正向渲染和延迟渲染对比
Unity重要特性之一就是可以选择渲染通道。对于那些不熟悉Unity的人来说（通常情况）在正向渲染通道和延迟渲染通道之间做选择就好比在“常”和“奇怪的样子并且感觉像是坏了一样”的渲染方法之间做选择。为了更好的理解为什么会有不止一个渲染通道，首先需要理解他们背后的机制，都是关于灯光照明。
〖 讲解 〗
灯光的开销很大，主要是因为当范围内有灯光时，大量的计算都要被完成以便获取像素点的有效光照颜色。在Unity中灯光可以被逐顶点、逐像素评估，或者作为球函数。这篇文章中我们只讨论前两个。
在逐像素灯光中，每一个像素点颜色都要单独进行计算（例如图中左边）。可以看到在这个案例中即使使用了低模的球体，灯光还是让它看起来是圆的。如果不是边缘的缘故，真的难以看出顶都在哪里。然后，是逐顶点光源。这个需要计算每个顶点的光照。其他位于顶点之间的像素使用常规的颜色混合算法来计算色值（没有进一步的光照计算）。这是光照最廉价的方法，也行，看起来廉价（那么像素光照和顶点光照在哪里转换呢，它隐藏在Light 组件中的Render Mode选项下。Important 选项对应像素光照，Not Important 对应顶点光照，Auto 使最强的光照成为像素光照）。
游戏开发者喜欢逐像素光照胜于逐顶点光照已经不是什么秘密了。然而，这还有一个显著的缺点。每一个光照都会引起范围内对象的额外的渲染通道。限制之一就是四个光照可以影响一个对象。还有一个限制就是阴影——基于Unity文档只有一个光照可以有阴影。（由于某些原因我在.3.4中实现了两个阴影，所以对此并不是很确定。）
〖 措施 〗
用延迟光照来拯救吧：有一个技巧允许将性能保持在合理水平的情况下在场景里尽可能多的使用灯光。它不会限制阴影的数量，如果场景物体在光照范围内也不会造成额外的绘制通道（物体投射阴影是异常的）。这个叫做延迟着色渲染通道。
为什么会如此不同，主要因为多数模型不需要光照计算而被渲染，并且当场景渲染接近完成时光照才被应用去渲染2D图片。这个地方的改变通常被称作在屏幕空间做一些事情。知道这个后，我们可以说光照非延迟渲染呈现在屏幕空间。为了更好的理解它，让我们看一下Frame Debugger。
〖 渲染 〗
场景渲染从渲染所有几何体开始：
这是一个平面图象，那么显卡如何知道怎样去应用光照和阴影？多亏了深度缓存！可以把深度缓存想象成另外一张看不到的图片，并且存储了关于每一个像素点位置距离相机距离的信息。当作为图像呈现出来时，它看起来是这样的：
只有深度信息不足以计算出光照如何应用到表面上。我们至少还需要另外一样东西——方向。3D空间中的定向通常被表示为法线。不寻常的是除了颜色缓存和深度缓存，还有应用到法线的缓存!
如何知道这些是法线？很简单！只需要看一下Scene Gizmo。
看出颜色相似了吗？红色视锥（x）指向左边，所以在之前的图片处理左侧面。绿色（y）是上边，蓝色（z）是右下方（从此透视图来看）。都匹配之前面的颜色。
基于这个信息，光照和阴影就可以被渲染。场景里有多少对象真的不重要。所有事物都在最终的图片中完成。
上图是光照通道倒置版本（1-color）的结果。最后通过混合第一个不透明图片得到了最终结果。看完上边内容你也许对使用新的渲染通道充满了热情，但是不要着急！延迟渲染并不是对所有问题都可以补救。它有一些——
这要是真的就太好了，不是吗？还是有一些局限性。
首先，延迟渲染不允许我们渲染半透明物体。因为如果有一些半透明物体存在于场景，就没有办法记录透过半透明物体可见的物体还有当前物体本身的深度和法线。Unity通过在整个过程的最后使用正向渲染来渲染半透明物体从而处理了这一局限性。这样运行的非常好，这些对象可以投射阴影，不过不幸的是不能接收其他对象的阴影。他们还会引起一些意外的问题，使用正向渲染不知道有没有这些问题。
第二个局限性是缺少反锯齿支持。原因和半透明对象的问题相似，不过unity并不想用什么办法解决这个问题。你可以用屏幕空间的AA算法（图片特效）来替代，不过视觉效果或许并不好看。
另外一个局限性是可以使用四个剔除遮罩。在文档中可以看到：你的剔除层遮罩必须至少包含所有层减掉四个任意层，所以32个层中有28个需要设置。否则将会得到图形构件。最后，没有对Mesh Renderer的ReceiveShadows标签的支持。
〖 需求 〗
这还不够，延迟渲染只能在有限的显卡上工作。对于PC机，可以很安全的假设不超过10年的显卡都可以支持它。对于移动设备来说，就不要假设什么了，不过这并不是什么大的问题，因为——
〖 性能 〗
最重要的是相比正向渲染，延迟渲染大多数情况下在移动设备中性能都会比较差。因为额外的通道需要每一帧都要完成。如果只使用了一个光照，这样做可能会有点儿不值得。
另一方面，添加额外的灯光很廉价，最坏情况下性能将会线性下降，和正向光照对比，这个依赖于场景中物体的数量。
城市：地平线（Unity制作）使用了延迟渲染通道。游戏中有很多的小光源，游戏依然表现的很好。
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点