宝爷Debug小记——Cocos2d-x(3.13之前的版本)底层BUG导致Spine渲染花屏

最近在工作中碰到不少棘手的BUG,其中的一个是Spine骨骼的渲染花屏,在战斗中派发出大量士兵之后有概率出现花屏闪烁(如下图所示),这种莫名奇妙且难以重现的BUG最为蛋疼。


 
前段时间为了提高Spine骨骼动画的加载速度,将Spine库进行了升级,新的Spine库支持skel二进制格式,二进制格式的加载速度比json格式要快5倍以上。
 
这是一个大工程,游戏中所有的骨骼动画都需要使用更高版本的Spine编辑器重新导出,由于部分美术没有对源文件进行版本管理,丢失了源文件,导致部分骨骼动画要重新制作,浪费了不少时间。我们对代码进行了严格的版本管理,并且大受裨益,但美术的源文件管理确实很容易被忽视,所以在这里吃了一个大亏。升级版本之后,部分使用了翻转的骨骼出现了一些问题,需要美术逐个检查,重新设置翻转之后再导出。
 
使用了新版本的Spine库,除了二进制格式的支持外,渲染方面也进行了一个优化,使用TriangleCommand替换了原先的CustomCommand,这使得多个骨骼动画的渲染可以被合并,原来的版本每个骨骼至少占用一个drawcall。另外新Spine使用的顶点Shader也发生了变化,导致之前使用的旧Shader也需要跟着调整顶点Shader。
 
接下来,让我们开始Debug,首先排查一下骨骼动画的问题,同一个关卡,我让测试人员帮忙以很高的频率出兵,但是只出一种兵,看看花屏是不是某种兵的渲染导致的。结果是每种兵出到一定的数量之后都会出现这个问题,但是不同的兵种出问题的时间不同,其中的大树人兵种在派出了6个之后就会出现花屏的问题,而其他兵种则比较难出现。
 
那么大树的骨骼和其他几个骨骼有什么不同呢?询问美术人员之后,得知大树这个骨骼动画使用了较多的Mesh,也就是Spine中的网格功能,这个功能可以让2D的图片实现柔顺的扭曲效果,例如毛发、衣物的飘扬效果。
 
既然是Spine的网格出问题,那么是否因为Spine的版本问题导致?编辑器导出的版本与Spine运行库的版本不匹配导致的,根据文档让美术使用了3.3.07,3.5.35和3.5.51版本的Spine编辑器导出骨骼,并使用了3.5.35和3.5.51的运行库进行测试,都存在这个问题。
 
接下来我开始对比Spine的渲染代码,对比上一版本(升级前的Spine,也就是Cocos2d-x3.13.1之前的Spine库),上一版本使用的是自己的批渲染,而最新版本是TriangleCommand,尝试改回去,但代码和数据结构已经发生了较大的改动,强制改回去之后发现渲染效果更加糟糕了。
 
阅读了Spine的渲染代码之后,尝试跳过spine的网格渲染,我添加了一个测试用的静态变量,然后在运行中打断点,之后动态修改这个变量的值,来控制程序的运行流程,逐个跳过Spine的渲染类型,最后定位到只要把网格渲染跳掉,出再多的大树人也不会导致花屏。我想或许有些没有程序员精神的程序员到这里就会结案,然后通知美术人员去除所有网格,重新导出资源。但我决定认真分析下为什么这个网格渲染会导致花屏。
 1 static int skiptype = 0;
 2  
 3 void SkeletonRenderer::draw (Renderer* renderer, const Mat4& transform, uint32_t transformFlags) {
 4     SkeletonBatch* batch = SkeletonBatch::getInstance();
 5  
 6     for (auto t : _curTriangles)
 7     {
 8         TrianglesMgr::getInstance()->freeTriangles(t);
 9     }
10     _curTriangles.clear();
11     _triCmds.clear();
12  
13     Color3B nodeColor = getColor();
14     _skeleton->r = nodeColor.r / (float)255;
15     _skeleton->g = nodeColor.g / (float)255;
16     _skeleton->b = nodeColor.b / (float)255;
17     _skeleton->a = getDisplayedOpacity() / (float)255;
18  
19     Color4F color;
20     AttachmentVertices* attachmentVertices = nullptr;
21     for (int i = 0, n = _skeleton->slotsCount; i < n; ++i) {
22         spSlot* slot = _skeleton->drawOrder[i];
23         if (!slot->attachment) continue;
24         if (slot->attachment->type == skiptype) continue;
25  
26         switch (slot->attachment->type) {
27         case SP_ATTACHMENT_REGION: {
28             spRegionAttachment* attachment = (spRegionAttachment*)slot->attachment;
29             spRegionAttachment_computeWorldVertices(attachment, slot->bone, _worldVertices);
30             attachmentVertices = getAttachmentVertices(attachment);
31             color.r = attachment->r;
32             color.g = attachment->g;
33             color.b = attachment->b;
34             color.a = attachment->a;
35             break;
36         }
37         case SP_ATTACHMENT_MESH: {
38             spMeshAttachment* attachment = (spMeshAttachment*)slot->attachment;
39             spMeshAttachment_computeWorldVertices(attachment, slot, _worldVertices);
40             attachmentVertices = getAttachmentVertices(attachment);
41             color.r = attachment->r;
42             color.g = attachment->g;
43             color.b = attachment->b;
44             color.a = attachment->a;
45             break;
46         }
47         default:
两种渲染最后的处理都一样,不同的地方就在于上面这个switch中的顶点计算部分,阅读了一下旧版本Spine的Mesh顶点计算代码,再看看新的Mesh顶点计算,直接吐血,原本的几行代码,新版本使用了几百行代码,都是各种复杂的计算,可读性很糟糕...,尝试把旧的Mesh顶点计算代码应用到新的Spine,结果也是非常糟糕。
 
接下来我决定换一个简单点的环境来定位问题,这样可以排除其他的干扰!我修改了一下Cocos2d-x3.13版本的TestCpp中的SpineTest进行简单的测试,结果发现了一个有意思的现象,当我添加到第十二个树人时渲染出现了一些奇怪的现象(美术给我的是小树人,顶点较少,所以到第十二个才出问题)
  
再次检查了一下渲染的代码后突然注意到左下角的顶点数,当我添加第12个树人的时候,顶点数突破了65535!记得在Cocos2d-x底层渲染中,65535是VBO顶点缓存区的最大值,接下来把目标锁定在Cocos2d-x的渲染中。再次阅读了一下Render的代码,特别是TriangleCommand的渲染,调试了一下,发现渲染的顶点是2W多个,而Index索引是7W多个,难道是index的限制不能超过65535?于是把代码中的INDEX_VBO_SIZE替换为VBO_SIZE,这样一次渲染中Index和Vertex都不能超过65535,改完之后,问题果然解决了。那这就结案了吗?我觉得还得再深入探讨一下,把问题的根源彻底确定。
 1 void Renderer::processRenderCommand(RenderCommand* command)
 2 {
 3     auto commandType = command->getType();
 4     if( RenderCommand::Type::TRIANGLES_COMMAND == commandType)
 5     {
 6         // flush other queues
 7         flush3D();
 8  
 9         auto cmd = static_cast<TrianglesCommand*>(command);
10  
11         // flush own queue when buffer is full
12         if(_filledVertex + cmd->getVertexCount() > VBO_SIZE || _filledIndex + cmd->getIndexCount() > INDEX_VBO_SIZE)
13         {
14             CCASSERT(cmd->getVertexCount()>= 0 && cmd->getVertexCount() < VBO_SIZE, "VBO for vertex is not big enough, please break the data down or use customized render command");
15             CCASSERT(cmd->getIndexCount()>= 0 && cmd->getIndexCount() < INDEX_VBO_SIZE, "VBO for index is not big enough, please break the data down or use customized render command");
16             drawBatchedTriangles();
17         }
18  
19         // queue it
20         _queuedTriangleCommands.push_back(cmd);
21         _filledIndex += cmd->getIndexCount();
22         _filledVertex += cmd->getVertexCount();
23     }
24  
难道IndexCount真的不能超过65535吗?google查阅了不少资料,glGet获取GL_MAX_ELEMENTS_INDICES,发现其值是10W+,仔细阅读了OpenGL超级宝典关于缓存区部分的介绍,也没有说Index不能超过65535。Cocos2d-x底层的VBO也分配了足够的空间。难道是顶点或者索引错位了之类的问题导致的,于是我把动画停止,把所有的树人都限定在同一个位置,然后在Render的最底层,打印出每个树人渲染时的所有顶点和索引信息,然后对比一下只有一个树人、11个树人以及12个树人渲染的顶点和索引信息有何不同。
 
  1 // 增加一些调试用的静态变量
  2 static bool __dbg = false;
  3 static bool __deepDbg = false;
  4 static int __cmdCount = 68;
  5 static int __curCmdCount = 0;
  6 static int __idxCount = 0;
  7 static int __vexCount = 0;
  8 static int __maxidx = 0;
  9  
 10 void Renderer::fillVerticesAndIndices(const TrianglesCommand* cmd)
 11 {
 12     memcpy(&_verts[_filledVertex], cmd->getVertices(), sizeof(V3F_C4B_T2F) * cmd->getVertexCount());
 13  
 14     // fill vertex, and convert them to world coordinates
 15     const Mat4& modelView = cmd->getModelView();
 16     for(ssize_t i=0; i < cmd->getVertexCount(); ++i)
 17     {
 18         modelView.transformPoint(&(_verts[i + _filledVertex].vertices));
 19         // 打印所有顶点的xyz和纹理uv
 20         if(__dbg && __deepDbg)
 21         {
 22             CCLOG("vertex %d is xyz %.2f,%.2f,%.2f uv %.2f,%.2f", i + _filledVertex - __vexCount,_verts[i + _filledVertex].vertices.x,
 23                 _verts[i + _filledVertex].vertices.y, _verts[i + _filledVertex].vertices.z, 
 24                 _verts[i + _filledVertex].texCoords.u, _verts[i + _filledVertex].texCoords.v);
 25         }
 26     }
 27  
 28     // fill index
 29     const unsigned short* indices = cmd->getIndices();
 30     for(ssize_t i=0; i< cmd->getIndexCount(); ++i)
 31     {
 32         _indices[_filledIndex + i] = _filledVertex + indices[i];
 33         if (__dbg)
 34         {
 35             if (__maxidx < _indices[_filledIndex + i])
 36             {
 37                 __maxidx = _indices[_filledIndex + i];
 38             }
 39             if (__deepDbg)
 40             {
 41                 CCLOG("index %d is %d", _filledIndex + i - __idxCount, _indices[_filledIndex + i] - __vexCount);
 42             }
 43         }
 44     }
 45  
 46     _filledVertex += cmd->getVertexCount();
 47     _filledIndex += cmd->getIndexCount();
 48 }
 49  
 50 void Renderer::drawBatchedTriangles()
 51 {
 52     if(_queuedTriangleCommands.empty())
 53         return;
 54  
 55     CCGL_DEBUG_INSERT_EVENT_MARKER("RENDERER_BATCH_TRIANGLES");
 56  
 57     if (__dbg)
 58     {
 59         __vexCount = 0;
 60         __idxCount = 0;
 61         __curCmdCount = 0;
 62     }
 63  
 64     _filledVertex = 0;
 65     _filledIndex = 0;
 66  
 67     /************** 1: Setup up vertices/indices *************/
 68  
 69     _triBatchesToDraw[0].offset = 0;
 70     _triBatchesToDraw[0].indicesToDraw = 0;
 71     _triBatchesToDraw[0].cmd = nullptr;
 72  
 73     int batchesTotal = 0;
 74     int prevMaterialID = -1;
 75     bool firstCommand = true;
 76  
 77     for(auto it = std::begin(_queuedTriangleCommands); it != std::end(_queuedTriangleCommands); ++it)
 78     {
 79         const auto& cmd = *it;
 80         auto currentMaterialID = cmd->getMaterialID();
 81         const bool batchable = !cmd->isSkipBatching();
 82         if (__dbg)
 83         {
 84             if (__curCmdCount % __cmdCount == 0)
 85             {
 86                 CCLOG("begin %d =====================================", __curCmdCount / __cmdCount);
 87                 __vexCount = _filledVertex;
 88                 __idxCount = _filledIndex;
 89             }
 90             ++__curCmdCount;
 91         }
 92  
 93         fillVerticesAndIndices(cmd);
 94  
 95         // in the same batch ?
 96         if (batchable && (prevMaterialID == currentMaterialID || firstCommand))
 97         {
 98             CC_ASSERT(firstCommand || _triBatchesToDraw[batchesTotal].cmd->getMaterialID() == cmd->getMaterialID() && "argh... error in logic");
 99             _triBatchesToDraw[batchesTotal].indicesToDraw += cmd->getIndexCount();
100             _triBatchesToDraw[batchesTotal].cmd = cmd;
101         }
102         else
103         {
104             // is this the first one?
105             if (!firstCommand) {
106                 batchesTotal++;
107                 _triBatchesToDraw[batchesTotal].offset = _triBatchesToDraw[batchesTotal-1].offset + _triBatchesToDraw[batchesTotal-1].indicesToDraw;
108             }
109  
110             _triBatchesToDraw[batchesTotal].cmd = cmd;
111             _triBatchesToDraw[batchesTotal].indicesToDraw = (int) cmd->getIndexCount();
112  
113             // is this a single batch ? Prevent creating a batch group then
114             if (!batchable)
115                 currentMaterialID = -1;
116         }
117  
118         // capacity full ?
119         if (batchesTotal + 1 >= _triBatchesToDrawCapacity) {
120             _triBatchesToDrawCapacity *= 1.4;
121             _triBatchesToDraw = (TriBatchToDraw*) realloc(_triBatchesToDraw, sizeof(_triBatchesToDraw[0]) * _triBatchesToDrawCapacity);
122         }
123  
124         prevMaterialID = currentMaterialID;
125         firstCommand = false;
126     }
127     batchesTotal++;
128     if (__dbg)
129     {
130         CCLOG("MAX IDX %d", __maxidx);
131     }
132     __dbg = false;
133  
在添加第一个树人后,打断点,并将__dbg和__deepDbg开启,它会打印出本次渲染的树人详情,添加到第十一和第十二个的时候,再各打印一次,通过Beyond Compare对比结果,发现这些信息完全正确,每个树人的所有顶点和索引都是完全一样的,渲染的内容并没有被修改或发生错位。那正确的内容为什么渲染不出正确的结果呢?于是继续分析接下来的glDrawElements方法,在十二个树人渲染的时候,断点检查了一下该函数的所有参数,发现了第二个参数的值出现了问题!这个值表示要渲染的顶点索引数量,在只渲染一次的情况下, _triBatchesToDraw[i].indicesToDraw应该等同于_filledIndex才对,而断点看到的值却远小于_filledIndex,查找了一下indicesToDraw的所有引用,发现这个值在每合并一个Command的时候会加上该Command的IndexCount,而这个变量的类型是GLushort!结果终于真相大白,这个变量在不断增加的过程中溢出了,从而导致渲染的Index出现问题,最终导致的花屏。
1     for (int i=0; i<batchesTotal; ++i)
2     {
3         CC_ASSERT(_triBatchesToDraw[i].cmd && "Invalid batch");
4         _triBatchesToDraw[i].cmd->useMaterial();
5         glDrawElements(GL_TRIANGLES, (GLsizei) _triBatchesToDraw[i].indicesToDraw, GL_UNSIGNED_SHORT, (GLvoid*) (_triBatchesToDraw[i].offset*sizeof(_indices[0])) );
6         _drawnBatches++;
7         _drawnVertices += _triBatchesToDraw[i].indicesToDraw;
8     }
最终的改法应该是将indicesToDraw的类型修改为GLsizei,测试通过后,开开心心地打算提交一个pull request,结果却发现,在下一个版本3.14中,该BUG已被修复...,想想还是应该多升级一下引擎啊....
 
最后反思一下这个Bug,有些千奇百怪的Bug,处理到最后往往是那么一两行代码的事情,整个解决Bug的流程看上去虽然很绕,但实际上是先确定并重现我呢体,再从出问题的地方——Spine一点点排查,一直到最底层的渲染逻辑。如果是用逆向思维,可能一下子就定位到问题了,但一开始根本没怀疑Cocos2d-x的渲染有问题,因为Cocos2d-x的版本已经有段时间没有升级过了,而Spine则是最近升级的。
 
所以呢,就算不升级引擎,也应该多关心一下引擎的更新日志,了解修改了哪些BUG。除了程序的原因,美术过量使用了网格,也是这个BUG的一大诱因,过量使用网格,会导致Spine骨骼动画加载变慢,资源文件变大,并影响性能。
 
在分析Spine渲染代码的时候,发现一个可优化的点,就是每次添加一个渲染命令,都会重新分配一块内存用于存储顶点信息,为什么不直接使用传入的顶点信息指针呢?可能是因为后面对顶点进行了坐标转换,这样同一个顶点可能被转换多次,那么在这里使用一个简易的内存池也可以起到很好的优化作用。
 
posted @ 2017-05-07 12:36 深圳-宝爷 阅读(...) 评论(...) 编辑 收藏