您当前在： >
开发者教程：如何使用虚拟引擎4进行渲染的流程分析
UE4作为当今商业界的大佬，渲染和图形质量一直是首屈一指的水准，但是相对于unity来说UE4基本上是一套完整方案提供，不通过源码修改对渲染进行定制的可能性比较小，而且同时UE4这方面的文档很少，因此这篇文章就是想通过分析UE4的渲染过程，来给大家针对自己使用ue4开发的游戏的内容特点做出优化带来启发。
我们使用Renderdoc对UE4(，DX11)截帧，UE4的版本为4.18. 可以看到UE4一帧画面的渲染过程如下
可以看到的是整个渲染流程还是很清晰明了的，接下来就会逐步分析每个过程。
1.Z-Prepass
UE4在deferred shading 过程之前这个，会有一系列的culling过程剔除掉不需要的像素或者几何体，基本上可以猜测是UE4是为了减轻后期在deferred shadinggbuffer 生成中的庞大计算量，第一遍的zpass会先渲染一遍场景中的几何，用于生产SceneDepthZ以及HZB buffer，格式为R24G8TYPELESS
2.Compute light grid
在Pre-Z之后UE4会把场景中的灯光按照屏幕空间分成相应的grid，类似于cluster shading的方法，注意这里的grid只考虑点光源，聚光灯，以及reflection captures，UE4这一步是通过compute shader实现的，所以只在sm&5.0的平台上有。具体shader代码在LightGridInjection.usf，阅读代码之后我们可以发现 UE4的灯光空间grid的划分是按照指数增长的。也就是每个grid的z随着距离会增长。
在真正计算光照时，我们可以用GridIndex来快速决定某点是否受到灯光影响。Lightculling的方法在forward下对于提高灯光的渲染效率是十分有用的，但UE4在DS下仍然保有了这一个过程。其效果存疑，初步推测是为了和UE4新加的Forward renderer统一。
3.Occlusion query
这一步在light culling之后，和Pre-Z pass 不同的是，Occlusion query 主要在物体级别做culling。ue4同样使用的是hardware occlusion queries( query)的。在这一个pass中，所有的不透明物体会被渲染为一个occluder(包围盒)：
在根据深度计算query之后，query的会传回cpu,我们就可以计算每个物体有多少像素可见。这样我们就能知道物体最终是否会被渲染。
在不透明物体的query pass之后。 还有一些其他的query pass，例如灯光(点光源)会有一个ShadowFrustumQUeries(一般是画一个球体)反射则有 PlanarReflection queries(一般是画一个 Cube)
4.HZB generation
接下来UE4会生成场景的Hi-z(Hierarchical Z)，R16_Float 格式，这一步也就是对之前的zbuffer做连续的downsample。HZB buffer会在之后的计算中起到很多作用，特别是Image based 的lighting技术，例如SSR等等。
5.ShadowMap 渲染
接下来的一步就是渲染shadowmap(shadowDepth,注意，这里指的是实时阴影的计算。根据UE4中灯光类型的不同，实时阴影的计算也有一定的差别。
UE4中的灯光类 型分为stationary， static，moveable三种，相应的每种灯光cast realtime shadow的方式也不同。
对于stationary light，静态物体的阴影会bake到static shadowmap，shadowmap只计算标记为动态物体的阴影，而对于dynamic light 会对所有物体投射阴影，而静态灯光不会产生实时阴影。
ue4首先会渲染方向光的阴影，一般会渲染3split的cascade shadow ，所以我们能在截帧信息看到split0， split1和split2，注意cascade split数目在ue4中也是可以在方向光参数中设置的变量。
之后是stationary light的shadow渲染，注意这里只针对场景中的moveable的物体。
最后是对于movable light的渲染，对于movable的方向光，ue4仍然是cascade shadow map计算阴影，需要注意的是对于movable的点光源，ue4使用了cubemap shadowmap，在cubeshadowmap的第一个pass CopyCachedShadowMap中，ue4会直接cachecopy static物体的shadowmap，例如这个场景中
圆柱体为static，其他两个物体设为movable，因此最后我们能看到Shadow 只画了两个几何体。
最后动态物体的shadow会添加在这个cubemap上面。
注意 shadowcubemap使用了geometry shader来选择画在那个面上。
6.G-prepass
其实在g-prepass之前还会渲染一个volumtric fog(如果场景中有的话) 这里我们先跳过，
G-prepass就是ue4中常说的basspass，这个bass会真正的渲染场景并产生我们在deferred shading 中需要的G-buffers:
SceneColorDefferd:包含了间接光照信息，例如lightmap和lightprobe(ue4叫ILC)
场景Normal
场景Albedo
PBR Specular信息
除此之外还有针对特殊shading模型的特殊Custom Data RT(例如 头发的tangent sss等)和Pre baked shadow factors RT，一般情况下UE4的渲染需要5-6个RT输出，除了产生GBuffer的计算之外，在这一步UE4还会计算完间接光照的信息，主要包括采集lightmap信息(静态物体)和球谐函数信息(Indirect lighting cache或者Volumetric light map)
UE4在4.18引入了新的半动态光照技术也就是Volumetric lightmap，相比于之前的 ILC机制，Volumetric lightmap能够更加细致的根据物体的空间位置对球谐函数probe做插值(ILC是每个物体做插值)
Volumetric lightmap的Texture3d
7.Velocity rendering
在basepass之后是Velocity rendering，Velocity buffer会渲染为一张R16B16UNorm，主要用于motion blur和TAA
8.Pre-Lighting
UE4在这一部分会计算DeferredDecal(屏幕空间贴花)，和AmbientOcclusion， UE4的屏幕空间AO考虑了深度和Normal信息，UE4的SSAO分为两个Pass，第一个pass会计算一个四分之一的RT，使用的是四分之一的normal和depth， 注意这里就用了之前生成的HZB buffer，第二个pass会渲染一个全分辨率RT并与第一个combine.注意最后计算的结果会乘到SceneColorDeferred这个RT上.
9.Lighting
接下来就是光照的渲染部分，UE4在渲染灯光光照时会先处理translucent 物体的照明。
在这之后会分别计算阴影灯光和非阴影灯光的standarddeferredlighting，
在这个pass之后，SceneColorDeferred RT就会包含最后直接光照的结果
10.ImageBased lighting
接下来UE4会渲染屏幕空间的一些光照效果，例如SSR(屏幕空间反射)还有ReflectionProbe等等
SSR会用到我们之前生成的HZB，在屏幕空间做Zbuffer的raymarching ，同时ue4的SSR会每帧jitter和TAA结合来提高质量。当击中时SSR的shader会采样上一帧的RT来获得颜色
在SSR之后是ReflectionEnvironment Pass。这一步会结合场景中的反射球和之前的SSR结果会叠加到SceneColorDeferred这个RT中。
11. Post Processing
最后一步是UE4的Postprocessing，主要包括Temporal AA; BEyeAdaption等等这些可以自定义的内容。
UE4 的TAA会经历两个pass，第一个pass会处理没被stencil的像素(例如有粒子的时候)，会用到MainRT和velocity buffer，第二个pass会处理例如粒子这样stencilled的pixel。两个pass的区别在于混合当前RT和History buffer的blendfactor的不同，第一个pass的blendfactor会根据pixel的亮度距离等等变化，而第二个pass的blendfactor啧固定为0.25，也就是说第二个pass的像素会更多考虑当前像素，很可能这是为了减少TAA中很常见的ghosting effect
注意：TAA的处理只包含动态的光照部分，也就是纯动态光照。
以上的分析还是省略了很多的细节，例如半透照明这种还没涉及。从整体的流程分析来看，UE4在渲染方案的时候还是最大限度的考虑了功能的最大化，UE4的DS renderer包含了非常齐全的光照特效，包括静态的lightmap，动态的lightprobe，屏幕空间的lighting，以及一些影视级别的，例如头发的渲染模型等等，但同时为了功能UE4的计算任务是很繁重的，因此也就不难理解为什么UE4需要Pre-Z和Occlusion Culling去剔除掉不用的像素。当然，对于使用UE4制作游戏的团队来说，根据游戏内容特点，画面的艺术风格，渲染管线都没必要一成不变，例如对于一款世界的野外。我们可以考虑省掉Pre-Z的过程，或者，只用地表去画Pre-Z，又或者对于NPR画面的游戏我们完全可以不需要6-7个RT去做Deferred shading。UE4应对这些定制化开发的需求的方法就是：。代码就在DeferredShadingRenderer.cpp里。
下一篇：没有了
深度VR观察记录点滴事情...回味成长历程
Unity3D 图形渲染个人见解
图形渲染是现在每一个游戏引擎最基本的功能，如果没有基本的图形渲染的功能，那么我们在玩游戏的时候就一堆代码呈现在眼前，这是何等伤眼睛的说。如今各家的游戏引擎都在图形渲染这块下足了功夫，CE和UE更是将图形渲染这块弄到极致的地步，CE和UE的画面都基本和电影画质一般，Unity3D一直以来都是主打多平台的功能个为主，Unity3D 4.x的效果以及画质一直是为人所诟病的问题，尤其是古剑和仙剑5出来之后，Unity3D更是被人喷的一文不值，在过内外大型的单机游戏都没有Unity3D的身影，正是如此Unity3D
5.x最大的改变也就是灯光渲染、烘培等下足了功夫，Unity3D 5.x的宣传片《亚当》CG短片的画质堪称电影基本的画质，甚至让人惊叹这是游戏引擎做得么？如果有兴趣的朋友可以去看看： 那么就不废话了，进入正题吧~
画面效果和性能一直是游戏引擎的两大难题，要想性能好就要那画面效果来开刀，要想画面效果好就只能拿性能来填补，如今很多人都往虚拟现实行业跳坑，VR行业更是如雨后春笋般冒出来，但是大部分的VR行业都是一堆人傻钱多的问题领导人，对于游戏引擎都是一窍不通的人，尤其是VR行业来说更是要命的问题，VR设备是一种非常吃硬件的设备，只要你的游戏性能优化不好就立马出现掉针问题，VR行业如今最求的真是的画面质感，如此一来对于图形渲染这块都要程序猿去优化处理的Unity3D就是一个老大难的问题，性能和效果都是要基于硬件配置进行调整效果，在不影响性能的前提下将游戏画面效果进行强制设置，这也是大型单机的常会自动调节性能最好的配置。
一、Unity3D的灯光渲染问题
Unity3D如果要做到效果和性能平衡，就要在项目初期制定硬件配置，那假设1080的硬件显卡配上VR设备，这样的配置Unity3D要制作60帧以上的流畅画面游戏，就相对比较难。因我们必须要严格控制模型面数和控制灯光数量，尽量避免使用实时阴影这些功能，因为这些功能会成倍数的增加模型面数和顶点数。
下面是cube在无平行光模型面数和顶点数，如图所示：
下面是实时平行光下的模型面数和顶点数：
这里可以看出，平行光的对模型面数和模型的顶点数并没有影响，这个是因为照射到模型面上的光的数据参数都是一样的，平行光没有开启阴影功能因此并不需要重新渲染图层上去，因此模型面数和顶点数都不会有影响，然后我们来看看开了阴影的平行光后，我们的模型面数会有如何的变化。如图所示：
上图就是开了阴影的平行光，可以明显看到模型的面数从14激增到64，更可怕的是顶点数从28增加到128了，这是为啥呢？
原理很简单，因为灯光开启实时阴影的时候Unity3D会根据你模型位置和灯光的参数计算出阴影效果，然后再模型上进行了多次渲染然后达到给模型附上阴影的效果。因此实时阴影是非常消耗性能的功能，因此在移动端以及VR上都不建议使用这个功能，最好的方法就是让模型让进行光阴烘培后再倒入Unity3D进行使用，这是我们就只需要打出简单的灯光进行补光即可。（PS：不建议在Unity3D上进行灯光烘培，除非你是大神级别的，我们之前项目用Unity进行灯光烘培后场景的感觉很难把控，而且模型常常出现黑斑）
二、Unity3D模型问题
现在最常见的就是，模型动不动就上万面有些更加离谱的是模型上百万面，然后倒入Unity里面直接卡死或者是掉帧非常严重，其实在游戏万级别的模型面数是基本很少见的，虽然硬件设备一直在提升但是并不是所有人都能配置上高配显卡，因此游戏场景常常会做3套以上的模型，然后根据你的自己配置来调用使用那套模型。因此我们需要根据项目合理制定模型面数，如果牺牲性能来达到效果的游戏，在玩家体验感上都会大打折扣。
但是现在虚拟现实公司并不会避免使用精模，而是为了幅度的开发成本使用高精度的模型，常常导致摄像机照到的面数和顶点数突破百万级的，然而官方给出的优化方法中提到，Unity3D的摄像机尽量避免超过200K到2M的顶点同时出现在摄像机前，这些要根据你的硬件设备进行调整，下面是Unity官方的优化说法：
这里肯定会有人说，那么让客户配置一个高配的电脑就行了呗，我告诉你这纯属扯淡，就好比我近期做得项目，整个项目模型顶点数已经超过官方给的峰值范围，出现在镜头前的模型面数达到惊人的千万级别面数，然而1080并不能拯救我们的说，就算将网格合并设置静态物体，都无法让1080上升到理想的帧数。模型面数和性能正是如此难以调节的问题。优化方式有几种，但是老板并不接受，所以我也懒得和他废话。这里肯定有人会问为啥会达到千万级别的面数，想知道的人可以私聊我。
那么如果想让自己的性能和效果达到理想效果该怎么办呢？
1、这样就要对模型进行详细的繁琐的调整，根据项目视觉范围制定中低模型。
2、尽量使用高模烘培后的贴图以及法线去修改成中低模型，远景就采用面片或者更加简单的模型进行替代。
有人会问如果远景使用面片这些能做出效果么？我可以很肯定的告诉你可以。之前的项目我们外包了一个桥的模型，然后给他们给过来的模型超出我们模型面数要求，因为项目是用在移动端上，而且桥作为远景来用，我们将烘培出几张贴图并且加上法线来加强它的凹凸感，最后的效果和万面级的模型一样。
所以在游戏引擎中，模型的精美是!=模型面数的，如果没办法做到将精模型做成中低模型，这个公司的终究会因为模型面数吃大亏的。（公司老板大部分都不懂这块，因此吃亏永远是我们程序）
模型精度固然重要，但是在游戏引擎这会成为性能的极大障碍，因此学会高精模转中低模型是非常重要的东西，细节的东西都用法线和漫反射贴图进行展示，这即可减少模型面数又不失模型的精度。
三、Unity3D纹理贴图合并
纹理贴图合并是一个美工必备技能之一，要做到是尽量避免使用重复的多张图片。神马意思呢？容我慢慢道来，就如刚刚的cube有6个面，一个面数都使用不用的贴图这样，就会有6张贴图的资源需要加载进去游戏引擎里面，虽然6次加载的时间并不是很久的，如果有一万个模型呢？那计算机就要加载6万多次，虽然对现在电脑来说并不是什么大问题，但是却要牺牲玩家时间进行等待。如果将6张题图都合并到一张或者的图里，这样就需要一次就可以加载完毕，对于纹理合并这块用过NGUI就非常有经验，将各种小图进行纹理合并形成一张大图，UGUI在一块虽然模糊了纹理合并的问题，但是到最后打包工程项目的时候UGUI还是会帮你打包成图集，这是为了节省加载以及优化性能上考虑。为此我们也要学NGUI或UGUI一样，将贴图都打包成
一张完整的16-bit或者32-bit图片。
为甚要这样做呢？因为计算机是通过二进制进行计算和存储的，我们使用2的N次幂有助于计算机内存的对齐，这样在性能上也有一定的帮助。所以在官方文档中也建议用16-bit或者32-bit的贴图，而且我常说的512，都是2的N次幂。所以模型要对贴图的优化合并模型中的小图，减少小图的加载有助于Unity对模型的优化。
那么按照我上面的说法还会有一个问题，如果多个模型同时使用到同一种材质呢？这样我们就只需要一张即可，如果法线贴图不一样就生成新的法线即可。
以上为个人对Unity的渲染做出的个人见解，不喜勿喷，欢迎指出文章的问题。
（最后给各位学习Unity3D的新人来提醒，如果公司老板最对效果有最求而且不愿意花时间去弄模型的公司，建议尽早递辞呈，游戏引擎是没办法在很短的时间做到CG般的效果，因此他们都会牺牲性能来达到所需要的效果，如果你遇到一个让去优化一个千万级面数的老板的时候，你就会知道这是有多蛋疼的事情，就连1080也只有6-7帧的时候，你会感觉整个世界都黑了，然后老板还一个劲的往里面加面数的时候，你真的会觉得这个老板就TM给你添乱，所以千万别进到这样的公司~~~）
没有更多推荐了，喜欢开发游戏的渣渣一枚。https://www.artstation.com/christiantam投稿：231粉丝：6527分享--dynmicweibozoneqqbaidu将视频贴到博客或论坛视频地址复制嵌入代码复制微信扫一扫分享收藏0硬币--稍后看马克一下~用手机看转移阵地~用或其他应用扫描二维码手机下视频请使用扫码若未安装客户端，可直接扫此码下载应用看过该视频的还喜欢正在加载...miniOFF全新的Unity性能诊断&优化方案来袭，简单优化，快人一步！
关于Unity渲染优化，你可能遇到这些问题
原文链接：
Draw Call半透明物体渲染多层纹理渲染Graphics.PresentAndSyncVBO相机后处理特效
Draw Call相关
Q1：移动游戏场景中，相同的怪物，Draw Call会动态合并吗？如下设置可行吗？
默认情况下，带蒙皮的Mesh是不支持动态合批的。如果场景中相同材质的蒙皮网格数量很多，可以考虑通过插件MeshBaker来进行合并，具体方法大家可以参考
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q2：Draw Call和Setpass Call，这两个指标主要是看哪一个？关于这点众说纷纭，很多地方都是说看SetPass Call，但是在UWA的性能测试中，还是把Draw Call当成唯一指标。
在 Unity 5.x 中，SetPass Call与 Draw Call相比，SetPass Call的指标与性能相关性更大（比如Static Batching的开启不影响Draw Call数，而SetPass Call通常会明显下降）。但 SetPass Call在某些情况下也同样存在问题，比如往一个场景中添加任意个相邻且材质相同的大网格物体（使Dynamic Batching失效）时，SetPass Call并不会变化。因此在UWA中，我们所使用的是类似Profiler 中 Total Batches
这一项指标，通常该数值与 Frame Debugger 中的数值基本一致，因此可以通过该工具来查看每个Batch的内容，从而更有针对性地进行优化。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q3：我UWA报告中“渲染模块”界面中看到大部分场景中的三角面片数是正常的，但在某一帧时DrawCall、Traingle、蒙皮网格数骤然提升，请问这可能是什么原因导致的？这三个参数的变化曲线是否有规律？为什么我在切换场景的时候也会有400多的DrawCall呢？
从图中看，这种情况发生在场景切换处。这种情况的发生原因很可能为一次性动态加载大量GameObejct，然后再手动Deactive当前并不需要使用的GameObject。研发团队可以查看该峰值处的场景名称和相关截图，从而来进一步定位发生该问题的根本原因。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q4：关于Static Batching, 场景中物件组合成大的Mesh，那么判断子Mesh要合入大的Mesh中的依据是什么？材质？勾选Static?我有一个模型A并勾选Static，使用材质A，怎么看到也和其他材质的Mesh合并到一块去了(Combined Mesh)？
勾选Static的GameObject下的Mesh都会被合入CombineMesh（无论什么材质），且每个Mesh都作为SubMesh存在。在Unity 5.3之前，对于渲染顺序相邻且材质相同的SubMesh则会动态将其索引数组拼合，从而合成一个Draw Call。而Unity 5.3之后则不再拼合索引数组，因为在不切换材质时产生多个Draw Call的开销并不大，而这多个Draw Call会被统计为一个Batch。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q5：Unity对Dynamic Batching的数量是否有限制？或者说对Saved by Batch的数量是否有限制？
Unity对于任何Mesh的面片都有65536的个数限制，拼合后的面片数也是如此。
Q6：请教，角色分部件换装可行吗？比如衣服裤子分开，都是用Skinned Mesh Render，有没有办法合并降低Draw Call？
可以通过合并网格的方式来达到降低Draw Call的效果，具体可查看Asset Store中的换装例子：Character Customization。但是，在角色换装时需要注意以下几点：
（1）装备与角色必须是共用一套骨骼的；
（2）各装备之间所用的材质必须相同。
开发者需要注意，只有同时满足以上两个条件时，才能达到只使用少量Draw Call来进行动态换装的效果。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q7：请问，Canvas里的东西移出了屏幕后，DrawCall没降低，那么它还会每帧去绘制吗？
DrawCall没降低，说明CPU依然将这部分的网格提交到了GPU。因此虽然UI元素已经不可见，但其CPU开销（包括切换渲染状态，提交VBO等）依然是在的，只是对GPU不会造成明显影响，因为最终并没有进行像素的渲染。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q8：能否对提升NGUI的渲染效率提供一些思路？
开发团队可以从以下几点入手：
通常一个Panel会产生1个或多个Draw Call，以一个Panel为单位，Draw Call 的数量通常由当前 Panel 中使用的Atlas、Font的数量所决定。
要降低UI渲染时的 Draw Call数量则需要对 Atlas 的制作进行合理的规划，即在保证使用较少的 Atlas 的同时，还需要保证 Atlas之间不会存在交叉遮挡。
要注意UI Texture的使用，每个UITexture自身会占用一个Draw Call，同时如果其Depth值穿插在了其他来自相同Atlas的UISprite中，还会导致Draw Call的打断，造成不必要的额外Draw Call。
另外还可以借助Panel Tool和Draw Call Tool来对UI部分的Draw Call进行分析，前者可以显示每个UIPanel包含了多少个Draw Call，而后者可以显示每个Draw Call由哪些UIWidget组成。"
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q9：关于场景中玩家和NPC名字的DrawCall的问题。我们项目中是使用TextMesh挂到场景单位上，但是这样每个名字就占了一个DrawCall，请问有没有好的办法优化呢？
游戏中的HUD的做法一般有两种，一种是如上的做法，另一种则是通过NGUI/UGUI来制作HUD。第二种的实现方法大致如下：
计算屏幕中角色在屏幕中的位置；
根据屏幕中的位置来计算各自HUD的位置，并根据HUD的数量分别放置在一个或几个Panel/Canvas下。
第二种方法的优势是尽可能用少的Draw Call数来渲染角色的HUD。开发团队可以就该方法来进行尝试。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
半透明物体渲染相关
Q1：这个批渲染是什么？好像开销很高 。
从图中看出，这是场景中不透明物体的渲染开销。建议研发团队对当时场景中的不透明物体（地形、建筑等）进行进一步检测，主要查看其三角面片数是否过高、Shader是否过于复杂等。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
多层纹理渲染相关
Q1：我们游戏用的是T4M，4层Tilling贴图+1层融合贴图，发现手机发热现象严重，影响性能的表现，请问有什么标准或者参考数据吗？
对于中低端机器来说，我们建议地形纹理所刷的层数要尽可能小于3层。在中低端设备中，纹理采样次数越多，则GPU的压力越大，发热效果也就越明显。
在UWA性能测评报告中，我们加入了针对Graphics.PresentAndSync的统计，从而让大家来看到项目运行过程中，GPU的压力情况。同时，在设备的温度显示中，建议大家关注温度的走势图，看看是否存在大幅向下回落的情况，如果存在，则很可能是设备因为过热而主动降频。
Graphics.PresentAndSync耗时统计
设备温度走势
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Graphics.PresentAndSync相关
Q1：我们在编译安卓版本时，在某些设备上（Sony L36h,小米4）调试时，发现有一个时间消耗项叫Graphics.PresentAndSync，该函数对性能的消耗会特别夸张（渲染20毫秒，这个能达到50毫秒）。查了相关文档，发现该函数好像和安卓设备的垂直同步有关，但是大部分安卓设备的垂直同步是不可以关闭的。请问有什么好的办法解决吗？
概括来说，该值很高表示 GPU 负担很重，可以从降面，或者简化shader入手。
Graphics.PresentAndSync 是指主线程进行Present时的等待时间和等待垂直同步的时间。该参数在Profiler中CPU占用通常较高，且仅在发布版本中可以看到。究其原因，其实是CPU和GPU之间的垂直同步（VSync）导致的，主要是与项目是否开启多线程渲染有关。当项目开启多线程渲染时，你看到的则是Gfx.WaitForPresent；当项目未开启多线程渲染时，看到的则是Graphics.PresentAndSync。
其中的原理，可以参照我们之前对其函数的详细解释：。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q1：我们现在有一个场景，Draw Call和面数都在正常范围内，Camera的距离也和其他场景一样，但是VBO却非常高。下图是该场景的数据情况，该场景下有很多复用的模型，如果不勾选Static那VBO会下降，但是Draw Call会上升。那我能否通过合并模型的方式把VBO降下来呢?
当你勾选Static时，Unity 会将其进行 Static Batching，进而将生成一个较大的VBO来进行渲染，同时降低Draw Call。而如果不勾选时，则引擎无法对其进行Batch，所以VBO会降低，而Draw Call升高。
对此，我们的建议如下：
1、一般来讲，降低Draw Call的意义大于降低VBO；
2、在Draw Call较低的情况下，比如当前的50+，可以考虑适当增加一些Draw Call来降低VBO的占用，一方面可以降低带宽的压力，另一方面也可以适当降低一些内存。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
相机后处理特效相关
Q1：关于抗锯齿和BLOOM，有什么好的优化方案或者优秀插件推荐？
通常在中低端的设备上，抗锯齿并没有比较高效的方案；而对于中高端的设备，可尝试直接使用 Unity 内置的 MSAA 功能，但也只推荐使用 2x。
关于Bloom效果，以下是适用于移动端，且评价较好的一款插件：BloomPro
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q2：如何在移动设备上，对Bloom和全屏抗锯齿进行优化？Unity标准资源里面自带的效率比较低（已经尝试过Bloom(Optimized)）。
建议使用Asset Store上适合移动端的Bloom Shader插件，比如FxPro: Bloom&DOF和BloomPro等。
对于AA，目前在移动设备上并没有特别优化的方法，仅能建议在低端设备上关闭AA功能，而在高端设备上可尝试开启较低倍数（2x）的MSAA。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Shader解析相关
Q1：图中的Material.SetPassFast占用很高，这是我在第一次实例化一个特效，但是第二次实例化就不会出现高值了，请问能怎么优化吗？
该过程是在处理Shader，Unity 5.3以后在第一次显示时才会将Shader进行Warmup，所以就会造成一次峰值卡顿。研发团队可以参考我们之前的分享：以加深理解。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q2：Shader.Parse 和 Shader.CreateGpuProgram 到底是做什么的？它们什么时候执行？
Shader.Parse体现的是Shader的加载和解析， Shader.CreateGpuProgram 是将Shader传入GPU的一次提交，GPU驱动会对其进行编译，以适应于特定的设备或平台。在Unity 5.x版本中，Shader.Parse在Shader资源加载时进行执行，而 Shader.CreateGpuProgram在所在GameObject第一渲染时进行执行。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
Q1：如下图，我们发现WaitingForJob这个函数消耗过高导致了卡顿，请问该卡顿是否由于渲染压力过大导致？
从图中看，该线程最后是在等待 Canvas.sortjob，而这是 UI 排序造成的开销（自Unity5.2版本开始，UGUI的部分计算已经移出了主线程）。
详情参考：
因此理论上，这是 UI 的 canvas.sortjob 在指定的时间上没有完成，从而使得渲染线程等待，且最终导致主线程进行等待而造成的开销。
该问题来自UWA问答社区，如您对该问题仍有疑问，可以转至社区进行进一步交流
没有更多推荐了，