NGUI 降低drawcall

前置说明一:

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也仅仅能分开渲染。

时间: 2024-11-06 18:38:28

NGUI 降低drawcall的相关文章

【Unity3D游戏开发】NGUI之DrawCall数量 (四)

看了非常多关于NGUI drawCall的文章.见得比較多的一个观点是:一个 Atlas 相应一个Drawcall. 但事实上NGUI内部有自己的一套对DrawCall的处理规则. 相关的规则有: 1.Atlas图集数量有关 2.Atlas图集的调用顺序(绘制顺序)有关 3.和UIPanel的数量有关 一.降低NGUI 3的DrawCall数量 升级到NGUI3. DrawCall数由5个增长到了十七八个.想想应该不会是NGUI的问题吧.后来整理了一下.发现有两点: 1)对于同一Atlas.Dr

NGUI 减少drawcall

前置说明一: Unity中的drawcall定义: 每次引擎准备数据并通知GPU的过程称为一次Draw Call. Unity(或者说基本所有图形引擎)生成一帧画面的处理过程大致可以这样简化描述:引擎首先经过简单的可见性测试,确定摄像机可以看到的物体,然后把这些物体的顶点(包括本地位置.法线.UV等),(顶点如何组成三角形),变换(就是物体的位置.旋转.缩放.以及摄像机位置等),相关光源,纹理,渲染方式(由材质/Shader决定)等数据准备好,然后通知图形API--或者就简单地看作是通知GPU-

【Unity NGUI游戏开发之四】NGUI的DrawCall数量

看了很多关于NGUI drawCall的文章,见得比较多的一个观点是:一个 Atlas 对应一个Drawcall. 但其实NGUI内部有自己的一套对DrawCall的处理规则.相关的规则有: 1.Atlas图集数量有关 2.Atlas图集的调用顺序(绘制顺序)有关 3.和UIPanel的数量有关 一.减少NGUI 3的DrawCall数量 升级到NGUI3, DrawCall数由5个增长到了十七八个,想想应该不会是NGUI的问题吧.后来整理了一下,发现有两点: 1)对于同一Atlas,DrawC

NGUI UI DrawCall 优化

首先要明确Unity中的drawcall定义: 每次引擎准备数据并通知GPU的过程称为一次Draw Call. Unity(或者说基本所有图形引擎)生成一帧画面的处理过程大致可以这样简化描述:引擎首先经过简单的可见性测试,确定摄像机可以看到的物体,然后把这些物体的顶点(包括本地位置.法线.UV等),(顶点如何组成三角形),变换(就是物体的位置.旋转.缩放.以及摄像机位置等),相关光源,纹理,渲染方式(由材质/Shader决定)等数据准备好,然后通知图形API——或者就简单地看作是通知GPU——开

NGUI 减少drawcall规则

前置说明一: Unity中的drawcall定义: 每次引擎准备数据并通知GPU的过程称为一次Draw Call. Unity(或者说基本所有图形引擎)生成一帧画面的处理过程大致可以这样简化描述:引擎首先经过简单的可见性测试,确定摄像机可以看到的物体,然后把这些物体的顶点(包括本地位置.法线.UV等),(顶点如何组成三角形),变换(就是物体的位置.旋转.缩放.以及摄像机位置等),相关光源,纹理,渲染方式(由材质/Shader决定)等数据准备好,然后通知图形API——或者就简单地看作是通知GPU—

NGUI优化之Drawcall

今天在运行之前的程序时,无意中发现一个简单的menu菜单页面drawcall居然达到接近30了,这个数值感觉太高了. 后网上查询关于降低drawcall的方法,发现主要有以下几点: 1.少用Panel: 2.少用Atlas: 3.尽量避免夹层(即不同材质的UISprite相互间层级夹杂,如L2,L4使用mat1,L1,L3使用mat2,这样就形成夹层现象): 分析了一下自己的实现,发现其实主要问题都是夹层引起的,因此重新设计了以下层的分布,并在开发过程中有意识的注意这个问题, 具体实现思路如下:

如何降低Unity程序的Drawcall

[如何降低Unity程序的Drawcall] Unity can combine a number of objects at runtime and draws them together with a single draw call. This operation is called “batching” 每帧能够有多少batch依赖于cpu.每个drawcall提交多少个三角形,对cpu压力变化不大,但是每帧有多少个drawcall则影响很明显. 一.Dynamic Batching.

NGUI之渲染DrawCall的合并

在Unity中,每次引擎准备数据并通知GPU的过程称为一次Draw Call.Draw Call值越低,会得到更好的渲染性能. (NGUI 查看DrawCall工具(NGUI-OPEN-Draw Call Tool)) Unity默认会按照控件的Depth来渲染.从后往前渲染,NGUI为了减少GPU状态切换的消耗(比如切换material),把相同material的widget合并,减少DrawCall的数量.如果和前一个材质不相同则会重新产生一个Draw Call. 如图:

NGUI中显示DrawCall详细信息

[NGUI显示DrawCall详细信息] UIDrawCall中有个宏,SHOW_HIDDEN_OBJECTS,默认为关闭状态.将此宏打开,NGUI即会将DrawCall对象显示在Hierarchy中.如下: 对象的命名规则如下: