Static Batching May Not Reduce Your Draw Calls
Static batching will not always reduce your draw call count. But it will always do something else that is highly beneficial for your game
Practical articles on CPU, GPU, memory and engineering process optimization.
Static batching will not always reduce your draw call count. But it will always do something else that is highly beneficial for your game
High-performance collections can cut managed overhead, but only if you stop treating NativeList, Burst, safety checks, and allocators like magic. This module shows when native containers win, when they lose, and how to make the switch without fooling yourself.
Cannot have many real-time lights with Forward Shading in URP... can you? (obviously yes)
Forward+ in URP is not a magic switch. This module shows where classic Forward breaks at 8 real-time lights per object, when Forward+ starts to make sense, and why mobile memory bandwidth can still make deferred the wrong call.
No GDC, no Unity, but a 20-minute walk I can do
Runtime material fusing is what you do when batching dies because of material variants. Learn the vertex-attribute trick for colors/properties, the texture-atlas path for multiple textures, and the checks that prove you really recovered the batch win.
Well, that did not go quite as planned...
Runtime static batching is what you reach for when design adds procedural rooms, spawned props, or runtime layouts and your old fix stops applying. Learn when to use StaticBatchingUtility.Combine vs Mesh.CombineMeshes, and how to prove the draw-call win before you commit.
Curious how I get access to help out in AAA games?
Why devs don't know how static batching truly works in Unity
Static batching looks easy until it blows up your memory budget or silently fails. Learn when it helps, what Unity really builds under the hood, how Awake/Start can break it, and how to verify the result with Stats, Frame Debugger, and RenderDoc.
Let us see why late Z-Kills are so bad for your GPU