Draw Call Optimization in Games

Our video game development company runs independent projects, jointly creates games with the client and provides additional operational services. Expertise of our team allows us to cover all gaming platforms and develop an amazing product that matches the customer’s vision and players preferences.
Showing 1 of 1 servicesAll 242 services
Draw Call Optimization in Games
Complex
from 2 business days to 2 weeks
FAQ
Our competencies
What are the stages of Game Development?
Latest works
  • image_games_mortal_motors_495_0.webp
    Game development for Mortal Motors
    663
  • image_games_a_turnbased_strategy_game_set_in_a_fantasy_setting_with_fire_and_sword_603_0.webp
    A turn-based strategy game set in a fantasy setting, With Fire and Sword
    859
  • image_games_second_team_604_0.webp
    Game development for the company Second term
    490
  • image_games_phoenix_ii_606_0.webp
    3D animation - teaser for the game Phoenix 2.
    533

Draw Calls Optimization in Games

200 Draw Calls on mobile device when rendering UI through Canvas in Overlay mode—not rare. This is typical situation on project that was "just made" without batching strategy from start. By the time optimization begins, scene has 15 unique materials on UI elements, each Sprite renders separately, and GPU on iPhone 12 outputs 28 fps where should be 60.

Draw Call is CPU command to GPU: "render this mesh with this material". Each call carries CPU overhead (State Change, Command Buffer preparation). On mobile chips this overhead critical. On PC—less, but still counts.

Where Draw Calls Grow Uncontrolled

Most common source is Unity Canvas. Standard mistake: multiple Canvas elements with different materials in one Canvas Root. Each material change—new Draw Call. Solution: all UI sprites in one Sprite Atlas, one material for entire Canvas. Canvas Rebuild on element change redraws entire Canvas—split dynamic elements in child Canvas.

Skinning and animated characters. SkinnedMeshRenderer doesn't participate in standard Static Batching and poorly supports GPU Instancing in Unity (needs custom approach via Graphics.DrawMeshInstanced with pre-computed bone matrices). If scene has 50 identical NPCs—that's 50 separate Draw Calls by default.

Particle System with unique materials. Each Particle System with unique material—separate Draw Call, even if system has 2 particles. On mobile project saw 60 Draw Calls just from particles in one location.

Dynamic GI and real-time lighting. Each additional real-time light source in Forward Rendering increases Draw Calls proportional to number of objects in radius. 3 point-lights in room × 20 objects = 60 additional calls. Deferred Rendering solves this architecturally, but requires G-Buffer support.

Tools and Specific Reduction Techniques

SRP Batcher—first thing we enable in URP/HDRP projects. Doesn't reduce Draw Calls count, but drastically lowers CPU overhead through Constant Buffer layout unification. Requires all shaders to be SRP Batcher-compatible (check in Shader Inspector—should say "compatible"). If shader written for Built-in Pipeline and not rewritten—SRP Batcher doesn't apply to it.

GPU Instancing—for repeating meshes with one material. Enabled by checkbox in Material Inspector. Natively works only for identical meshes with identical materials. For different colors/parameters—MaterialPropertyBlock. Typical case: 200 trees of one type → 1 Draw Call instead of 200.

Static Batching—mark static objects as Static, Unity at build combines their meshes into one large VBO. Minus: increased memory consumption, as each batched mesh stored separately. On mobile projects with limited RAM—balance between Draw Calls and memory.

Dynamic Batching—for small meshes (less than 900 vertices). In URP enabled by default, but practically almost doesn't work for most game objects—too strict requirements for verts count and UV channels. Better not to rely on it as main tool.

Frame Debugger—main diagnostic tool. Open, start Play, press Enable. See each Draw Call with explanation why not batched ("different materials", "not in same layer", "different lightmap indices"). Here we understand real picture, not what Stats shows in Game View.

Real case: mobile Tower Defense, scene with 380 Draw Calls. Frame Debugger showed: 80 towers of one type—not instanced because each has unique LightProbe baked (because they were moved after lighting bake and not re-indexed). Light Probe Groups rebuild + GPU Instancing enable → 80 calls became 4. Overall scene result: 380 → 140 Draw Calls, fps on Samsung Galaxy S21 rose from 38 to 58.

How We Organize Work

First step—take metrics via Unity Profiler in Standalone mode (not Editor). Editor adds own calls and distorts picture. Connect device via USB, Deep Profile only if need precise attribution by scripts.

Analyze via Frame Debugger categories of Draw Calls: UI, Environment, Characters, VFX, Shadow Casters. For each category—own batching strategy.

Prepare change plan with impact estimate. Batching strategy change for UI takes 1–2 days. Character material architecture rework—week. GPU Instancing implementation for vegetation—2–3 days.

Task Scale Estimated Timeline
Audit + report with recommendations 2–3 days
UI layer optimization (Canvas batching) 3–5 days
Game scene optimization (environment + props) 1–3 weeks
Full Draw Call strategy rework project 4–8 weeks

Cost calculated individually after project audit.