合并Drawcall的规则 是怎么样的?

这的确是一个可行的方案,相当于之前的 global z order,目前为了引擎核心层的简单干净,我们去除了这个概念,在渲染层重构的过程中,是有可能加入这个功能的。

嗯 因为我发现 按照现在架构, 在实际 应用上,在ui这一块 基本没有几个能合并 的drawcall

还是有很多的,可以邀请子龙大大来分享一下 1.4 的新成果 BMFont 和 UI 合并 @zilong

还是跟场景结构有关 很典型的 排版 一张图片 一个label 这两个节点挂 在一个你物件上,成为一个item 如果有隐藏显示的逻辑 肯定是直接隐藏父节点,如果为了合并drawcall而不得不把所有的item拆开来 图片放一起 label放一起,那么逻辑会非常混乱

你的文字只要是 bmfont 是可以合并的

我现在在尝试自己添加个Depth到CCNode的属性中 如何让这个属性在Cretor编辑器中显示出来?

目前自己改造了一版,大致思路就是 node可以设置为合并drawcall的父节点,其下的子节点RenderCommand 按照 depth 排序,同一个depth的 按照贴图调整顺序,这里同一贴图的保证还是按之前的场景树中的顺序。

@panda 借楼提两个问题
1、cocos2dx中对于drawcall的控制是否要达到unity中那么严格
其他的程序说在做UNITY项目的时候,drawcall是能省则省。但是我做cocos的项目时觉得文字稍微多占一些drawcall对于帧率并没有影响。
2、使用ugui的drawcall合并规则(如果两节点之间的其他节点与这两节点不重叠,则可尝试合并drawcall),这样的规则是否会提高性能,还是在判断矩形是否重叠时反而会让性能降低?

  1. drawcall 一定会对性能有影响,文字你觉得影响不大可能是因为填充率不高,所以占用的损耗不高,但损耗一定存在。
  2. ugui 那种合并 draw call 的策略在 creator 中目前还不支持

ugui 什么时候优化到这地步了?

谢谢回答。
关于第二个问题,ugui的drawcall合并思路,是否一定会提高性能?因为我想着 如果要判断的矩形过多,对于cpu来讲消耗也是比较大的。是否还需要配合例如“是否是静态ui”之类的判断,才能发挥出效果?

:smiley: 反正我试了最新版是这样的。

我在想的是不是可以吧labelttf,或者系统label预生成贴图,然后就可以跟bmFont一样合并了。。

有喔, Unity 5.2.4 UI 會看有沒有重疊來做batch
https://media.giphy.com/media/l0IygAIF5zgvQ67hm/giphy.gif

不错~~~~

贼TM先进,静态UI这个方法不错,但是我看到Creator的roadmap里有个多个节点合并成一张贴图的功能,不知道跟这个的区别。

那背包怎么处理???

官方是不是可以考虑出个方案优化一下drawcall合并了啊

NGUI制作背包等有大量物品图片的界面时候如何优化Drawcall? - 权然的回答 - 知乎
https://www.zhihu.com/question/26022356/answer/136778658

这位老哥的处理看起来比较靠谱

:laughing:了解了DrawCall之后如何帮助实践:
能实时查看每个节点的DrawCall的Creator节点树插件:
https://store.cocos.com/app/detail/2940


2赞