NGUI中的DrawCalls数量

原文地址:http://www.cnblogs.com/wonderKK/p/3918636.html


看了很多关于NGUI drawCall的文章,见得比较多的一个观点是:一个 Atlas 对应一个Drawcall。

好奇心下做了个demo,两个panel中只用到一个Atlas,却产生了10个drawCall,百思不得其解。寻觅已久终于找到三篇文章:

 

一、[NGUI]减少NGUI 3的DrawCall数量

http://game.ceeger.com/forum/read.php?tid=14653

 

刚升级到NGUI3, 这下不打紧,DrawCall数由5个增长到了十七八个,想想应该不会是NGUI的问题吧。后来整理了一下,发现有两点: 
        1)对于同一Atlas,DrawCall数取决于Panel的数量(实际上是UIPanel这个脚本的数量)。比如说,我有两个Sprite,这两个Sprite属于同一Atlas,但是位于不同的Panel下,这时候DrawCall 数是2, NGUI 2中则是1。使用建议就是只使用一个Panel。 
        2)对于不同Atlas,同一Panel下的Sprite,可通过Depth调节显示层级,Z值不管用,这点跟NGUI 2中刚好相反。还有就是不同Atlas的Sprite 的Depth值尽量不要来回穿插。比如Atlas A中有两个Sprite a 和 aa,Depth分别为1,3;Atlas B中有两个Sprite b 和 bb, Depth分别为2,4, 则DrawCall 总数为4而不是2。(在NGUI 3中,你可以点击Panel ,在Inspector面板中看到每一个DrawCall的调用细节 ) 


        简单的说就是DrawCall的数量不只跟Atlas的数量有关,还跟Atlas调用顺序有关,使用的时候最好只用一个Panel, 不同Atlas的Sprite Depth尽量不穿插。

 

二、NGUI 减少drawcall

http://blog.csdn.net/monzart7an/article/details/25212561



前置说明一:

Unity中的drawcall定义:

每次引擎准备数据并通知GPU的过程称为一次Draw Call。

Unity(或者说基本所有图形引擎)生成一帧画面的处理过程大致可以这样简化描述:引擎首先经过简单的可见性测试,确定摄像机可以看到的物体,然后把这些物体的顶点(包括本地位置、法线、UV等),(顶点如何组成三角形),变换(就是物体的位置、旋转、缩放、以及摄像机位置等),相关光源,纹理,渲染方式(由材质/Shader决定)等数据准备好,然后通知图形API——或者就简单地看作是通知GPU——开始绘制,GPU基于这些数据,经过一系列运算,在屏幕上画出成千上万的三角形,最终构成一幅图像。

 

前置说明二:

NGUI中的UIWidget的显示顺序:

每一个UIWidget的显示顺序由depth值决定,跟z轴没关系,而这个depth值是由两部分组成的,一个是UIWidget所在的UIPanel的depth和UIwidget自身的depth值进行加权计算。

并且,UIPanel的权重非常大,可以认为,UIPanel的depth大的所有UIWidget比UIPanel的depth小的所有UIWidget比最后计算的depth一定大。举个例子:

 

UIPanel1    depth  x                      UIPanel2    depth  y

UIWidget1  depth  m                      UIWidget2  depth  n

 

只要 x > y,那么不管m和n的大小,UIWidget1最后的depth一定大于UIWidget2。

 

 

减少drawcall的规则:

1、同一个UIPanel下的texture和font尽量放在同一个altals下。也表达了另外一个意思,使用同一个altals的元素尽量放在同一个UIPanel下面。

2、如果一个UIPanel下面使用了多个altals,那么尽量让使用相同altals的元素连续,尽量避免altals交叉。

 

规则1的前半部分好理解。后半部分,参照前面显示顺序问题可以知道。如果使用同一个altals的元素在两个不同的UIPanel下面,这就必然导致它们的drawcall分离。所以即使调整它们的depth一致,也无法合并成一个drawcall.

 

规则2的意思,举个例子就明白了:

同一个UIPanel下有4个UIWidget,w1,w2,w3,w4。

其中 W1和W2引用altals1。

其中 W3和W4引用altals2。

 

如果它们的depth顺序为  w1 : 1,w2 :2,w3 : 3,w4 : 4。

那么整个渲染需要2个drawcall,因为渲染顺序为 w1,w2,w3,w4。

而w1和w2公用一个altals,所以可以合并成一个drawcall,同理w3和w4可以合并成一个drawcall。

 

而如果它们的depth顺序为: w1 : 1,w2 :3,w3 : 2,w4 : 4。

那么整个渲染需要4个drawcall,因为渲染顺序为 w1,w3,w2,w4。

因为w1和w3不是公用一个altals,所以只能分开渲染。同理w3和w2,w2和w4也只能分开渲染。

 

 

三、源码分析NGUI的DrawCall合并原理

http://bbs.9ria.com/thread-282804-1-1.html

 

楼主自学Unity不久,有纰漏的地方请大神指正。正文如下:

NGUI为了减少GPU状态切换的消耗(比如切换material),把相同material的widget合并,减少DrawCall的数量。下文描述了NGUI如何对widget归类,以及减少DrawCall需要注意的地方。

归类widget的代码在UIPanel中的FillAllDrawCalls()里,代码如下

  1. void FillAllDrawCalls ()
  2.         {
  3.                 for (int i = 0; i < drawCalls.size; ++i)
  4.                         UIDrawCall.Destroy(drawCalls.buffer[i]);
  5.                 drawCalls.Clear();
  6.                 Material mat = null;
  7.                 Texture tex = null;
  8.                 Shader sdr = null;
  9.                 UIDrawCall dc = null;
  10.                 if (mSortWidgets) SortWidgets();
  11.                 for (int i = 0; i < widgets.size; ++i)
  12.                 {
  13.                         UIWidget w = widgets.buffer[i];
  14.                         if (w.isVisible && w.hasVertices)
  15.                         {
  16.                                 Material mt = w.material;
  17.                                 Texture tx = w.mainTexture;
  18.                                 Shader sd = w.shader;
  19.                                 if (mat != mt || tex != tx || sdr != sd)
  20.                                 {
  21.                                         if (mVerts.size != 0)
  22.                                         {
  23.                                                 SubmitDrawCall(dc);
  24.                                                 dc = null;
  25.                                         }
  26.                                         mat = mt;
  27.                                         tex = tx;
  28.                                         sdr = sd;
  29.                                 }
  30.                                 if (mat != null || sdr != null || tex != null)
  31.                                 {
  32.                                         if (dc == null)
  33.                                         {
  34.                                                 dc = UIDrawCall.Create(this, mat, tex, sdr);
  35.                                                 dc.depthStart = w.depth;
  36.                                                 dc.depthEnd = dc.depthStart;
  37.                                                 dc.panel = this;
  38.                                         }
  39.                                         else
  40.                                         {
  41.                                                 int rd = w.depth;
  42.                                                 if (rd < dc.depthStart) dc.depthStart = rd;
  43.                                                 if (rd > dc.depthEnd) dc.depthEnd = rd;
  44.                                         }
  45.                                         w.drawCall = dc;
  46.                                         if (generateNormals) w.WriteToBuffers(mVerts, mUvs, mCols, mNorms, mTans);
  47.                                         else w.WriteToBuffers(mVerts, mUvs, mCols, null, null);
  48.                                 }
  49.                         }
  50.                         else w.drawCall = null;
  51.                 }
  52.                 if (mVerts.size != 0) SubmitDrawCall(dc);
  53.         }
复制代码

算法描述如下

先把UIPanel中的Widget按depth从小到大排序,如果depth相同那按照material的ID来排序。然后遍历每个元素,把material相同的Widget归类到同一个drawCall。合并之后的结果如下图

 

 

最后生成了3个DrawCall,并按顺序提交GPU绘制。

为何要采用这个算法呢?因为NGUI的Material是透明材质,不会写入深度缓存(但是会进行深度测试,以保证与非透明物体的层次正确),我们可以看NGUI材质所使用的Unlit/Transparent Colored这个Shader,里面有一句ZWrite Off。所以widget的前后关系与z坐标是没有关系的,而是与DrawCall的绘制顺序有关。所以如果要按照上图的depth来显示widget,必然只能分成3个DrawCall,并且按顺序绘制。

 

 

其实合并drawCall的过程,正式游戏引擎“渲染队列”的职责:

  简要分析Ogre的渲染队列实现原理

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值