- Home /
Question about Static Batching
I'm considering/thinking about the set-up work that needs to be done in max/maya in order to utilize static batching
I have 5 cartoony-looking trees, all sharing the same 3 materials: light green, dark green, and brown.
1 tree == 1 object (within 3ds max): all trees use these same 3 materials.
If I have all 5 unique trees sitting next to each other in Unity, will Static Batching "break apart" the 5 trees based on the materials they share, and recombine them (based on their materials) to assist performance? ie, so now instead of having 5 separate trees, I have 3 new meshes after Unity has done its static batching thing
I'm wondering if this is the case, because I could then duplicate those 5 tree's any number of times (let's say i now have 500 different tree objects, but they only use the original 3 materials) - static batching would then combine them into 3 meshes instead of 500 separate trees?
Is there any special work that should be considered while modeling in order to utilize static batching?
Thank you!
Answer by Hanoble · May 30, 2017 at 05:32 PM
The details you are looking for can be found here. There really is not much work on the modeling side when it comes to static batching, the important thing to remember is that these objects CANNOT move. It is best for things like buildings, world pieces, etc, and it works by combining those objects behind the scenes to reduce set pass calls, but does have a slight memory overhead.
As far as your question about the trees is concerned, static batching would take all of those trees and combine there geometry internally, but this is not something you see in the editor. It would not take your meshes and change the number from hundreds to one, but you would see the set pass calls be significantly reduced via the stat window. Depending on how many trees you have, the memory overhead could actually not be worth the FPS increase from the batching, but this is something you could certainly test yourself.
Dynamic batching you did not ask about, but it has limitations and requires more knowledge on the modeling side to take full advantage of (vert limits, multipass shaders, etc). All of this information can be found in the link provided earlier and I would highly suggest you spend some time reading up.
You can use the stats window in editor to actually see the batching information and the frame debugger is also a great tool if you want to really dig into exactly what is happening with your set pass calls and batching.
Hi Hanoble, thanks for the reply - I've read through the optimization link a few times, and I'm hoping to just get a solid understanding of some of it's aspects. For example, early in the docs it says
"Only GameObjects sharing the same $$anonymous$$aterial can be batched together. Therefore, if you want to achieve good batching, you should aim to share $$anonymous$$aterials among as many different GameObjects as possible."
I read this as "a sphere with "material A" on it and a cube with "material A" on it will be batched together"
what I'm wondering is:
"object A is made up of two pieces, one piece has material A and the other has material B; object B is made up of two pieces, one piece has material A and the other has material B..." will these 2 objects be batched?
as i read that question back I would guess no, the 2 objects would not be batched together, but i'm still unsure... for what it's worth (regarding memory overhead) this is a game being dev'd for mobile platforms
thanks again!
You need to think of those objects made up of other objects in terms of each one of those pieces is a single object, Object A is not a batching object, rather the two pieces with materials on them are the batching objects. In the scenario you gave, the parts of Object A with material A would batch with the parts of object B with material A, and the parts of object A with material B would batch with the parts of object B with material B. Parts of those 2 objects would batch with each other, and if you look into the frame debugger you would see what it is actually drawing on each set pass call and which parts of those objects are batched together.
Batching can be a bit confusing at first, but it is undoubtedly 100% worth it, especially when you are talking mobile. Getting familiar with those tools is the best advice I can give, along with checking the performance on your target platform. I have used batching to take games with thousands of objects and 5 fps to 60 fps with nothing more than static batching. For objects that need to move, dynamic batching has more restrictions, but is equally as important.
That clears it up and makes complete sense! I'll become familiar with the frame debugger - Thanks again, you've been very helpful!