A draw call is an instruction to render something. Issuing it is CPU work — setting state, binding buffers, binding textures — and that work happens whether the object is a triangle or a million.
Why it dominates
A scene with a thousand small objects issues a thousand calls. The GPU finishes each almost instantly and waits for the next. The CPU becomes the bottleneck and the GPU idles — which is why a "simple" scene can run worse than a visually complex one.
What causes a new call
- A different mesh
- A different material
- A different shader
- Certain state changes
The material boundary is the one artists control most directly, which is why material count matters so much more than it looks.
Reducing them
- Share materials. The single biggest lever. Two identical props with different materials cannot batch.
- [Atlas textures](/kb/game-development/texture-atlasing/) so sharing is possible.
- [Instance](/kb/game-engines/instancing-and-batching/) repeated meshes.
- Merge static geometry that never moves and shares a material.
- Cull aggressively. Objects outside the view or hidden behind others should never be submitted.
Where it hurts most
Mobile and VR. Mobile CPUs are weaker; VR renders the scene twice at high frame rates. Both make draw calls the first constraint rather than the third.
Measuring
Every engine reports draw calls per frame in its profiler, alongside batched and instanced counts. That comparison — submitted versus batched — tells you whether your batching is actually working, which is more useful than the raw number.
For generated assets
Every generated model is unique with its own material, which is the worst case for batching. Dressing a scene with forty individually generated props means forty meshes and forty materials. Generating a handful of variants and instancing them is the difference between a scene that runs and one that does not.