From time to time, I’ve been trying to optimize the rendering of Academia. I’ve employed many techniques (here , here , and here) to promote dynamic batching already and it seems like they’re not enough. My hypothesis is that dynamic batching hogs the CPU when there are more objects to batch (like around 10k to 15k saved by batching). It’s time to look else where.
So I took a closer look on static batching. Static batching, as I’ve read, is faster than dynamic batching, but at the cost of more memory. We’re still below our memory budget so static batching is worth a try. It is also quite smart. I tried a simple scene that was statically batched, then I deactivated an object. The object became invisible, of course, but I was genuinely impressed. I thought the engine would create a new bigger mesh from all the combined mesh. As such, you can no longer update this big mesh. I’m glad I was wrong since this implies that I don’t have to code something like remembering the vertices of the object and update the UVs when an object becomes deactivated. I don’t have to change the existing game logic at all.
Static batching was already ticked in the Player Settings since ever, but when I run the frame debugger, I don’t see any static batching at all. Majority of the objects in the game were already set to static. I’ve been using Unity since 2011 and there are still stuff that I don’t fully understand. I’ve discovered that static batching does not work on dynamically loaded objects, which is how our game runs. It only works for objects that were baked in the scene and was set to static. For dynamically loaded objects, you have to manually call StaticBatchingUtility.Combine().
When I implemented the manager that will call StaticBatchingUtility.Combine() strategically, the first issue I encountered was that you can’t update the UVs of the combined mesh. This means that if an object has UV manipulation like sprite animations, it cannot be added to the meshes to be combined. The engine throws an error if you manipulate the UV of a combined object. I had to filter out which objects can be combined. I used the StaticBatchingUtility.Combine() method which accepts an array of GameObjects to be combined.
When I finished the static batching manager class, I thought everything will just work. When I run the game, still zero static batches. This brought me a lot of more trial and error and more headache that I almost gave up. When I was about to shut down, I read the documentation again and it said “The GameObject in
gos must have MeshFilter components attached for this to work.” It was such a eureka moment. I usually prepare my game elements where the meshes or sprites are child GameObjects. I was combining the parent objects instead of the child objects that contains the MeshFilter. Don’t make this mistake.
In the end, I got to finally make it work. It saved me 1-2ms of rendering time. It’s not much but it proved that it is indeed faster. I’ve only implemented it in just one part of the game. There are still other parts where I could apply it.
That’s it for now. If you have unique rendering optimization techniques, please do share them.