【基本解决】请教Cocos2dx3.0新渲染器合并draw call的规则&&多格table的性能优化

Cocos2d-x
#1

在cocos2dx的英文论坛写了一大段英文也没人回复T_T，转战中文论坛求教中。

以下问题用cocos2dx3.0 rc版本以及正式版都测试过~~~~

我们游戏有很多场景是一个大table里面有若干个组成复杂但是相互类似的格子（比如图鉴），为此我做了一个简单的测试，放了3个相同的item（复制粘贴出来的），每个item由6个不同贴图的sprite组成（我知道碎图合并可以减少draw call，此例只为测试，而且最后我们也无法合并到只用一张图），没有用batchnode，因为我理解新的renderer会自动把同样贴图同样深度的sprite合并drawcall的，最后应该只有6个draw call，可是测试下来发现一共有18个draw call，并没有发生合并。

然后我研究了一下render部分的代码，发现最后在绘制的时候会判断一下当前command和前一个command的material是否一致，一致则合并，但是我的command是1，2，3，4，5，6，1，2，3，4，5，6，1，2，3，4，5，6，所以全部都无法合并。我自己暴力的在排序的时候，对z=0的queue（18个command都在这）按照material排了下序，这样就能够得到想要的6个draw call的效果。

我的问题：

  1. 我的这种情况，期待6个draw call是正确的吗？
  2. 如果正确，那么是我哪里用法不对造成有18个draw call？
  3. 如果不正确，那么这个auto-batching是设计来优化什么样子的情形的？
  4. 像我说的这种情况，比如一页有16个item，有什么高效的做法吗？

求指点~~多谢。

#2

这样的期待应该是不正确的，auto-batching是用来处理类似 item1:1,2,3,4,5,6 和 item2：6,5,4,3,2,1
比如先draw item1 ，再draw item2 ，那么auto-batching 的draw call是11，会把两个6合并
如果用以前的batchnode，这块地方代码上显然不能把item1 和item2 batch在一起，所以draw call应该是12
auto-batching是把所有需要draw的list的里面的东西，能按顺序batch的都batch在一起
不过好像其实如果在3.0中使用了batchnode，结果会导致这个batchnode无法被再次auto-batching
所以当 batchnode1:1,1,1 和batchNode2:1,1,1,1
他们的draw call还是2，而不是1…这一点让我觉得有点无语…

#3

啊，可算有人理了，眼泪哗哗的，太感人了。

原来只会合并这么一点啊，那顶锅盖说感觉改进不是特别大啊。

#4

batch的主要效果体现在比较大量的sprite的时候，如果本身就只有一点点sprite，那么其实也没有什么特别提示效果

1赞
#5

那么像原问题里的这种每个item都比较复杂的table，怎么做比较高效呢？

#6

没有先后顺序的sprite draw，我觉得11，22，33，44，55，66是值得期待的，可以有个render的状态值开关，告诉这一批的随便排序

#7

因为之前是用unity+NGUI就可以这样合并，所以就这么期待了:2:

#8

因为unity主要是3d的，主要使用的jpg，所以可以这样合并
如果实在要做得稍微高效一点，而且不更改引擎的前提下，那么这样做：
item1 和 item2 只是名义上把它的元素包括起来，但是这些元素并不是直接add到item1 和 item2 上面
元素自己手动分层，比如所有1全部都添加到一个只添加1的节点上…
这样相当于自己把sprite的顺序理顺，这样引擎就可以batch在一起了

#9

嗯，这样就太麻烦了，我觉得还是要求设计改改比较快 :12:

unity主要使用的jpg所以可以这样合并是什么意思，没看懂呢？

#10

在3d中，一般jpg都有不同的z值，如果相同z值，那么就不知道谁在前面谁在后面了。
然后jpg绘制不需要考虑和其他的颜色叠加，因为没有透明度，只要覆盖就行了，而png则因为有透明度，需要和后面的颜色叠加，必须按顺序来

#11

哦，原来你指的透明度，明了 :14:

其实这是两个问题。你说的z排序以及透明图片只能按顺序来是关于深度剔除的，用来解决填充率带来的瓶颈。我说的同一个z上的相同material draw call可以合并，是关于draw call带来的瓶颈。

不过事实上你说的这个优化也是cocos2dx欠缺的，以前项目吃过亏，现在做设计的时候会注意一点。