"Unity3d Game development" Ngui number of Drawcall (iv)

Read a lot of articles about Ngui Drawcall. One of the more views is that an Atlas corresponds to a drawcall.

But in fact Ngui has its own set of rules for Drawcall's handling.

The relevant rules are:

1.Atlas Atlas number about

The call order (drawing order) of the 2.Atlas Atlas is related to

3. Related to the number of UIPanel

One, reduce the number of Drawcall Ngui 3

Upgrade to NGUI3. The number of Drawcall grew from 5 to 88. Think it would not be a question of Ngui. Then I tidied it up a bit. There are two points found:
1) for the same atlas. The number of Drawcall depends on the number of panel (actually the number of UIPanel this script). For example, I have two sprites, and these two sprites belong to the same atlas. It is under different panel, however. At this time Drawcall number is 2, NGUI 2 is 1. The recommended use is to use only one panel.

2) for different Atlas, the sprite under the same panel. The display level can be adjusted by depth, which is exactly the opposite of Ngui 2, regardless of the z-value. There is also the depth value of the sprite of different Atlas try not to be interspersed back and forth. For example, two Sprite A and aa,depth in Atlas A have two sprite B and BB in 1,3;atlas B, respectively. The depth are 2, 4 respectively. The total number of Drawcall is 4 instead of 2.

(In Ngui 3, you can click on the panel and see the details of each Drawcall call in the Inspector panel)

Simply put, the number of Drawcall is not just about the number of Atlas. It also has to do with the sequence of the atlas call, preferably using only one panel at a time. The sprite depth of different Atlas is not interspersed as much as possible .

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

Second, NGUI reduce drawcall

Pre-description One:

The Drawcall definition in unity:

Each time the engine prepares the data and notifies the GPU that the process is called a draw call.

The process by which Unity (or the basic graphics engine) generates a frame can roughly simplify the descriptive narrative: the engine first passes a simple visibility test to determine what the camera can see. Then put the vertices of these objects (including local locations, normals, Uvs, etc.). (How vertices form a triangle), the transformation (that is, the position of the object, rotation, scaling, and camera position, etc.), the relevant light source. Texture. The rendering method (determined by the material/shader) is ready, and then notifies the graphic api--or simply as a notification that the gpu--is drawn, based on which the GPU, after a series of operations, draws thousands of triangles on the screen and finally forms an image.

Front Note two:

The display order of Uiwidget in Ngui:

The order in which each uiwidget is displayed is determined by the depth value. It doesn't matter with the z axis, and this depth value is made up of two parts, one is the depth of the uipanel that Uiwidget is in and the Uiwidget value of depth itself is weighted.

Moreover, the weight of the uipanel is very large. Can feel, uipanel depth big all uiwidget than UIPanel depth small all uiwidget than the last calculated depth must be big.

To give a sample example:

UIPanel1 depth x UIPanel2 depth y

UIWidget1 depth m UIWidget2 depth n

Just x > Y. So no matter the size of M and N, UIWidget1 final depth must be greater than UIWidget2.

Rules to reduce Drawcall:

1, the same uipanel under the texture and font as far as possible under the same altals.

Also expressed another meaning, use the same altals elements as far as possible under the same uipanel.

2, assume that a uipanel below use a plurality of altals, then try to make use of the same altals elements of continuous, as far as possible to avoid altals crossover.

The first half of rule 1 is well understood. In the latter part, the question of the order of the previous display can be known. Assume that the element using the same altals is below two different uipanel. This will inevitably lead to their drawcall separation.

So even if the depth is aligned, it cannot be combined into a single drawcall.

The meaning of rule 2, for example, is clear:

There are 4 uiwidget under the same uipanel. W1. W2,w3,w4.

Among them W1 and W2 quoted Altals1.

Among them W3 and W4 quoted Altals2.

Assume that their depth order is w1:1,w2:2,w3:3,w4:4.

Then the entire rendering requires 2 drawcall, because the rendering order is w1,w2,w3. W4.

W1 and W2 have a common altals, so they can be combined into a drawcall, and W3 and W4 can be merged into a single drawcall.

And assuming that their depth order is: W1:1. W2:3,w3:2,w4:4.

Then the entire rendering requires 4 drawcall. Because the rendering order is W1. W3,w2,w4.

Because W1 and W3 are not public one altals. So it can only be rendered separately.

Similarly W3 and W2. W2 and W4 can only be rendered separately.

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

Third, the source code Analysis Ngui Drawcall merger principle

Ngui to reduce the consumption of GPU State switching (for example, switching material), combine the same material widgets to reduce the number of drawcall. The following is a description of how Ngui classifies widgets. and reduce the drawcall need to pay attention to the place.

The code for the collation widget is in Fillalldrawcalls () in UIPanel. The code is as follows:

void Fillalldrawcalls () {for (int i = 0; i < drawcalls.size; ++i) Uidraw                Call.destroy (Drawcalls.buffer[i]);                Drawcalls.clear ();                Material mat = null;                Texture tex = null;                Shader SDR = null;                Uidrawcall DC = null;                if (msortwidgets) sortwidgets ();                        for (int i = 0; i < widgets.size; ++i) {Uiwidget w = widgets.buffer[i];  if (w.isvisible && w.hasvertices) {Material                                Mt = w.material;                                Texture tx = W.maintexture;                                Shader sd = W.shader; if (Mat! = MT | | Tex! = TX | | SDR! = SD) {if (Mvert                         S.size! = 0) {                       Submitdrawcall (DC);                                        DC = null;                                        } mat = MT;                                        Tex = TX;                                SDR = SD;                                        } if (mat! = NULL | | SDR! = NULL | | Tex! = NULL) {                                                if (DC = = null) {                                                DC = Uidrawcall.create (this, Mat, Tex, SDR);                                                Dc.depthstart = w.depth;                                                Dc.depthend = Dc.depthstart;                                        Dc.panel = this;                                          } else {      int rd = w.depth;                                                if (Rd < Dc.depthstart) Dc.depthstart = rd;                                        if (rd > Dc.depthend) dc.depthend = rd;                                        } w.drawcall = DC;                                        if (generatenormals) w.writetobuffers (Mverts, MUVs, Mcols, Mnorms, Mtans);                                else W.writetobuffers (Mverts, MUVs, mcols, NULL, NULL);                }} else W.drawcall = null;        } if (Mverts.size! = 0) Submitdrawcall (DC); }

Algorithmic descriptive narratives such as the following

First, the widgets in UIPanel are sorted by depth from small to large. Suppose depth is also sorted according to the material ID. Then iterate through each element. Classify material same widgets into the same drawcall. The results of the merge are, for example,

Finally, 3 Drawcall are generated and the GPU drawing is submitted sequentially.

Why should we use this algorithm? Since Ngui's material is a transparent material and will not be written to the depth cache (but will be tested in depth to ensure the correct level with non-transparent objects), we can see the colored of unlit/transparent shader used by Ngui material, There is a sentence zwrite Off. So the back-and-forth relationship of widgets is not related to Z-coordinates. Instead, it is related to the drawing order of Drawcall. So suppose you want to follow the depth to show the widget, it must only be divided into 3 drawcall. and plotted sequentially.

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

"Unity3d Game development" Ngui number of Drawcall (iv)