文化网站建设需要的功能,软件开发岗位介绍,织梦如何将wordpress,免费下载网站有哪些大家好#xff0c;这里是七七#xff0c;前段时间在忙一些事情#xff0c;最近终于有空来更新优化篇了。本文本打算分为上下两篇#xff0c;但为了看更方便#xff0c;就多花了几天写成一文发布#xff0c;具体是介绍了图形优化中批处理的具体效果#xff0c;虽然本文篇…大家好这里是七七前段时间在忙一些事情最近终于有空来更新优化篇了。本文本打算分为上下两篇但为了看更方便就多花了几天写成一文发布具体是介绍了图形优化中批处理的具体效果虽然本文篇幅较大但还是建议寻求Unity进阶或图形进阶的读者仔细阅读。
话不多说开始介绍
介绍
在3D图形和游戏中批处理是一个非常通用的术语它描述了将大量任意数据块组合在一起并将它们作为单个大数据块进行处理的过程。这对于CPU特别是GPU来说是理想的因为它可以使用多个内核同时粗粝多个任务。在内存中不同位置来回切换内核是需要时间的因此切换内核所花的时间越少越好。
在某些情况下批处理的对象指的是网格、顶点、边、UV坐标和其他用于描述3D对象的不同数据类型的大集合。然而该术语也可以简单代表批处理音频文件、精灵、纹理文件和其他大数据集的行为。
因此为了避免混淆本专题提到的Unity中的批处理通常指的是两种用于批处理网格数据的主要机制动态批处理和静态批处理。这两种方法本质上是几何体合并的两种不同形式用于将多个对象的网格数据合并到一起并在单一指令中渲染它们而不是单独准备和绘制每个几何体。
将多个网格批处理为单个网格是可以实现的因为没有规定网格对象必须是3D空间中连续的几何体。Rendering Pipeline管线渲染可以接受一系列没有共同变的顶点因此可以将本来需要多个渲染指令的独立网格合并为单个网格用单一指令渲染它。
多年来关于动态批处理和静态批处理系统的触发条件以及批处理在什么地方能够带来性能提升一直存在许多困惑。毕竟在某些情况下如果没有正确使用批处理它的确会恶化性能。正确理解这些系统将有助于我们掌握显著提升应用程序图形性能所需的知识。
本文涵盖如下专题 管线渲染和Draw Call概念的简单介绍Unity的材质和着色器如何一起工作以渲染对象使用Frame Debugger可视化渲染行为动/静态批处理的工作原理及优化方式 一、Draw Call
在单独讨论动态批处理和静态批处理之前首先要明白它们在管线渲染中试图解决的问题。
这些批处理方法的主要目标是减少在当前视图中渲染所有对象所需的Draw Call数量。就最基本的形式而言Draw Call只是一个从CPU发送到GPU中用于绘制对象的请求。 注意Draw Call是这一过程的通用行业术语但在Unity中有时也称为SetPass Call因为一些底层方法也命名为SetPass Call。可以将Draw Call理解为初始化当前渲染过程之前的配置选项。本文剩余部分将其统称为Draw Call。 在请求Draw Call之前需要完成一些任务。首先网格和纹理数据必须从CPU内存RAM送到GPU内存VRAM中这通常发生在场景初始化期间但仅限于场景文件知道的纹理和网格。如果使用非场景中的纹理和网格数据在运行时动态实例化对象那么必须在它们实例化时完成加载。接着CPU必须配置处理对象这些对象就是Draw Call的目标所需的选项和渲染特性为GPU做好准备。
这些CPU和GPU间的通信任务是通过Graphics API进行的这可以是DirectX、OpenGL等取决于针对的平台和指定的图形设置。这些API调用通过一个称为驱动的类库来执行该类库包含一系列错综复杂的设置、状态变量以及可以在应用程序中配置和执行的数据集只是驱动库旨在同时服务多个程序以及来自多个线程的渲染器调用。可用的特性会根据我们的显卡和所针对的Graphics API发生巨大的变化更高级的显卡支持更高级的特性但这需要由更新版本的API支持因此需要更新的驱动程序来启动它们。多年来创建的各种设置、支持的特性和版本之间的兼容性级别特别是诸如OpenGL这样的旧API其数量简直令人难以置信。幸运的事在某种抽象级别上所有这些API都倾向于以类似的方式运行因此Unity可以通过一个公共接口支持很多不同的Graphics API。
在渲染对象之前必须为准备管线渲染而配置的大量设置常常统称为渲染状态Render State。除非这些渲染状态选项发生了变化GPU将为所有传入的对象保持相同的渲染状态并以类似的方式渲染它们。
更改渲染状态是一个耗时的过程。例如如果将渲染状态设置为使用一个蓝色纹理文件然后要求它渲染一个巨大的网格那么渲染会非常快整个网格都显示为蓝色。然后可以再渲染9个完全不同的网格它们都显示为蓝色因为没有改变所使用的问题。然而如果先用10种不同的纹理渲染10个网格就将花费更长的时间。这是因为在每个网格发送Draw Call指令之前需要使用新的纹理来准备渲染状态。
用于渲染当前对象的纹理在Graphics API种实际上是一个全局变量而在并行系统内修改全局变量说起来容易做起来难。在诸如GPU这样的大规模并行系统中实际上必须在修改渲染状态之前一直等待直到所有当前的作业打到同一个同步点为止换句话说最快的内核需要停下等待最慢的内核赶上这浪费了它们可以用于其他任务的时间到达同步点后需要重新启动所有的并行作业。这会浪费很多时间因此请求改变渲染状态的次数越少Graphics API越能更快递处理请求。
可以出发渲染状态同步的操作包括但不限于立即推送一张新纹理到GPU修改着色器、照明信息、阴影、透明度和其他任何图形设置。
一旦配置了渲染状态CPU就必须决定绘制哪个网格用什么纹理和着色器以及基于对象的位置、旋转和缩放这些都在一个名为变换的4✖️4矩阵中表示这正是Transform组件名字的由来决定在何处绘制对象然后发送指令到GPU以绘制它。为了使CPU和GPU之间的通信保持活跃新指令被推入一个名为Command Buffer的队列中。这个队列包含CPU创建的指令以及GPU每次执行完前面的指令后从中提取的指令。
批处理提升此过程性能的诀窍在于新的Draw Call不一定意味着必须配置新的渲染状态。如果两个对象共享完全相同的渲染状态信息那么GPU可以立即开始渲染新对象因为在最后一个对象完成渲染之后还维护着相同的渲染状态这消除了由于同步渲染状态而浪费的时间也减少了需要推入Command Buffer中的指令数减少了CPU和GPU上的工作负载。
二、材质和着色器
在Unity中渲染状态本质上是通过材质呈现给开发者的。材质是着色器的容器着色器是一种用于定义GPU应该如何渲染输入的顶点和纹理数据的简短程序。着色器本身没有必要的状态信息来完成任何有价值的工作。着色器需要诸如漫反射纹理、法线影响和光照信息之类的输入并有效地规定了为了呈现传入的数据需要设置哪些渲染状态变量。 提示着色器之所以如此命名是因为多年前它们原本仅实现为处理对象的光照和着色应用阴影原本是没有阴影的。现在它们的功能已经有了巨大的增长现在更通用的功能是作为访问各种不同并行任务的可编程接口但依旧使用之前的名字。 每个着色器都需要一个材质而每个材质必须有一个着色器。甚至新导入场景中的网格如果没有赋予材质就会自动被赋予默认隐藏的材质为它们提供基本的漫反射着色器和白色色彩。因此无法绕过这一关系。 提示注意一个材质只支持一个着色器。要对一个网格使用多个着色器需要将多个材质赋予该网格的不同部位。 所以如果想要最小化渲染状态修改的频率可以减少场景中使用的材质数量。这将同时提升两个性能CPU每帧花费更少的时间生成指令并传输给GPU而GPU不需要经常停止重新同步状态的变更。
为了理解材质和批处理的行为先介绍一个简单的场景。然而在开始之前应该仅用一些渲染选项因为它们会产生一些额外的Draw Call这可能会令人分散注意力 1、导航到EditProject SettingsQuality并设置Shadows为Disable Shadows或者选择默认的Fastest品质级别。 2、导航到EditProject SettingsPlayer打开Other Settings选项卡并禁用Static Batching和Dynamic Batching如果它们是开启的。 下一步创建一个场景其中包含一个方向光、4个立方体和4个球体每个对象都有独特的材质、位置、旋转和缩放。
然后看Game窗口的Stats弹出框中的Batching值共有9个批处理。该值严格等于渲染场景中使用的Draw Call数量。当前视图将消耗其中一个批处理来渲染场景的背景场景的背景可以设置为Skybox或Solid Clor这取决于摄像机对象的Clear Flags设置。
剩余8个批处理用于绘制8个对象。对于每个对象Draw Call需要使用材质的属性准备管线渲染并请求GPU根据对象当前的变换设置渲染给定的网格。给每个对象提供不同的纹理文件用于渲染来确保材质是唯一的。因此每个网格需要不同的渲染状态所以这8个不同网格都需要各不相同的Draw Call。
如前所述理论上可以通过减少系统修改渲染状态信息的频率来最小化Draw Call的数量。因此一部分目标是减少使用的材质数。然而如果所有对象都设置为使用相同的材质则性能依旧没有任何提升批处理数量依然是9。这是因为渲染状态变更的数量没有真正减少也没有高效低合并网格信息。遗憾的是管线渲染不够智能意识不到在重复写入完全相同的渲染信息并要求它一次又一次地渲染相同的风格。
三、Frame Debugger
在深入讨论批处理之前先研究一个有用的工具Frame Debugger它有助于确定批处理是如何影响场景的。
要打开Frame Debugger在主窗口中选择WindowFrame Debugger或者在Profiler的Rendering区域中单击BreakDown View Options中的Frame Debugger按钮这两个操作都可以打开Frame Debug窗口。
单击Frame Debug窗口的Enable按钮可以观察场景是如何创建的每次执行一个Draw Call。一般左侧显示GPU指令列表右侧显示选中的Draw Call的详细信息。
Frame Debugger窗口提供了很多有用的信息可以用于调整单一Draw Call的行为但最有用的区域是左边面板的Drawing部分其中列出了场景中的所有Draw Call其中的每一项表示一个唯一的Draw Call和它渲染的对象。该工具的一个非常有用的特性是单击其中任一项就能立刻在Game窗口中看到场景渲染到所单击记得那一项所需的Draw Call。这样就可以快速、直观地区分两个连续的Draw Call也很容易准确地指出给定的Draw Call渲染了哪些对象。可以通过查看在Draw Call期间出现了多少个对象来帮助确定是否对一组对象进行批处理。
四、动态批处理
动态批处理有下面3个重要优势 在运行时生成批处理中包含的对象在不同帧之间可能有所不同这取决于哪些网格在主相机视图中是可见的能在场景中运动的对象也可以批处理 如果返回Player settings页面并开启Dynamic Batching将看到批处理数量从9降到6。动态批处理自动识别共享材质和网格信息的对象因此将它们合并到一个大的批次中以供处理。还应该看到Frame Debugger中有一列不同的项展示了正在进行动态批处理的网络。
结果是4个立方体合并到一个名为Dynamic Batch的Draw Call中但4个球体依然通过4个独立的Draw Call渲染这是因为4个球体不满足动态批处理的要求。尽管它们使用的材质相同但还必须满足很多其他条件。
对网格进行成功的动态批处理所需满足的需求列表可以在Unity文档中找到。
为给定网格执行动态批处理的要求如下 所有网格实例必须使用相同的材质引用。只有ParticleSystem和MeshRenderer组件进行动态批处理。SkinnedMeshRenderer组件用于角色动画和所有其他可渲染的组件类型不能进行批处理。每个网格至多有300个顶点但是着色器使用的顶点属性数不能大于900.这意味着对于复杂的着色器每个网格的最大顶点数可能小于300。对象不能在变换中包含镜像也就是说一个具有正比例的游戏对象A和一个具有付比例的游戏对象B不能放在一起批处理。网格实例应该引用相同的光照纹理文件材质的着色器不能依赖多个进程网格实例不能接受实时投影整个批处理中网格索引的总数有上线这与所用的Graphics API和平台有关一般索引值为3264。 重点关注术语材质引用因为如果使用两个不同的材质但他们的设置相同则渲染管线的智能并不足以发现这一点会把它们当成不同的材质进而不执行动态批处理。其他要求已经解释过了然而有几个要求的描述并不直观需要额外解释。
4.1顶点属性
顶点属性只是网格文件中基于每个顶点的一段信息通常表示为一组浮点数。顶点属性包括但不限于顶点位置相对于网络的根、法线向量一个从对抗表面指向外面的向量通常用于光照计算、一套或多套纹理UV坐标用于定义一张或多张纹理如何包裹网格甚至可能包括每个顶点的颜色信息通常用于自定义光照或扁平化着色、低多边形风格的对象。只有着色器使用的顶点属性总数小于900的网格才会进行动态批处理。 注意查看网格的原始数据文件其中包含的顶点属性信息比Unity载入内存的少这是由于引擎会将网格数据从原始数据格式转化为内部格式。因此不要假设3D建模工具提供的顶点属性数量是最终的数量。验证属性数量的最好方式是将网格对象拖到场景中在Project窗口中找到MeshFilter组件在Inspector窗口的Preview子区域中查看verts值 在伴随的着色器中每个顶点使用的属性数据越多900个属性预算就消耗得越多从而减少网格允许拥有的顶点数量这些顶点不能再用于动态批处理。例如简单的漫反射着色器只能给每个顶点使用3个属性位置、法线和一组UV坐标因此动态批处理可以使用这个着色器来支持总共有300个顶点的网格。然而在更复杂的着色器中每个顶点需要5个属性只能支持不超过180个顶点的网格的动态批处理。另外请注意即使咋着色器中每个顶点使用不到3个顶点属性动态批处理仍然只支持最多300个顶点的网格因此只有相对简单的对象才适合动态批处理。
这些限制证实场景开启动态批处理之后尽管所有对象共享相同的材质引用也仅节省3个Draw Call的原因。Unity自动生成的立方体网格仅包含8个顶点每个顶点都带有位置、法线和UV数据总共24个属性远低于300个顶点和900个顶点属性的上限。然而自动生成的球体包含515个顶点因此总共有1545个顶点属性明显超过300个顶点和900个顶点属性的限制所以不能动态批处理。
如果单击Frame Debuger中的一个Draw Call选项就会显示标签为Why this draw call cant be batched with previous one的部分。大多数情况下下方的解释文本说明了哪个条件没有被满足至少是它检测到的首个条件以及调试批处理行为的有用方法有什么。
4.2网格缩放
文档清楚地建议使用负数缩放会对动态批处理产生奇怪的效果。负数缩放通常是镜像场景中网格的快速方式可以避免创建和导入完全不同的网格来生成仅沿着某个轴翻转的对象。这个技巧通常用于创建一对门或只是为了使场景看起来不同。然而如果与没有缩放或对两个轴进行负数缩放的网格相比只对1个轴或3个轴进行负数缩放的网格会放到一个不同的动态批处理中。这与3个值xyz中哪个是负数无关仅和负数值的数量是奇数或偶数有关。
在后台批处理分离行为的另一个奇怪的副产品是对象的渲染顺序可以决定什么网格能进行批处理。如果先前的对象出现在与当前对象不同的批处理组中则无法对其进行批处理。同样最好举例说明。再次假设5个对象V以111缩放W以-111缩放X以-1-11缩放Y以-1-1-1缩放Z和V均以111缩放。对象V和Z使用相同的等比缩放因此它们会被批处理到一起。然而如果以上述顺序渲染所有对象到场景中那么V会被渲染接着Unity测试对象W和V是否可以批处理到一起。由于W有及数个附属缩放因此不能和V进行批处理。Unity接着比较X和W检查它们是否可以批处理到一起依然不行因为W有及数个附属缩放而X有偶数个。然后比较对象W-Y和Y-Z失败的原因都相同最终结果是5个对象用5个Draw Call渲染没有机会进行V和Z的批处理合并。注意只有使用负数缩放才会产生这个奇怪的效果。
据推测这是用于检测有效可批处理组的算法的唯一副产品由于在两个维度上镜像网格在数学上等价于网格绕相同的轴旋转180°而没有哪种旋转等价于网格沿着1个轴或3个轴进行镜像因此所观察到的行为可能只是动态批处理系统自动转换了对象尽管这并不完全清楚。无论如何希望这能为生成动态批处理时可能遇到的许多奇怪情况做好准备。
4.3动态批处理总结
渲染大量的简单网格时动态批处理是非常有用的工具。使用大量外观几乎相同的简单物体时该系统的设计是非常完美的。应用动态批处理的可能情况如下 到处都是石头和树木的森林有很多简单而常见的元素计算机、走廊、管道等的建筑、工厂或空间站一个游戏包含很多动态的非动画对象还包含简单的几何体和粒子特效如几何战争等游戏。 阻止两个对象动态批处理的唯一条件是它们使用了不同的纹理就应该花点时间和精力合并纹理通常称为图集并重新生成网格UV以便进行动态批处理。这可能会牺牲纹理的质量或者纹理文件会变大但这是值得的。
动态批处理可能对性能造成损害的唯一情况是设置一个场景其中有数百个简单对象而每个批处理中只有几个对象。在这种情况下检测和生成这么多小批处理组的开销成本可能比为每个网格单独执行Draw Call所节省的时间还要多。即便如此一般也不会发生这种情况。
简单地假设正在进行动态批处理则更有可能给应用程序带来性能损失而实际上我们忘记了其中一个必要条件。推送一个新的网格版本可以意外地突破定点限制在Unity将一个原始对象扩展名为.obj转换成它自己的内部格式的过程中生成的顶点属性比预期的要多。要突破定点限制还可以调整一些着色器代码或添加额外的过程但不会取消对象进行动态批处理的资格甚至可以设置对象来启用阴影或光线探测但这会破坏另一个条件。
当这些意外发生时并没有发出警告只是指出修改后Draw Call的数量在增加性能也进一步下降了。为了使场景中动态批处理的数量保持合适的水平需要连续不断地检查Draw Call的数量并观察Frame Debugger的数据以确保最新的修改不会意外取消对象的动态批处理资格。然而与往常一样如果证实这会造成性能瓶颈那么仅需关心Draw Call的性能。
总之每种情况都是各不相同的需要使用网格数据、材质和着色器进行实验以确定能动态批处理什么不能动态批处理什么并对场景不时地执行一些测试以确保使用数量合理的Draw Call。
五、静态批处理
Unity通过静态批处理提供了第二种批处理机制。静态批处理功能在几个方面类似于动态批处理例如对哪些对象进行批处理取决于运行时它对摄像机是否可见批处理的内容每帧都不同。然而静态批处理只处理标记为Static的对象因此命名为静态批处理。
静态批处理系统有自己的要求 网格必须标记为Static具体来说是Batching Static每个被静态批处理的网格都需要额外的内存合并到静态批处理中的顶点数量是有上限的并随着Graphics API和平台的不同而不同一般为32~64K个顶点网格实例可以来自任何网格数据源但它们必须使用相同的材质引用。 接下来细述这些要求
5.1Static标记
静态批处理只能应用于开启Static标记的对象具体而言是Batching Static子标记这些子标记称为StaticEditorFlags。单击GameObject的Static选项旁边的下三角按钮会出现一个StaticEditorFlags下拉列表框该框可以为不同的Static处理过程修改对象的行为。
Static标记的一个明显的副作用是不能修改对象的变换。因此任何想要使用静态批处理的对象都不能通过任何方式移动、旋转和缩放。
5.2内存需求
静态批处理的额外内存需求取决于批处理的网格中复制的次数。静态批处理在工作时将所有标记为Static的可见网格数据复制到一个更大的网格数据缓冲中并通过一个Draw Call传到管线渲染中同时忽略原始网格。如果所有进行静态批处理的网格都各不相同那么与正常渲染对象相比这不会增加内存使用量因为存储网格需要的内存空间量是相同的。
然而由于数据是高效复制过来的因此这些静态批处理的副本会消耗额外的内存其数量等于网格的数量乘以原始网格的大小。通常渲染1个、10个或100万个相同的对象消耗的内存是相同的因为它们都引用相同的网格数据。在这种情况下对象之间的唯一区别就是每个对象的变换。然而因为静态批处理需要把数据复制到一个大的缓冲区所以这个引用会丢失原因是原始网格的每个副本都会复制到缓冲区中每个副本都带着各不相同的数据集以及附着到顶点位置的硬编码变换。
因此使用静态批处理渲染1000个相同的树对象消耗的内存是不使用静态批处理渲染相同树的1000倍。如果没有正确地使用静态批处理将导致一些严重的内存消耗和性能问题。
5.3材质引用
如前所述共享材质引用时间少渲染状态变更的一种方式因此该要求显而易见。另外有时静态批处理需要更多材质的网格。在这种情况下所有网格会根据所使用的材质划分到各自的静态批处理组每个组使用不同的材质。
该要求的缺点是静态批处理渲染所有静态网格时使用的Draw Call数量最多只能等于所需的材质数量。
5.4静态批处理的警告
静态批处理有几个缺点。它实现批处理的方式是将网格合并到一个更大的网格中所以静态批处理系统有一些需要注意的警告。这些警告包括较小的不便和明显的缺点这取决于场景 Draw Call减少了但不能直接在Stats窗口中看到要在运行时才能看到在运行时向场景中引入标记为Batching Static的对象不能自动包含到静态批处理中 下面深入讨论这些问题
5.4.1静态批处理的Edit模式调试
试图确定静态批处理在场景中的整体效果有一些困难因为在Edit模式下静态批处理没有生效因此在手动测试之前难以确定静态批处理提供了什么优势。应该用Frame Debugger来验证静态批处理是否正确生成以及是否包含了预期的对象。
如果在项目后期才开始启用该特性可能会有问题因为此时需要花费大量时间启动、调整、重启场景以确保节省了期待节省的Draw Call。所以最好在构建新场景的早起开始进行静态批处理优化。
不言而喻静态批处理创建工作并不完全是琐碎的如果有许多批处理要创建或有许多大型对象要批处理那么场景初始化时间可能会显著增加。
5.4.2在运行时实例化静态网格
在运行时添加到场景中的任何新对象即使它们标记为Batching Static对象也不会由静态批处理系统自动合并到任何现有批处理中。自动合并会导致重新计算网格和与管线渲染同步时造成巨大的运行时开销所以Unity甚至不会尝试自动合并。
大多数情况下应该尝试让任何期望被静态批处理的网格出现在场景的原始文件中。然而如果需要动态实例化或者使用叠加方式加载场景就可以使用StaticBatchUtility.Combine()方法控制静态批处理。该工具方法有两个重载形式一个重载形式需要提供根GameObject该对象中所有带网格的子GameObject对象都会转换到新的静态批处理组中如果使用了多个材质就会创建多个组另一种重载形式需要提供GameObject列表和一个根GameObject该重载形式会自动将列表中的对象作为根对象的子节点以相同的方式生成新的静态批处理组。
应该分析一下StaticBatchUtility.Combine()的用法因为如果有许多顶点要合并那么该操作的开销将非常大。它也不会将给定的网格与任何预先存在的静态批处理组合并在一起即使它们使用相同的材质。因此无法通过实例化或叠加加载的静态网格来减少Draw Call这些静态网格使用的材质与场景中已经存在的其他静态批处理组相同它只能与在Combine调用中分组的网格合并。 提示如果调用StaticBatchUtility.Combine()方法进行批处理之前GameObject没有被标记为StaticGameObject就一直是非Static但网格自身是Static。这意味着GameObject、它的Colider组件和其他任何重要对象可能被意外移动但网格依然留在原处。对于在静态批处理的对象中意外混合Static和非Static状态要特别小心 5.5静态批处理总结
静态批处理是一种强大但危险的工具如果使用不当就很容易因为呢诶村小号和应用程序的渲染成本造成巨大的性能损失。它还需要大量的手动调整和配置以确保正确生成批处理不会由于使用各种Static标记而意外引发一些不期望的负面效果。它有一个显著的优势可以用于不同形状和巨大尺寸的网格这是动态批处理无法实现的。
