I have a quick question regarding draw calls… I read a post on the forum that says that if you have several meshes that use the same material and texture then they will all be drawn in the same draw call if you run the “Combine Children” script. To test this, I created an empty scene in which I placed three cubes in front of the camera. Each cube added two draw calls for a total of 6. I then applied the “Combine Children” script and ran the scene to discover that it made no difference; the calls remained at 6. I’m obviously doing something wrong so would someone please be so kind as to point out my error? Also, why would a single cube require two draw calls (instead of one) and would anyone happen to know of an advanced article on optimizing for Unity?
You shouldn’t need to use the combine children script anymore. Unity will dynamically batch moving objects with under ~250 polys and will batch all your objects marked as static in the inspector that share a material.
You could be getting 2 draw calls per cube for several reasons, you could have a two pass shader that is rendering the object 2 times. If you are in Forward-Rendering Mode, then you could have a light shining on your objects causing them to be redrawn.
@PeterG : So the Combine Children script is obsolete now? Also, I do have a point light with my camera, but you need some light source to render so I’m confused how to achieve the 1 draw call nirvana.
@Tzan : I’ll try the parenting but I thought the Combine Children is obsolete now in Unity 3? see Peter G’s reply
If you create it dynamically you can do the batching on the fly actually, just make your management use 1 mesh per material and stream all into the same mesh buffers while keeping track of “virtual objects related to the data in there” (these virtual objects would store the own mesh, but not visibile and the start index in the triangles, uv and vertex arrays so you know what to alter if the object moves)
Its not really hard, but it requires that you have some basic knowledge on how 3D works at all.
I wouldn’t call it obsolete totally b/c you can still use it on Unity free, or dynamically combining objects at runtime, but most of the time static batching are better. By the way you actually don’t need a lightsource to render the scene. Either increase the ambient light or use a material that is self illuminating. And it takes one draw call to render the background, so with any objects in the scene, I don’t believe you can get under 2.
@Tzan, you missed the part about static batching. Objects marked static can have any number of tris and verts, and Unity will batch them with other objects that share the same material.
Yes, your characters probably aren’t under 250 tris, but for background scenery static batching works works great.
I did see the static batching stuff.
I also saw this line that I quoted in my last post.
"Static batching is only available in Unity iOS Advanced. "
Its near the bottom of that doc page.
If that is still true, I cant use it.
I know many people here do iPhone stuff but not me. I dont know what Diablo is working toward.
Perhaps it will be useful for him.
Dreamora: I do know what you mean, I may try that.
I am doing something similar now.
a C# class holding a Mesh and the game data that supports it, then putting those into a List of meshes and running CombineMeshes() on that. The result goes into a GO.
Your way cuts out the middle man it seems. Its hard to tell what really happens in CombineMeshes(), it might not be anything more than what I would end up doing by composing the final mesh myself.
Thats why I dont use it.
I have created a Quad Tree for a way of organizing my objects to prevent the vert count from getting to 65K in any given combine.
I set the limit to 30k, then it makes a new QuadTree level. On my machine 30k works fine, but as I test on others I may lower it.
How about finishing the game then profiling after to see where the bottlenecks actually are? I don’t mean to be rude but that is the process that works best overall.
I totally agree about the premature optimization thing, I do try to not do that. But sometimes you know there will be problems.
I have a procedurally created dynamic terrain. In a view there could be 6000 spaces that are from 4 to 100 verts.
Even if its 50 verts, thats 300,000 verts to be combined every frame. I havent tried to let the batcher do it since I wrote that code before we had it available. How long has dynamic batching been in, 3.0?
My landscape elements could be any size and there could be thousands of them so no real point in leaving that to chance.