Cocos2d-x Auto-batching 浅浅的”深入分析”

前端之家收集整理的这篇文章主要介绍了Cocos2d-x Auto-batching 浅浅的”深入分析”前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

转载自http://blog.csdn.net/musicvs/article/details/28226299


===========以下是回忆,是我对Auto-batching产生疑惑的过程,可以忽略不看=========


大家可以看看这个帖子:Cocos2d-x3.0 Auto-batching 三个小实验

对着这份文档看,以及调试源码,总算弄明白这个问题了。

简单地说,要绘制的精灵(应该说是Node)先存放到队列里,然后由专门的渲染逻辑来渲染。对于队列中的精灵,一个个取出来(其实存取的不是精灵,这里先简单这么理解),发现材质一样的话(相同纹理、相同混合函数、相同shader),就放到一个批次里,如果发现不同的材质,则开始绘制之前连续的那些精灵(都在一个批次里)。然后继续取,继续判断材质。

如果相同材质的精灵,中间间隔了不同材质的精灵,那也没法在同一个批次里渲染。

这就是那个问题的答案:为什么不连续创建的精灵(相同纹理、相同混合函数、相同shader)不能满足Auto-batching的要求,因为只要中间有不同材质的渲染对象,就会中断,会先把之前连续的相同材质的对象进行批渲染。

========================以上是回忆,回忆结束========================

渲染流程

现在,一个渲染流程是这样的:

(1)drawScene开始绘制场景

(2)遍历场景的子节点,调用visit函数,递归遍历子节点的子节点,以及子节点的子节点的子节点,以及…
(小若:够了!给我停!)

(3)对每一个子节点调用draw函数

(4)初始化QuadCommand对象,这就是渲染命令,会丢到渲染队列里

(5)丢完QuadCommand就完事了,接着就交给渲染逻辑处理了。

(7)是时候轮到渲染逻辑干活干活,遍历渲染命令队列,这时候会有一个变量,用来保存渲染命令里的材质ID,遍历过程中就拿当前渲染命令的材质ID和上一个的材质ID对比,如果发现是一样的,那就不进行渲染,保存一下所需的信息,继续下一个遍历。好,如果这时候发现当前材质ID和上一个材质ID不一样,那就开始渲染,这就算是一个渲染批次了。

看官方的一张图就完全明白了:


(8)因此,如果我们创建了10个材质相同的对象,但是中间夹杂了一个不同材质的对象,假设它们的渲染命令在队列里的顺序是这样的:2个A,3个A,1个B,1个A,2个A,2个A。那么前面5个相同材质的对象A会进行一次渲染,中间的一个不同材质对象B进行一次渲染,后面的5个相同材质的对象A又进行一次渲染。一共会进行三次批渲染。

(小若:突然发现,第6条哪去了啊?被你吃了吗)

这么一说,太含糊了,我们再来一次,用代码来罗列。

1.drawScene开始绘制场景

首先是开始,简单点,看代码

 
 
  1. voidDisplayLinkDirector::mainLoop()
  2. {
  3. if(_purgeDirectorInNextLoop)
  4. {
  5. _purgeDirectorInNextLoop=false;
  6. purgeDirector();
  7. }
  8. elseif(!_invalid)
  9. drawScene();
  10. // release the objects
  11. PoolManager::getInstance()->getCurrentPool()->clear();
  12. }

调用drawScene函数,开始绘制场景

2.遍历场景的子节点

接下来,drawScene函数里有一小段代码(我就不贴全部了,多吓人):

if(_runningScene) 
    
  • _runningScene->visit(_renderer,identity,false);
  • _eventDispatcher->dispatchEvent(_eventAfterVisit);
  • }
  • 没错,调用visit函数遍历场景的所有子节点(包括子节点的子节点,一直递归),然后做一些操作。

    3.对每一个子节点调用draw函数

    当然,我们最终关心的是,调用这些子节点的draw函数

    voidSprite::draw(Renderer*renderer,constkmMat4&transform,booltransformUpdated) 
        
  • // Don't do calculate the culling if the transform was not updated
  • _insideBounds=transformUpdated?isInsideBounds():_insideBounds;
  • if(_insideBounds)
  • _quadCommand.init(_globalZOrder,_texture->getName(),_shaderProgram,_blendFunc,&_quad,1,transform);
  • renderer->addCommand(&_quadCommand);
  • 我删掉了一些吓人的代码

    4.初始化QuadCommand对象,这就是渲染命令

    上面的代码就是重点了,初始化_quadCommand对象,这就是QuadCommand,渲染命令。

    其实渲染命令不仅仅只有QuadCommand,还有其他的,比如CustomCommand,自定义渲染命令,顾名思义,就是我们用户自己定制的命令,由于我没有使用过,就不介绍了。

    然后,接着就调用addCommand函数将渲染命令加入队列。

    这里有一点,也很重要,由于渲染命令有好几种,所以addCommand的时候,其实是会根据不同的命令类型把渲染命令添加到不同的队列。本文只想针对QuadCommand,所以就忽略这一点,假设我们的所有命令都是QuadCommand。

    5.丢完QuadCommand就完事了

    draw函数执行完,就轮到渲染逻辑干活了。

    6.开始渲染

    轮到渲染逻辑干活了,之前介绍了,渲染命令有好几种,如果我没有理解错误的话,只有QuadCommand才能参与自动批处理,因此,这里会对渲染命令进行筛选,发现是QuadCommand类型的命令就保存到一个队列里。如代码

    @H_127_403@if
    (commandType==RenderCommand::Type::QUAD_COMMAND)
  • {
  • autocmdstatic_cast<QuadCommand*>(command);
  • _batchedQuadCommands.push_back(cmd);
  • }
  • ==RenderCommand::Type::CUSTOM_COMMAND)
  • {}
  • ==RenderCommand::Type::BATCH_COMMAND)
  • ==RenderCommand::Type::GROUP_COMMAND)
  • else
  • {}
  • 为了避免大家睡着了,我把很多重要的代码删了,我们只要关注_batchedQuadCommands.push_back(cmd);。_batchedQuadCommands就是QuadCommand命令队列了。

    接着,调用drawBatchedQuads函数遍历QuadCommand命令队列:

    @H_127_403@for(constauto&cmd:_batchedQuadCommands)
  • if(_lastMaterialID!=cmd->getMaterialID())
  • {
  • //Draw quads
  • if(quadsToDraw>0)
  • {
  • glDrawElements(GL_TRIANGLES,(GLsizei)quadsToDraw*6,GL_UNSIGNED_SHORT,(GLvoid*)(startQuad*6*sizeof(_indices[0])));
  • _drawnBatches++;
  • _drawnVertices+=quadsToDraw*6;
  • startQuad+=quadsToDraw;
  • quadsToDraw=0;
  • }
  • //Use new material
  • cmd->useMaterial();
  • _lastMaterialID>getMaterialID();
  • }
  • quadsToDraw+>getQuadCount();
  • 又为了避免大家睡着了,我删了很多重要的代码(小若:我说,重要的代码随便删除真的好吗?)

    大家睁大耳朵鼻子什么的看看,_lastMaterialID是重点,当发现当前遍历的渲染命令的材质ID和_lastMaterialID不一样时,就会开始进行渲染,然后记录新的材质ID,继续遍历。

    这就是我们所说的,只有连续的相同材质ID的对象才会被放到同一个批次里进行渲染,如果不连续,那么材质ID再怎么相同也没有办法了。

    对了,_drawnBatches变量就是我们左下角经常看到的GLcalls的数字了~

    7.为什么必须要相同纹理、相同混合函数、相同shader?

    要满足Auto-batching,就必须有这三个条件,这是为什么呢?

    我们回到之前的代码,在调用节点的draw函数时,调用了QuadCommand的init函数

    _quadCommand.init(_globalZOrder,transform);
  • 这个init函数就是关键:

    voidQuadCommand::init(floatglobalOrder,GLuint textureID,GLProgram*shader,BlendFunc blendType,V3F_C4B_T2F_Quad*quad,ssize_t quadCount,constkmMat4&mv) 
        
  • _globalOrder=globalOrder;
  • _textureID=textureID;
  • _blendType=blendType;
  • _shader=shader;
  • _quadsCount=quadCount;
  • _quads=quad;
  • _mv=mv;
  • _dirtytrue;
  • generateMaterialID();
  • init函数里最后调用了generateMaterialID函数,这个函数就是关键。(小若:够了你,什么都是关键,关键个毛线啊)

    voidQuadCommand::generateMaterialID()
  • if(_dirty)
  • //Generate Material ID
  • //TODO fix blend id generation
  • intblendIDif(_blendType==BlendFunc::DISABLE)
  • blendID==BlendFunc::ALPHA_PREMULTIPLIED)
  • =1;
  • ==BlendFunc::ALPHA_NON_PREMULTIPLIED)
  • =2;
  • ==BlendFunc::ADDITIVE)
  • =3;
  • =4;
  • // convert program id,texture id and blend id into byte array
  • charbyteArray[12];
  • convertIntToByteArray(_shader->getProgram(),byteArray);
  • convertIntToByteArray(blendID,byteArray+4);
  • convertIntToByteArray(_textureID,byteArray+8);
  • _materialID=XXH32(byteArray,12,0);
  • _dirty 看到没?~我们的材质ID(_materialID)最终是要由shader(_shader->getProgram())、混合函数ID(blendID)、纹理ID(_textureID)组成的啊喂!所以这三样东西如果有谁不一样的话,那就无法生成相同的材质ID,也就无法在同一个批次里进行渲染了。

    _blendType就是我们的BlendFunc混合函数,注意一下,这里所说的相同的混合函数,并不是指要完全相同的值,
    其实只是相同类型,看看if else的那几个判断就知道了,最后需要的只是blendID这个值。
    
    

    当然,至于为什么要这样生成材质ID,我就没有去深究了,我只是个写游戏的,引擎底层,还是交给Cocos2d-x团队的人吧(邪恶)。

    8.怎样才能让相同材质的对象的渲染命令连续排列?

    不连续的渲染命令,即使材质ID相同也没有用,那,我们应该怎么让这些家伙连续起来呢?

    这个问题好办,还记得场景绘制的时候会遍历所有子节点吧?

    在遍历子节点之前,其实还偷偷做了一件事情,那就是,调用sortAllChildren();函数对子节点进行排序,对比的规则是:

    boolnodeComparisonLess(Node*n1,Node*n2)
  • return(n1->getLocalZOrder()<n2->getLocalZOrder()||
  • (n1-==n2->getLocalZOrder()&&n1->getOrderOfArrival()>getOrderOfArrival())
  • );
  • 好吧,我们不要管代码(小若:那你还贴个毛线啊,很吓人的好不好)

    总之,排序的规则是按照子节点的localZOrder和orderOfArrival进行的,orderOfArrival是用于localZOrder相同的情况下,进一步区分渲染顺序的(就是谁在上面谁在下面,额,请不要想歪)。

    那么,我们只要调整节点的zOrder就能改变节点的遍历顺序,于是,节点的QuadCommand添加顺序也就被改变了。

    但是,注意,但是来了,除了场景子节点会进行排序之外,在渲染逻辑里,渲染命令队列也会进行一次排序:

    voidRenderer::render() 
        
  • if(_glViewAssigned)
  • //1. Sort render commands based on ID
  • for(auto&renderqueue:_renderGroups)
  • renderqueue.sort();
  • 当然,我删了很多重要的代码renderqueue是RenderQueue对象,就是用于保存渲染命令的队列,它的sort函数是这样的:

    voidRenderQueue::sort()
  • // Don't sort _queue0,it already comes sorted
  • std::sort(std::begin(_queueNegZ),std::end(_queueNegZ),compareRenderCommand);
  • std::sort(std::begin(_queuePosZ),std::end(_queuePosZ),0); line-height:1.4em; margin:0px; padding:0px; border:0px currentcolor">}
  • boolcompareRenderCommand(RenderCommand*a,RenderCommand*b)
  • returna->getGlobalOrder()<b->getGlobalOrder();
  • }
  • 没错,渲染队列会根据节点的globalOrder再一次进行排序,默认的globalOrder当然是0了,也就是排不排序结果都一样。 这涉及到localZOrder和globalOrder的概念,这就帮star特做个广告吧,看看他的帖子: Cocos2dx 3.0 过渡篇(二十九)globalZOrder()与localZOrder()
    也可见“瑛峰”的博客http://blog.csdn.net/u012419410/article/details/44220449

    总之,结论就是,如果没有对节点的globalOrder进行设置,那就只需要调整节点的localZOrder,便可以实现对渲染命令的排序顺序进行控制。

    来看下面的代码,一开始贴过的:

    /* 创建很多很多个精灵 */ 
        
  • for(inti=0;i<14100;i++)
  • Sprite*xiaoruo=Sprite::create("sprite0.png");
  • xiaoruo->setPosition(Point(CCRANDOM_0_1()*480,120+CCRANDOM_0_1()*300));
  • this->addChild(xiaoruo);
  • xiaoruo"sprite1.png");
  • 这样创建的精灵肯定就没法连续了,因为sprite0.png的精灵和sprite1.png的精灵是不断间隔着创建的,没有连续。而且它们默认的localZOrder都是0,所以排序不起效。

    那么,稍微改改就好了,如下:

    @H_127_403@>
    addChild(xiaoruo,1);
  • 2);
  • 只是给精灵分别指定了localZOrder值,这样在排序的时候sprite0.png的精灵就会在一起,同样,sprite1.png的精灵也会在一起。

    运行结果,来一个很壮观的截图:

    渲染批次是5,等等!为什么是5?为什么不是2?

    9. 渲染队列存储上限

    继续回答刚刚的问题,图中的渲染批次是5,为什么是5?为什么不是2?

    首先,即使我一个精灵也不创建,渲染批次也至少是1。

    那么,我创建了两组材质ID相同的精灵,理论上GL calls应该是3,为什么是5?

    这个也很简单,因为渲染队列最大只存放10922个渲染命令,注意,是“只存放”而不是“只能存放”,这个只是在代码里做的限制。

    当渲染队列(指的是Render类的成员变量:std::vector<QuadCommand*> _batchedQuadCommands; ,之前有讲到)存放的渲染命令大于10922时,就会自动进行一次渲染操作,

    把队列里的渲染命令处理掉。

    因此,我创建了2组精灵,每组14100个,已经超过了10922的范围,所以,即使这2组精灵各自都是相同的材质,但也不得不被分成2次进行渲染,于是,这2组精灵共进行了4次渲染操作。

    加上GL calls默认就有1(为什么默认会有一次,我就没有去研究了),那么,就是5次了。

    话又说回来了,谁家的游戏那么夸张,要创建28200个精灵啊!这样那些跑分8000左右的手机怎么办啊,我在自己手机里试过了,帧率是60!没错,是60,已经太慢了无法正确计算了。因为每一帧的渲染消耗的时间是2秒多!

    一帧就消耗2秒多,太刺激了。

    嗯,跑题了。

    结束语

    好了,关于Auto-batching的探索之旅总算是结束了。

    我对OpenGL的东西还真不太懂,所以,有可能在研究代码的时候有一些东西被我忽略了,或者误解了,如果文章错误的地方,那…你来打我啊(别,开玩笑的)。

  • 猜你在找的Cocos2d-x相关文章