koobas.hobune.stream
Strategys for reducing draw calls
Greetings Folks,
I got a pretty huge problem with my number of draw calls.
I am about to creat a tactical round based roleplaying game and got therefore a "gameboard", that is based on gameobjects. At the moment it is a 12x12 field, 
The objects come with 4 childs, so I got only the outlines and can coler them seperatly. Basically, on of the fields countains 5 gameobjects and a gameboard contains 12x12 = 144 of theese objects.
I guess I don't have to mention that this leads to a huge amount of drawcalls. So I'm looking for some solutions to reduce them. I got the feeling that I would need to creat a model for each field, what would still lead to 144 (static) gameobjects...
A friend got the idea of creating a "plane" that can mark specific ways on the board. 
A marked area should be able to get one of this forms for example. If I could creat dynamically planes like this with code I could create the complete gameboard with one model, what would heavily reduce the number of drawcalls.
But till now I haven't found an option of creating planes that aren't just a rectangle.
Does anyone got a good idea how to reduce the amount of drawcalls while still giving me the ability to let the player see a grid and seperatly mark individual fields?
Thanks for any help!
I'm struggling to understand ... couldn't you just have one small tile
(or perhaps four, or 30, however many "types" of tile you want) ..
and just basically copy it out as many times as you want?
i think you mention you are "coloring" the tiles. note that when you change the color it creates a new material -- is this the "gotchya" that is causing you problems?
Thanks for the answers. You guys are rigt, I got basically one "field" with just like 10 different colors.
I need to be able to change its color with C# script. I saved the materials in some variables within the script. I thought Unity is using the same material then, but I guess thats where I am wrong. So basically I also should replace renderer.material by renderer.sharedmaterial
And can anyone explain me what this means? "If you have two identical materials which differ only in textures, you can combine those textures into a single big texture - a process often called texture atlasing. Once textures are in the same atlas, you can use single material ins$$anonymous$$d. "
I got some problems to understand this.
Again, thank you so far!
$$anonymous$$ just added an excellent answer, also. Again, you can use say 2DToolkit to completely automate this sort of thing.
eg, notice the important warning here
http://docs.unity3d.com/Documentation/Manual/DrawCallBatching.html
"If you need to access shared material properties from the scripts, then it is important to note that modifying Renderer.material will create a copy of the material. Instead, you should use Renderer.sharedMaterial to keep material shared."
Again - what you are doing sounds trivial and should cause you no problem. It's just a couple hundred flat simple objects, and it sounds like there's 10 or so varieties of those.
also -- as always, many if not most people doing this sort of thing just use 2DToolkit which makes it unbelievably easy and gives you single-draw-call performance
Reducing draw calls
Method 1 - Dynamic batching:
Unity has a per material batching system. It means, that every objects that share the same material are on the same draw call, and can be sent to the GPU at once.
This means, that for each material, you also get a draw call. To reduce this, you have to reduce the amount of materials.
The most common way of reducing materials is via Texture Atlases. Texture atlas is a big texture, that contains a lot of smaller textures of multiple objects. These objects then share the same material, but each object only uses a small part of it, this can be achieved with modifying it's UVs.
UVs tell the mesh what part of the texture should a polygon get. This is called UV Mapping. If you had a Quad, it's bottom-left corner would use the 0,0 part of the texture; the bottom-right 1,0; top-left 0,1; and top right 1,1.
Texture atlases and UVs can be generated in many ways, with 3rd party programs or even built-in Unity functions. If you want to know more about the PackTextures Unity function, you should check this forum thread.
Many modelling programs also have tools for creating texture atlases and modifying UVs of meshes.
Method 2 - Programming practices:
The most common programming practice that breaks batching is renderer.material and you should never use it, if you don't want to break batching. If you call renderer.material on a object that was previously batched, it breaks the batching. So if you want to manipulate the material, you should use renderer.sharedMaterial instead.
Method 3 - Static batching (Pro Only feature):
Static batching allows for better performance when batching, but it can only batch static objects, that are marked static.
A static object can't move, rotate or scale in game, so this should be only used for scenery or props and other static objects on the scene.
---David
A very usefull answer, thank you very much. I already made my objects static and the change to "renderer.shared$$anonymous$$aterial" brought no advantage iin reducing the drawcalls. But I'm going to check out the UVs ;) again, thank you very much!
If you use NGUI and You want to use NGUI Atlas on 3D meshes you can get Atlas3D plugin for NGUI. Check the video and tutoraial at: http://tracki.pl/atlas3d
If you use low poly meshes (not more than 300 vertices) you can get 1 drawcall with many dynamic meshes. Additionally script helps with converting Unity lightmapping and you still get 1 drawcall when using lightmapping on those dynamic meshes. Just like static batching on Unity Pro but you have dynamic meshes free to move and ready for occlusion.
