javascript技巧

关注公众号 jb51net

关闭
首页 > 网络编程 > JavaScript > javascript技巧 > CocosCreator优化DrawCall

详解CocosCreator优化之DrawCall

作者:路飞的小迷弟

这篇文章主要介绍了CocosCreator中DrawCall的优化,想研究游戏性能的同学,一定要看一看

前言

在游戏开发中,DrawCall 作为一个非常重要的性能指标,直接影响游戏的整体性能表现。
无论是 Cocos Creator、Unity、Unreal 还是其他游戏引擎,只要说到游戏性能优化,DrawCall 都是绝对少不了的一项。
本文将会介绍什么是 DrawCall,为什么要减少 DrawCall 以及在 Cocos Creator 项目中如何减少 DrawCall 来提升游戏性能。

什么是 DrawCall

DrawCall就是CPU调用图形库(比如DirectX或OpenGL)的图形绘制接口,来命令GPU进行渲染的操作。

DrawCall 是如何影响性能的呢?

先举个栗子:
http形式从服务器拉取1024个大小1kb的文件和单个大小为1M的文件,哪个耗时更短?
答:肯定是拉取单个1M的更快。
原因就是每个请求之前,http 都需要做许多的准备工作来保证文件能够正常传输。而正是这些额外工作,造成了很多时间和性能开销。

而每一次绘制CPU都要调用DrawCall,而在调动DrawCall前,CPU还要进行很多准备工作:检测渲染状态、提交渲染所需要的数据、提交渲染所需要的状态。
而GPU本身具有很强大的计算能力,可以很快就处理完渲染任务。一般来说,绘制 100 个三角形和绘制 1000 个三角形所消耗的时间没差多少。
但是,当 DrawCall 过多,CPU就会很多额外开销用于准备工作,CPU本身负载,而这时GPU可能闲置了。

**也就是说,正是因为每次渲染前,CPU 都需要做一系列准备工作,而 CPU 的每一次内存显存读写、数据处理和渲染状态切换都会带来一定的性能和时间消耗,积少成多,而 GPU 大部分时间都在摸鱼。
所以才造成了我们认知中的,DrawCall 数量过多导致了卡顿 **

如何减少 DrawCall

如上所说,我们可以通过一次多给 CPU 分配点工作,让一次渲染的内容多一些,减少分配次数,来达到我们的目的。
话是这么说,可是我们应该怎么实际操作呢?往下看

针对图片资源

静态合图

就是讲碎图整合成一张大图,即我们常说的 打图集。
但是图集也不是随便打的,并不是一张大图容纳越多的碎图越好。这里面也是有一定的门道的。

尽量将处于同一界面(UI)下的相邻且渲染状态相同的碎图打包成图集

对于Creator来说,在游戏运行时引擎是按照节点层级顺序从上往下由浅到深进行渲染的,理论上 每渲染一张图像(文本最终也是图像)都需要一次 DrawCall。
渲染状态是指:纹理状态(预乘、循环模式和过滤模式)或 Material(材质)、Blend(混合模式)等等,所以使用自定义 Shader 也会打断合批

所以 相邻且渲染状态相同 是关键点。
tip: 不建议任何图片资源的尺寸超过2048*2048,否则可能会出现加载相关的问题。

下面介绍2种打图集的方式

自动图集资源(Auto Atlas)

利用 Cocos Creator 内置的自动图集资源来将碎图打包成图集。
在项目构建时,编辑器会将所有自动图集资源所在文件夹下的所有符合要求的图像分别根据配置打包成一个或多个图集。
自动图集资源使用起来很灵活,编辑器在打包图集时会自动递归子目录,若子目录下也有自动图集资源(即 .pac 文件)则会跳过该目录,所以我们可以对同一目录下的不同部分的碎图配置不同的参数。

关于自动图集的几点建议

合理控制图集最大尺寸,避免单个图像加载时间过长。尺寸太大的图像没有必要打进图集(如背景图)。善用九宫格(Sliced)可以节省很多空间(这一点需要美术大佬配合)。间距保持默认的 2 并保持勾选扩边选项,避免图像裁剪错误和出现黑边的情况。勾选不包含未被引用资源选项,自动排除没有用到的图像以节省空间(该选项预览时无效)。开发时预览图集,根据结果进行调整,以达到最好的优化效果。

TexturePacker

使用 TexturePacker 打包图集时需要注意配置「形状填充(Shape Padding,对应 Auto Atlas 中的间距)」,避免某张图像出现相邻图像的像素的情况。

对比一下

Auto Atlas

TexturePacker

Creator 官方说明:

Cocos Creator 提供了在项目构建时的静态合图方法 —— 「自动合图」(Auto Atlas)。但是当项目日益壮大的时候贴图会变得非常多,很难将贴图打包到一张大贴图中,这时静态合图就比较难以满足降低 DrawCall 的需求。
所以 Cocos Creator 在 v2.0 中加入了 「动态合图」(Dynamic Atlas)的功能,它能在项目运行时动态的将贴图合并到一张大贴图中。当渲染一张贴图的时候,动态合图系统会自动检测这张贴图是否已经被合并到了图集(图片集合)中,如果没有,并且此贴图又符合动态合图的条件,就会将此贴图合并到图集中。
动态合图官方文档:
https://docs.cocos.com/creator/manual/zh/advanced-topics/dynamic-atlas.html

动态图集有2个限制:

tips: 启用动态合图会增大内存消耗,不同平台占用内存不一致。小游戏和原生平台默认禁止动态合图。可以通过 api 自行开启:cc.macro.CLEANUP_IMAGE_CACHE = false; cc.dynamicAtlasManager.enabled = true;
还需要保证纹理的 Premulyiply Alpha(预乘)、Wrap Mode(循环模式) 和 Filter Mode(过滤模式) 等信息与动态图集一致才能够动态合批。

另外,静态图集也能参与动态合图,只要满足动态合图的要求即可。
tip1: 自动图集资源(Auto Atlas)需要在其属性检查器面板中开启 Texture 栏下的 Packable 选项,该选项默认是禁用的
tip2: 精灵(Sprite)也是需要开启 Packable 选项才能动态合图。该选项默认是开启的
tip3: 如果要使用了 shader ,那么需要禁用该精灵的 Packable 选项。

针对 Label

位图字体(BMFont)

在 Creator 中使用系统字体或 TTF 字体的 Label 会打断渲染合批,特别是 Label 和 Sprite 层叠交错的情况,每一个 Label 都会打断合批增加一个 DrawCall。

因此建议使用 BMFont 来代替 TTF 或系统字体,并且将 BMFont 与 UI 碎图打包到同一图集中(或「开启动态合图」),可以免除大部分文本导致的 DrawCall增加。

文本缓存模式(Cache Mode)

Creator 2.0.9 版本在 Label 组件上增加了 Cache Mode 选项,来解决系统字体和 TTF 字体带来的性能问题。
CacheMode有三种选项:

总结:对于大量频繁更改的文本,使用 CHAR 模式带来的性能提升是非常明显的。
同时 CHAR 模式的局限也很明显,一般用于场景中出现大量数字文本,类似于经验值增加、血量减少之类的特效的情况

必经之路–调整UI层级顺序

原则:

分离图像节点和文本节点文本使用 BMFont 或 Cache Mode 选项,尽量出现避免文本打断渲染合批的情况FBI WARNING: 一个 Mask 组件及其控制的渲染节点,需要至少三次 Draw call。第一次开启模板测试并调用一次 Draw call,刷新模板缓冲。第二次绘制对需要通过模板测试的区域进行设置。第三次再进行实际的子节点内容绘制,绘制结束再关闭模板测试。因此 使用 Mask 组件就无法与其他相邻节点进行批次处理 ,但是 Mask 组件内部的连续节点在满足合并规则的情况下还是会进行合批。

总结

改变渲染状态会打断渲染合批,例如改变纹理状态(预乘、循环模式和过滤模式)或改变 Material(材质)、Blend(混合模式)等等,所以使用自定义 Shader 也会打断合批。图集默认不参与动态合图,手动开启自动图集资源的 Packable 选项后如果最终图集符合动态合图要求也可以参与动态合图。纹理开启 Packable 选项参与动态合图后无法使用自定义 Shader,因为动态合图会修改原始贴图的 UV 坐标。使用 Cache Mode 的 BITMAP 模式需要注意内存情况,CHAR 模式需要注意文本内容不宜过多。在 ***Cocos Creator 2.0.7 之前的版本***中,改变节点的颜色或透明度、Sprite 组件使用九宫格(Sliced)都会打断渲染合批

以上就是详解CocosCreator优化之DrawCall的详细内容,更多关于CocosCreator优化DrawCall的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文