koobas.hobune.stream
Unity 2D Sprites cost many draw calls
Hi all,
I am creating a 2D puzzle game, where the player has a field of 40 * 40 squares, differently coloured.
The squares are individual Unity2D sprites, but all based of the same core block, coloured on the SpriteRenderer in code.
Since it's all from the same sprite, I thought it would be only 1 draw call. However, it takes 8 draw calls. When I make the grid smaller (5 * 5 squares) it does work with only one draw call. It seems as if there is a maximum number of squares / draw call, but I can not figure out why.
Another interesting observation was that changing my Mesh type from Tight to Full Rect actually reduced my draw calls a lot already, which to me also doesn't make sense.
Any thoughts? I'm lost.
Thank guys.
Cheers,
Ivo
I feel like I solved it, although it seems like a strange outcome.
https://docs.unity3d.com/Documentation/$$anonymous$$anual/DrawCallBatching.html
"Batching dynamic objects has certain overhead per vertex, so batching is applied only to meshes containing less than 900 vertex attributes in total."
Does this mean that for every 900 vertices I'll get another draw call?
It seems like it, but at the same time I can't believe this. Any help is appreciated.
No. This means that if you have complex objects they won't batch, even if they share a material. Say you have a 3D character mesh you wanted to use for an army of 500 enemies. And in the mesh, you have positions, vertex colors, and normals (i.e three types of vertex attributes). If the mesh has less than 300 vertex positions (300 x 3 = 900) then it is possible that all of your army characters might batch and be drawn in a single draw call. If you have more than 300 vertices, then each enemy would require its own drawcall drawcall (500 drawcalls ins$$anonymous$$d of one batched drawcall). Note I say 'possible' and 'might' because there are situations that come across the list that meet this criteria that for some magic reason don't batch. But usually...
Thanks roberto, that makes sense to me.
I found that the issue is somewhere in the 2D sprite-system of Unity. I don't know the why, but here's the results of some simple Sprite2D vs Quad tests.
Test 1 - Unity2D Sprites: Duplicating Unity2D sprites. After creating 341 sprites (= 682 vertices) , creating the 342nd sprite resulted in another draw call.
Test 2 - Quads: Duplicating Quads: After creating 5000 quads, still one draw call.
An advantage (for me at least) of creating Unity2D sprites, is that I can color them individually. I'll stick with that, since eventually it 'only' costs me a few extra draw calls.
If anyone can shed some light on the 'why' of this, that'd be great as well ;)
I don't know anything about how Unity handles sprites. Given the restrictions on what you can do with them, the are handled in some non-traditional way. But as for the coloring issue, you can change the color of individual Quads without breaking batching by using a Shader that supports Vertex colors and changes the colors in the colors array in the mesh (rather than use the material.color).
Is there a transparent background? See this video http://www.youtube.com/watch?v=L-HCiFWPeGo
If your sprite's texture is from same atlas; there should be one draw call
I recognised the same behaviour and also tested and found out about another anomaly when marking all sprites static. When you reached the point where the 2nd draw call appears and delete the last sprite, it's not going down to 1 draw call again. You actually have to delete 4 sprites to go back down. When adding up again, the 2nd draw call again appears after adding 4 sprites.
It's actually 682 tris and about 1.4k verts. But there is definitely a limit to batching when it comes to sprites.
