What Are Draw Calls? Complete Beginner Guide to Game Optimization in Unity and Unreal Engine

You have spent months designing a stunning environment for your new game. The textures are high-resolution, the lighting looks realistic, and the assets are packed with detail. You hit "Play" in your engine, excited to walk through your creation, only to watch your frame rate plummet from a silky-smooth 60 frames per second (FPS) to a stuttering, unplayable 18 FPS. Confused, you check your polycount, but it is well within normal limits. So what is destroying your game’s performance?

The culprit is almost certainly draw calls.

In 3D real-time rendering, draw calls are one of the most critical, yet frequently misunderstood, performance bottlenecks. Many beginners focus solely on polygon counts, assuming that low-poly models guarantee a fast game. In reality, a scene containing a million triangles grouped into a single draw call will often render significantly faster than a scene with only ten thousand triangles divided among thousands of draw calls.

Understanding draw calls is not just a skill reserved for technical artists or senior engine programmers. It is a fundamental concept that every game developer—whether working on a solo mobile project or a large-scale console title—needs to grasp. By learning how draw calls work, how the CPU and GPU communicate, and how to implement optimization techniques, you will unlock the ability to build visually striking games that run flawlessly across a wide range of hardware.

---

---

1. What Is a Draw Call?

At its simplest, a draw call is an instruction sent by the CPU to the GPU, telling it to render a mesh with specific textures and materials.

The CPU handles game logic, physics, and coordinates rendering, while the GPU is a parallel processor designed to render vertex and texture data into screen pixels.

Because the CPU and GPU are separate chips with different memory architectures, they must coordinate. The CPU prepares the visual data, loads it into graphics memory (VRAM), and tells the GPU exactly what to do with it. Each time the CPU sends a command like "Hey GPU, draw this wooden crate mesh using this wood material and texture," a draw call is born.

The Art Director and Painter Analogy

Think of the CPU as an Art Director and the GPU as a master Painter. The Painter is incredibly fast at putting paint on canvas but has no initiative. The Painter will sit doing nothing until instructed. The Art Director must hand the Painter a canvas (mesh), set up the paint jars and brushes (materials and shaders), and say: "Paint this crate."

If the Art Director tells the Painter to paint one giant forest scene with 1,000 trees in one single instruction, the Painter gets to work and finishes quickly. But if the Art Director hands the Painter 1,000 separate tiny canvases, constantly swapping brushes and paints for every single leaf and pebble, the Painter spends 95% of their time waiting for the Art Director to hand them the next canvas and paint jar. The Art Director (CPU) becomes exhausted, and the Painter (GPU) sits idle, waiting. This delay is the essence of a CPU draw call bottleneck.

---

2. How Rendering Works: Under the Hood

To fully grasp draw calls, we need to examine the path data takes from your game files to the pixels on the monitor. This path is known as the Render Pipeline.

The render loop begins with visibility checks. The CPU runs frustum culling (removing objects outside the camera's field of view) and occlusion culling (removing objects hidden behind closer geometry). The remaining visible objects are scheduled for drawing.

The Setup and State Changes

Before drawing a mesh, the CPU must tell the GPU how to shade it. This is a Render State Change. The CPU binds resources, telling the GPU:

• Which vertex and pixel/fragment shaders to run.
• Which textures to bind (diffuse, normal, metallic, etc.).
• Which rendering states to use (depth testing, stencil logic, blend modes).
• The object's transform coordinates (world position, scale, rotation).

Render state changes are expensive. The CPU translates these commands through drivers via a graphics API (Vulkan, DirectX, Metal, or OpenGL). If your scene requires the CPU to switch shaders and textures for every small object, the CPU will bottleneck translating driver instructions, leaving the GPU waiting for work.

The Execution

Once the states are set, the CPU pushes a draw command (such as glDrawElements in OpenGL or DrawIndexedInstanced in DirectX) into the **Command Buffer**. The GPU reads from this buffer asynchronously, processing vertices, interpolating triangles, rasterizing them into pixels, running the pixel shaders, and writing the final colors into the frame buffer.

---

3. Why Draw Calls Matter

Draw calls are the primary cause of CPU rendering bottlenecks. If a CPU requires 0.05 milliseconds to prepare one draw call, and the frame has 400 draw calls, the CPU spends 20 milliseconds on drawing instructions alone. For a solid 60 FPS target, the entire frame (including physics, AI, and scripts) must process in under 16.6 milliseconds. If drawing commands take 20 milliseconds, your game cannot hit 60 FPS, regardless of GPU power.

Info: The Golden Rule of Game Performance

Always remember: Optimization is diagnostic before it is corrective. Never start blindly combining meshes until you have profiled the game to confirm draw calls (CPU overhead) are your actual bottleneck. If your game is lagging due to post-processing or dynamic shadows (GPU bound), reducing draw calls will not help.

Mobile Hardware Limitations

While PCs and modern consoles have dedicated, high-speed architectures and sophisticated drivers (like Vulkan and DirectX 12) designed to handle thousands of draw calls, mobile devices are severely constrained. Mobile GPUs often use Tile-Based Deferred Rendering (TBDR). This architecture saves memory bandwidth by splitting the screen into tiny tiles and rendering them locally on-chip. However, it relies heavily on the CPU to sort and bin geometry beforehand. High draw calls on mobile don't just reduce frame rates; they cause massive battery drain and trigger thermal throttling.

Virtual Reality (VR) Considerations

VR takes draw call pressure to another level. In a standard flat-screen game, the engine renders the scene from one camera perspective. In VR, the engine must render the scene twice—once for the left eye, and once for the right eye. Without advanced optimization, this double-rendering doubles your draw calls. Combined with the high refresh rate requirements of VR (often 90Hz to 120Hz, meaning less than 11ms to render a frame), optimizing draw calls becomes a hard requirement to prevent motion sickness.

---

4. Draw Calls vs Triangle Count

One of the most persistent myths among beginner developers is that the polygon count of a 3D model is the most important factor in game performance. This leads developers to spend hours retopologizing a prop to reduce it from 5,000 to 2,000 triangles, while completely ignoring that the prop uses five different materials, causing five draw calls every time it is placed.

Modern GPUs are absolute beasts at processing polygons. They contain thousands of arithmetic logic units (ALUs) designed to run vertex math in parallel. Passing a single mesh with 500,000 triangles to the GPU in a single draw call is incredibly efficient; the GPU keeps all its cores saturated. However, passing 500 individual meshes of 1,000 triangles each (which totals the same 500,000 triangles) requires 500 distinct draw calls. The CPU will struggle to feed these commands to the GPU, causing a bottleneck.

The table below highlights the difference in performance characteristics between polygon limits and draw call limits:

Metric	High Draw Call / Low Poly Scene	Low Draw Call / High Poly Scene
Example Scene	2,000 individual fences, crates, and grass clumps (1,000 tris each)	1 combined city block mesh (2,000,000 tris total)
Total Triangles	2,000,000 Triangles	2,000,000 Triangles
Draw Calls Count	2,000+ Draw Calls	1 Draw Call
Primary Bottleneck	CPU Bound (Driver overhead, API commands, state switches)	GPU Bound (Vertex shader execution, rasterization)
Performance Profile	Poor FPS, stuttering, low GPU utilization (GPU sits idle waiting)	Stable FPS, high GPU utilization (GPU runs at 100% capacity)
Target Hardware Impact	Devastating on mobile and older CPU systems	Typically handled well by modern desktop graphics cards

---

5. Common Causes of High Draw Calls

Before we look at engine-specific solutions, let us identify the common design patterns and mistakes that inflate draw call counts in a game scene:

• Too Many Unique Materials: Each material forces a render state change. Fifty identical props using fifty unique materials require fifty draw calls instead of one.
• Modular Kitbashing: Placing hundreds of individual wall pieces, columns, and arches gives high editor flexibility but generates individual draw calls for each placed asset.
• Unoptimized UI Canvases: Animating positions or colors of UI elements causes canvas rebuilds. If unstructured, a single dynamic element can break UI batching entirely.
• Poor Texture/Channel Packing: Not using channel-packed textures (like putting Metallic, Roughness, and AO into RGB channels) results in complex materials that hinder batching.
• Real-time Shadows: Every shadow-casting light forces a scene redraw from its perspective. Five shadow-casting lights multiply the draw calls of every mesh within their range.

---

6. Draw Calls in Unity

Unity uses the concept of Batches and SetPass Calls to represent draw calls. Let's break down Unity's automated systems to reduce them, and how you can track them.

Unity Batching Technologies

Unity offers several native batching systems to group draw calls under the hood:

1. Static Batching

Static Batching combines non-moving meshes sharing a material into a single vertex buffer at startup, allowing Unity to draw them in one call.
Requirements: You must check the "Static" (specifically "Batching Static") box in the Inspector for all participating GameObjects, and they must share the exact same material.
Trade-off: It increases memory usage. Batching 1,000 identical fence segments creates a massive combined mesh in VRAM, rather than instancing a single asset.

2. Dynamic Batching

Dynamic Batching is designed for moving objects. On the CPU, Unity packages the vertices of visible, moving objects into a temporary vertex buffer and sends them to the GPU in a single draw call.
Requirements: The meshes must be small (typically under 300 vertices and 900 vertex attributes) and must share the same material.
Trade-off: The CPU has to perform the batching calculation every frame. On modern systems, this CPU overhead can cost more performance than the draw calls themselves.

3. GPU Instancing

GPU Instancing lets the GPU render identical meshes in a single draw call while supporting per-instance properties like position, scale, and color.
Requirements: The meshes must be identical, use the same material, and use a shader that supports GPU Instancing (by adding the #pragma multi_compile_instancing directive).

struct Attributes { float4 positionOS : POSITION; UNITY_VERTEX_INPUT_INSTANCE_ID // Declare instance ID }; struct Varyings { float4 positionCS : SV_POSITION; UNITY_VERTEX_INPUT_INSTANCE_ID // Propagate instance ID }; Varyings vert(Attributes input) { Varyings output; UNITY_SETUP_INSTANCE_ID(input); UNITY_TRANSFER_INSTANCE_ID(input, output); output.positionCS = TransformObjectToHClip(input.positionOS.xyz); return output; }

4. Scriptable Render Pipeline (SRP) Batcher

Native to URP and HDRP, the SRP Batcher speeds up draw calls rather than reducing their count. It stores material data in persistent GPU memory buffers (Constant Buffers). If objects share a shader, Unity binds it once and renders them sequentially by updating offset values, bypassing expensive CPU state changes.
Requirements: Mesh renderers must use SRP Batcher-compatible shaders (like standard Lit shaders), and the mesh must not be dynamically generated.

Batching Type	Movement	Mesh Restrictions	Material Requirement	Main Benefit / Cost
Static Batching	Must be static	None (any size)	Must be identical	Zero CPU overhead at runtime; high VRAM usage.
Dynamic Batching	Can move	Very small meshes (<900 vertex attributes)	Must be identical	Automated for small models; CPU cost can be high.
GPU Instancing	Can move	Must use identical Mesh asset	Must use identical Material	Extremely memory efficient; ideal for grass and trees.
SRP Batcher	Can move	None (any size)	Must use same Shader (different materials OK)	Saves CPU setup time; native in modern pipelines.

Unity Diagnostic Tools

To analyze draw calls in Unity, you have two primary built-in tools:

• The Stats Window: In the Game View, click the **Stats** button. Look at the **Batches** (total draw calls) and **SetPass Calls** (render state changes). Keep an eye on SetPass Calls; a high number of SetPass Calls is usually more taxing to performance than a high Batch count because state changes are more expensive than draws.
• The Frame Debugger: Go to Window > Analysis > Frame Debugger. This tool lets you scrub through the rendering steps of a single frame one draw call at a time. It tells you exactly what object is being drawn, which shader is active, and why a particular draw call could not be batched with the previous one.

---

7. Draw Calls in Unreal Engine

Unreal Engine offers robust systems designed to manage large worlds, dense geometry, and complex shaders. Let's look at how Unreal manages and optimizes draw calls.

Unreal Engine Draw Call Reduction Features

1. Instanced Static Meshes (ISM)

Like GPU Instancing, ISMs render copies of a mesh in one draw call.
How it works: An ISM references one Static Mesh and a list of instance transforms.
Limitation: The entire group is culled together. If one instance is visible, the engine processes all of them, wasting GPU cycles.

2. Hierarchical Instanced Static Meshes (HISM)

HISMs resolve the culling limitations of standard ISMs.
How it works: HISMs organize instances into tree structures (like octrees) for individual culling and support per-instance LOD transitions.
When to use: Best for foliage, grass, and repeated props across large levels.

3. Hierarchical Level of Detail (HLOD)

At long distances, rendering multiple LOD meshes still causes high draw calls.
How it works: HLOD combines far-away meshes into a single simplified proxy mesh with a baked material, reducing hundreds of draw calls to one.

4. Nanite Virtualized Geometry

Nanite virtualizes geometry by breaking meshes down into pixel-sized clusters.
How it works: Using compute shaders, Nanite performs cluster-level visibility and rendering, bypassing traditional CPU draw call bottlenecks.
Limitation: It is restricted to modern platforms (PC, current-gen consoles) and has performance penalties with transparent, masked, or vertex-deformed materials.

Feature	Culling Precision	LOD Support	Ideal Use Case	Key Limitation
Static Mesh	Individual mesh level	Per-mesh basis	Unique hero props, custom buildings	Generates 1+ draw call per placed actor.
ISM	Group level (all or nothing)	One LOD for all instances	Small dense clusters of identical meshes	Poor occlusion/frustum culling efficiency.
HISM	Hierarchical cluster level	Per-instance LOD steps	Foliage, grass, vast debris fields	Slightly higher CPU set-up cost than ISM.
HLOD	Combined mesh level	Far-distance baked LOD	Distant cities, mountains, landscapes	Requires offline building, increases disk size.
Nanite	Cluster-level (pixel scale)	Continuous virtualized LOD	High-poly megascans, detailed meshes	Limited platform support; expensive VRAM footprint.

Unreal Profiling Tools

To track down draw calls in Unreal Engine, open the in-editor console (tilde key ~) and use these tools:

• stat RHI: Type stat RHI into the console. This overlay shows you "Counters / RHI", listing "Draw Calls" and "Triangles Drawn". On PC, you should aim to keep draw calls under 2,000 to 3,000 per frame. On mobile, keep them below 150 to 200.
• Unreal Insights: Unreal Insights is a standalone profiling application packaged with the engine. It tracks the engine's execution down to the microsecond, showing you exactly where the CPU thread (RenderThread) is stalling due to graphics API overhead or driver wait times.

---

8. How to Reduce Draw Calls: Practical Solutions

Regardless of the game engine you use, the principles of reducing draw calls remain the same. Here are the core techniques you can implement during production:

1. Texture Atlasing

A texture atlas combines several small, individual textures into one large sheet.
If a table, chair, and bookshelf each have unique textures, they require separate materials and draw calls. Combining their textures into one atlas and remapping UV coordinates allows them to share a single material, batching the assets into a single draw call.

Important: Transparent Objects and Batching

Transparent and alpha-blended objects (like glass windows, smoke particles, and water planes) are difficult to batch. Graphics engines must render transparent objects from back-to-front (depth sorting) to ensure transparency renders correctly.

Because of this sorting requirement, even if multiple transparent objects share the same material, the engine cannot batch them together if there is an opaque object physically positioned between them in 3D space. Keep your transparent elements organized and separate them from your opaque batching structures.

2. Material Optimization (Sharing Materials)

Minimize the number of unique materials in your project. Instead of creating a new material for every object, create flexible Master Materials (or Uber-shaders) that use parameters to change colors, textures, and properties. In Unreal Engine, use "Material Instances"; in Unity, use "MaterialPropertyBlocks" to vary appearance without generating state changes.

3. Mesh Combining

If you have designed a house using 50 modular wall pieces, doors, and columns, combine them into a single mesh. Both Unity and Unreal have built-in mesh merging tools. You can also export your modular layouts back to 3D modeling packages like Blender or Maya, merge the meshes, clean up the topology, and re-import them as a single asset.

4. Level of Detail (LOD) Systems

LOD systems swap out detailed meshes for simpler ones as they move away from the camera. While LODs are primarily used to reduce polygon counts on the GPU, they also help reduce draw calls. At far distances, LOD systems can swap out multi-material objects for single-material fallback models, or make use of HLODs to collapse entire sections of a level into a single draw call.

5. Occlusion Culling

Occlusion culling checks if an object is hidden behind other geometry (e.g., walls or mountains). If blocked, the engine skips rendering it, saving CPU draw calls and GPU pixel shading calculations.

---

9. Mobile Game Optimization

If you are developing a game for mobile platforms (iOS or Android), managing draw calls is your primary performance constraint. Mobile chipsets share system memory (RAM) between the CPU and the GPU, which means memory bandwidth is extremely limited compared to PC setups with dedicated GDDR VRAM.

High draw calls on mobile devices lead to:

• Thermal Throttling: As the CPU works to translate draw calls through mobile drivers (which have higher overhead than PC APIs), it generates heat. The mobile operating system will actively throttle the clock speeds of both CPU and GPU to cool the device down, causing sudden framerate drops.
• Rapid Battery Drain: Constant CPU-GPU memory context switching consumes significant electrical power, draining the user's phone battery quickly and causing the device to feel uncomfortably hot in their hands.

The table below summarizes the hardware performance differences you must account for:

Specification	High-End PC / Console (Vulkan, DX12)	Mobile Device (OpenGL ES, Vulkan Mobile)
Target Draw Calls Limit	2,000 - 5,000 per frame	100 - 200 per frame
Memory Architecture	Dedicated GPU VRAM (High Bandwidth)	Shared System LPDDR RAM (Low Bandwidth)
Primary Draw Call Limiters	API driver performance, GPU pipeline latency	CPU thermal throttling, bandwidth limits, driver overhead
Shadow map budget	Multiple dynamic shadow maps with cascading LODs	Rarely use real-time shadows; rely on baked shadow maps
Transparency rendering	High tolerance for overdraw and alpha blending	Very sensitive; alpha blending causes fill-rate bottlenecks

---

10. Real Development Example

Let us look at a practical, real-world scenario to see how these techniques translate into performance gains.

Consider a level representing a crowded medieval marketplace. The scene contains:

• 100 wooden crates (each crate has 1 unique wood material).
• 150 market stalls (each stall uses 2 materials: wood and fabric canvas).
• 500 cobblestone ground stones (individual meshes, sharing 1 stone material).
• 250 modular stone wall pieces (each using 1 plaster material).

Without optimization, the engine renders each mesh individually. A single crate generates 1 draw call. A stall generates 2 draw calls (one for wood, one for fabric). The unoptimized scene generates "1,150 draw calls" just for these props, easily pushing a mobile game into unplayable territory and causing frame stutters on a low-end PC.

The Optimization Plan:

1. Texture Atlasing: We combine the wood texture, fabric canvas texture, plaster texture, and cobblestone stone texture into a single 4K texture atlas. We update the UVs of all the meshes in Blender and assign them a single shared material.
2. GPU Instancing / HISMs: Since the 100 crates are identical meshes, we convert them into an Instanced Static Mesh (in Unreal) or enable GPU Instancing on the shared material (in Unity). This collapses 100 draw calls down to 1.
3. Mesh Combining: We take the 250 modular stone wall pieces and bake them together in the editor into 5 large combined wall blocks. This collapses 250 draw calls down to 5.
4. Static Batching: We set the cobblestone ground meshes to "Static" and let the engine batch them.

The results of this optimization pass are shown in the table below:

Asset Group	Unoptimized Draw Calls	Optimization Technique	Optimized Draw Calls
100 Wooden Crates	100 Draw Calls	GPU Instancing / ISMs	1 Draw Call
150 Market Stalls	300 Draw Calls (2 materials per stall)	Texture Atlasing & Shared Material	150 Draw Calls (Now 1 call per stall)
500 Cobblestone Meshes	500 Draw Calls	Static Batching / HISMs	1 Draw Call
250 Modular Stone Walls	250 Draw Calls	Mesh Combining (into 5 sections)	5 Draw Calls
TOTALS	1,150 Draw Calls	—	157 Draw Calls (86% Reduction)

---

11. Common Beginner Mistakes

Avoid these common pitfalls when optimizing draw calls in your project:

• Creating Too Many Materials: Beginners often assign unique materials to every mesh. If a modular corridor pack of 20 pieces uses 20 unique materials, they cannot be batched. Assign shared materials to as many assets as possible.
• Ignoring Batching Rules: A common mistake is marking objects static and then moving them via script at runtime. This forces the engine to constantly re-evaluate batching structures, adding CPU overhead.
• Not Profiling Standalone Builds: Profiling inside the editor window is misleading because the editor UI generates its own draw calls. Always profile standalone development builds on target hardware.
• Overusing Modular Assets: Building with modular kits is standard practice, but leaving them as individual assets at release hurts performance. Run a mesh merging or HLOD pass before shipping.

Info: Nanite vs. Traditional Draw Calls

If you are using Unreal Engine 5, do not assume Nanite solves all draw call issues. Nanite operates on a completely different rendering path. While it excels at drawing millions of static triangles with minimal draw calls, it does not support transparent surfaces, dynamic vertex distortion, or skinned skeletal meshes (like characters). For characters, vegetation, and translucent objects, traditional draw call rules still apply.

---

12. My Optimization Workflow

Here is the structured optimization workflow I follow in my projects:

1. Profile the Baseline: Run the game on target hardware and check CPU and GPU frame times. If the CPU rendering thread is taking longer than the GPU frame time, we are CPU bound.
2. Check Draw Calls and SetPass Calls: Open the Stats window or type `stat RHI` in Unreal. Note the number of draw calls. If they exceed the target budget (e.g., 200 for mobile, 2,000 for PC), we prioritize draw call reduction over polygon reduction.
3. Inspect the Frame: Use the Unity Frame Debugger or Unreal Insights to inspect the rendering sequence. Identify which assets are generating the highest number of draw calls and look at why batching fails.
4. Apply the Fixes:
   • Combine small modular meshes (like walls, pipes, and columns) that are always rendered together.
   • Group repeating foliage, rocks, and props into HISMs or instanced batches.
   • Generate texture atlases for assets that are frequently grouped in the scene.
   • Set up LOD configurations, ensuring distant models use fewer materials.
5. Re-Profile and Iterate: Build the game again, measure the performance improvement, and repeat the process until the performance targets are met.

---

13. Conclusion

Game optimization is a balancing act. It is not about making your game look worse; it is about structuring your visual assets so the hardware can draw them efficiently. Draw calls represent the administrative overhead of rendering. By understanding how the CPU and GPU communicate, you can reduce this overhead and free up resources for better physics, advanced AI, or richer visual effects.

Start thinking about draw calls early in your development cycle. Plan your material usage, group your textures into atlases, use instancing for repeated assets, and profile your game regularly. Your players, and their hardware, will thank you.

---

Frequently Asked Questions

1. What is the difference between a Draw Call and a Batch?

A draw call is a single instruction sent from the CPU to the GPU to render a mesh. A batch is a collection of draw calls grouped by the engine into a single draw command to minimize driver overhead.

2. Does reducing polygons reduce draw calls?

No. Polygon reduction optimizes GPU vertex processing, but does not affect draw calls. A 100-triangle mesh and a 1,000,000-triangle mesh both require exactly one draw call if they use a single material.

3. Why do different materials prevent batching?

Different materials use different shaders, textures, or properties. Changing materials requires the CPU to send commands that alter the GPU's rendering state (a state change), preventing them from being merged into one draw call.

4. What is a SetPass call in Unity?

A SetPass call occurs when a new shader pass is bound, triggering an expensive render state change. Minimizing SetPass calls is often more critical than reducing batches, as state changes generate significant CPU overhead.

5. Should I use Static Batching for everything?

No. Static batching creates a massive combined mesh in VRAM, which drastically increases memory footprint if overused on identical props. Use static batching for unique environment layouts and instancing for identical assets.

6. Can dynamic batching cause performance drops?

Yes. Dynamic batching requires the CPU to build temporary vertex buffers every frame. If the CPU spends too much time grouping moving vertices, this overhead can exceed the rendering performance saved.

7. What are the drawbacks of using Texture Atlases?

Atlases make tiling textures difficult because UV coordinates are restricted to a sub-rect of the sheet. They can also cause texture bleeding (adjacent textures leaking at a distance) if layout padding is insufficient.

8. What is the target draw call budget for VR games?

Standalone VR (like Meta Quest) usually permits 100–150 draw calls per eye. PC VR supports higher ranges (500–1,000), but both require optimization because VR must render the scene twice (once per eye).

9. How does the SRP Batcher differ from GPU Instancing?

GPU Instancing is limited to identical meshes with the same material. The SRP Batcher batches different meshes using different materials, provided they use the same shader, by caching material variables in persistent VRAM buffers.

10. Can lights and shadows increase draw calls?

Yes. Shadow-casting lights force the engine to render the scene from the light's perspective to build shadow maps. This duplicates draw calls for every illuminated object, multiplying CPU overhead.