15.4 Draw Calls, Batching, LOD & Culling

Chapter 7.8 introduced the frame budget: 16.6 ms to produce one frame at 60 fps, split between CPU work and GPU work. Chapter 8.5 named the two numbers that usually blow that budget on a real scene — draw calls and triangles — and gave you LOD, batching, GPU instancing, and occlusion culling as a checklist to fix them. This chapter opens each of those techniques up properly: exactly what a draw call costs the CPU and why, how to sort renderers so materials stop breaking batches, the actual code for static batching, dynamic batching, and the SRP Batcher, the math behind picking LOD distances instead of guessing them, and a full walkthrough of frustum culling, occlusion culling, and per-layer distance culling. By the end you will be able to open the Frame Debugger on a real scene and explain, draw call by draw call, why each one is there and whether it needs to be.

1. What a Draw Call Actually Costs

A draw call is one command the CPU sends to the GPU: "render this mesh, with this material, at this transform, right now." The GPU side of that command is almost always fast — GPUs are built to chew through triangles by the million. The CPU side is where the real cost hides, and it has nothing to do with how many triangles the mesh has. Before the GPU can even start, the CPU has to:

• Check whether the render state (shader, textures, blend mode, and so on) actually needs to change from the last draw call, and update it if so.
• Upload this object's transform (its position, rotation, and scale, packed into a matrix) to a buffer the GPU can read.
• Build a small command describing the draw and hand it to the graphics driver.
• Let the driver itself validate that command before it goes anywhere near the GPU — the driver is software too, and it does its own bookkeeping.

Every one of those steps costs a small, roughly fixed amount of CPU time, whether the mesh behind it is a 12-triangle cube or a 50,000-triangle character. Draw one object with 50,000 triangles and the GPU works hard. Draw 5,000 objects with 10 triangles each — same total triangle count — and the CPU does 5,000 times the setup work for the same GPU workload. That is the core fact this whole chapter is built on: past a fairly low triangle count, draw call count matters more than triangle count.

2. Worked Example: 1000 Objects vs 1 Combined Mesh

Numbers make this concrete. Picture 1000 small cubes arranged in a grid, each one its own GameObject with its own MeshRenderer, all sharing one material. Here is the naive way to build that scene:

using UnityEngine;

public class SpawnManyCubes : MonoBehaviour
{
    public Mesh cubeMesh;
    public Material cubeMaterial;
    public int count = 1000;

    void Start()
    {
        for (int i = 0; i < count; i++)
        {
            GameObject go = new GameObject("Cube_" + i);
            MeshFilter mf = go.AddComponent<MeshFilter>();
            MeshRenderer mr = go.AddComponent<MeshRenderer>();

            mf.mesh = cubeMesh;
            mr.sharedMaterial = cubeMaterial; // shared, not a private copy
            go.transform.position = new Vector3(i % 32, 0f, i / 32) * 1.2f;
        }
    }
}

Each of those 1000 cubes ends up as its own draw call, because each one is a separate MeshRenderer and Unity has no way to know ahead of time that they never move relative to each other. Now build the same visual result a completely different way: merge all 1000 cube meshes into one big mesh, once, at load time.

using UnityEngine;
using UnityEngine.Rendering;

public class CombineCubes : MonoBehaviour
{
    public Mesh cubeMesh;
    public Material cubeMaterial;
    public int count = 1000;

    void Start()
    {
        CombineInstance[] combine = new CombineInstance[count];

        for (int i = 0; i < count; i++)
        {
            Vector3 pos = new Vector3(i % 32, 0f, i / 32) * 1.2f;
            combine[i].mesh = cubeMesh;
            combine[i].transform = Matrix4x4.Translate(pos);
        }

        Mesh combinedMesh = new Mesh();
        combinedMesh.indexFormat = IndexFormat.UInt32; // 1000 cubes = way over 65535 verts
        combinedMesh.CombineMeshes(combine);

        GameObject go = new GameObject("CombinedCubes");
        go.AddComponent<MeshFilter>().mesh = combinedMesh;
        go.AddComponent<MeshRenderer>().sharedMaterial = cubeMaterial;
    }
}

Both versions put the exact same triangles on screen. The only thing that changed is how many times the CPU had to say "GPU, draw this now":

Put a real number on "(fixed)" and the effect stops being abstract. A single draw call's CPU-side overhead is commonly somewhere in the range of 0.01 to 0.05 ms once state validation, matrix upload, and driver bookkeeping are included — the exact number depends on the platform, the driver, and how much state changed. At a middle-of-the-road 0.02 ms per call:

This is a worked illustration, not a guaranteed measurement — your own numbers will depend on your target hardware. What does not change from platform to platform is the pattern: CPU draw call cost scales with how many times you call it, not with how much geometry is behind each call. That is the whole reason batching, instancing, and the SRP Batcher exist, and it is why the rest of this chapter treats "reduce draw calls" as a separate goal from "reduce triangles."

3. SetPass Calls: Why Changing Material Is the Expensive Part

Not every draw call costs the same amount, even before batching enters the picture. Right before a draw call, the GPU sometimes needs a SetPass call — a pipeline state change: binding a different shader program, binding different textures, or changing a render state like blend mode or depth testing. A SetPass call is considerably more expensive than the draw call that follows it, because it is reconfiguring how the entire GPU pipeline behaves, not just handing over one more object to draw.

The trigger for a SetPass call is a material change. Two draw calls in a row using the exact same material need zero SetPass calls between them — the GPU pipeline is already set up correctly. Two draw calls in a row using different materials need a SetPass call in between, even if the meshes are trivial. This is why the order you submit draw calls in matters, not just how many objects there are.

Unity's own renderer already sorts opaque objects to reduce state changes where it safely can (roughly front-to-back for opaque objects, to help early depth testing, and by render queue and shader for state changes), but it cannot always find the best order on its own, especially once custom render queues or lots of unique materials are involved. What you control directly is how many distinct materials exist in the first place — fewer unique materials means fewer possible SetPass transitions no matter what order things end up in. A quick way to see that number for a set of renderers:

using System.Linq;
using UnityEngine;

public static class BatchAudit
{
    public static void ReportUniqueMaterials(MeshRenderer[] renderers)
    {
        int uniqueMaterials = renderers
            .Select(r => r.sharedMaterial)
            .Distinct()
            .Count();

        Debug.Log("Renderers: " + renderers.Length);
        Debug.Log("Unique materials: " + uniqueMaterials);
        Debug.Log("Best case SetPass calls (if perfectly sorted): " + uniqueMaterials);
    }
}

Run BatchAudit.ReportUniqueMaterials against, say, 500 renderers that only actually use 12 different materials, and the console shows:

Renderers: 500
Unique materials: 12
Best case SetPass calls (if perfectly sorted): 12

That "12" is a ceiling on how good this scene can possibly get through sorting alone — it cannot go lower without either combining renderers into fewer draw calls (Sections 4 to 6) or reducing the number of distinct materials in the first place (Section 8).

4. Static Batching

Static batching combines the meshes of objects that are marked as never moving, into one big vertex buffer, once, either when the scene loads or at build time. Afterward, any group of those objects that shares a material draws as a single batch instead of one draw call per object. It is the right tool for level geometry: buildings, terrain props, rocks, fences — anything placed once and never repositioned, rotated, or scaled again at runtime.

Marking objects "Static" in the Inspector's Static checkbox is the normal way to opt in, but the same thing is available from code, useful when objects are generated procedurally at load time rather than placed by hand in the Editor:

using UnityEngine;

public class BuildStaticBatch : MonoBehaviour
{
    public GameObject[] neverMovingRocks;

    void Start()
    {
        // Combines every renderer in neverMovingRocks that shares a
        // material into as few draw calls as possible, and parents
        // the result under this GameObject's transform.
        StaticBatchingUtility.Combine(neverMovingRocks, gameObject);
    }
}

There is no console output from this call — the result shows up in the Frame Debugger as a single "Static Batch" step covering every rock that shares a material, instead of one step per rock. The cost is memory, not CPU: static batching duplicates each object's vertex data into the shared buffer, transformed into its final position ahead of time. Combine 500 copies of the same 2,000-vertex rock and you store roughly 500 x 2,000 vertices worth of data, even though visually it is still "the same rock" 500 times. Compare that to GPU instancing in Section 6, which keeps exactly one copy of the mesh in memory no matter how many instances appear on screen — the trade-off between the two techniques is almost entirely about this memory cost versus the ability to move objects at runtime.

5. Dynamic Batching

Dynamic batching is static batching's opposite in one specific way: it works on objects that do move, by rebuilding a combined vertex buffer fresh every single frame instead of once. Unity's built-in render pipeline can do this automatically for renderers that meet a fairly strict set of conditions:

• The renderers share the exact same material (not merely the same shader).
• Each mesh is small — a limit of roughly 300 vertices per mesh (the practical ceiling is actually stated in terms of vertex attributes, so a mesh using fewer vertex attributes per vertex can sometimes go a bit higher).
• None of the objects are marked Static (a Static object uses static batching instead, and the two do not combine).
• The shader used is a single-pass shader — multi-pass shaders cannot be merged this way.
• Scale matters: uniformly scaled objects batch together fine; mixing a positive and a negative scale on the same axis across objects breaks the batch, because flipping a mesh inside-out changes triangle winding order.

Because it costs CPU time every frame to rebuild that shared buffer, dynamic batching is a net win mainly for large numbers of very small, very simple objects — think scattered debris, bullet casings, or simple foliage cards — and matters far less than it used to now that GPU instancing (Section 6) and the SRP Batcher (Section 7) exist. It is still worth understanding its limits, if only to recognize when a mesh is quietly disqualifying itself:

using UnityEngine;

public class DynamicBatchEligibility : MonoBehaviour
{
    const int dynamicBatchVertexLimit = 300;

    void Start()
    {
        Mesh mesh = GetComponent<MeshFilter>().sharedMesh;

        if (mesh.vertexCount > dynamicBatchVertexLimit)
        {
            Debug.LogWarning(name + " has " + mesh.vertexCount +
                " vertices -- too heavy for dynamic batching (limit ~" +
                dynamicBatchVertexLimit + ").");
        }
        else
        {
            Debug.Log(name + " has " + mesh.vertexCount +
                " vertices -- eligible for dynamic batching.");
        }
    }
}

Attach this to a simple debris chunk with 180 vertices and a detailed prop with 4,500 vertices, and the console shows the two verdicts side by side:

Debris_Chunk has 180 vertices -- eligible for dynamic batching.
DetailedCrate has 4500 vertices -- too heavy for dynamic batching (limit ~300).

6. GPU Instancing

GPU instancing takes a different approach entirely: instead of combining meshes into one buffer (static batching) or rebuilding a buffer every frame (dynamic batching), it sends the mesh to the GPU exactly once, then sends a list of per-instance data — most commonly a transform matrix each — and lets the GPU stamp out that one mesh at every position in a single draw call. It is the natural fit for many copies of the exact same mesh that still need to move, spawn, or despawn independently: grass, trees, rocks, arrows, bullet casings.

A minimal instanced draw, scattering foliage clumps across a field:

using UnityEngine;

public class InstancedFoliage : MonoBehaviour
{
    public Mesh clumpMesh;
    public Material clumpMaterial; // must have "Enable GPU Instancing" checked
    public int clumpCount = 6000;

    Matrix4x4[][] batches; // pre-split into chunks of at most 1023

    void Start()
    {
        const int maxPerBatch = 1023; // hard limit of Graphics.DrawMeshInstanced
        int batchCount = Mathf.CeilToInt(clumpCount / (float)maxPerBatch);
        batches = new Matrix4x4[batchCount][];

        int placed = 0;
        for (int b = 0; b < batchCount; b++)
        {
            int sizeThisBatch = Mathf.Min(maxPerBatch, clumpCount - placed);
            batches[b] = new Matrix4x4[sizeThisBatch];

            for (int i = 0; i < sizeThisBatch; i++)
            {
                Vector3 pos = new Vector3(Random.Range(-60f, 60f), 0f, Random.Range(-60f, 60f));
                Quaternion rot = Quaternion.Euler(0f, Random.Range(0f, 360f), 0f);
                float scale = Random.Range(0.8f, 1.3f);
                batches[b][i] = Matrix4x4.TRS(pos, rot, Vector3.one * scale);
                placed++;
            }
        }
    }

    void Update()
    {
        // Pre-split once in Start, so Update just submits the chunks --
        // no per-frame array allocation.
        for (int b = 0; b < batches.Length; b++)
        {
            Graphics.DrawMeshInstanced(clumpMesh, 0, clumpMaterial, batches[b]);
        }
    }
}

With clumpCount = 6000, that is 6 chunks of at most 1023 each, so 6 draw calls put 6000 foliage clumps on screen every frame — instead of 6000 separate draw calls. Splitting the chunks once in Start() rather than every frame in Update() matters: allocating a new array 6 times a frame, 60 times a second, is exactly the kind of hidden garbage-collector pressure that shows up as stutter later, even though the draw call count itself looks fine.

7. The SRP Batcher

If your project uses a Scriptable Render Pipeline (URP or HDRP), there is a fourth technique that works completely differently from the first three. The SRP Batcher does not merge multiple objects into fewer draw calls at all — a scene with 500 separate objects using SRP-Batcher-compatible shaders still issues 500 draw calls. What it does instead is make each individual draw call dramatically cheaper to prepare on the CPU, by caching each material's shader property data on the GPU between frames, so switching from one object to the next — even a completely different mesh, even a different material, as long as both use SRP-Batcher-compatible shaders — mostly just means pointing at already-uploaded data instead of re-uploading it.

This matters because it removes the usual reason material variety was expensive: normally, switching materials costs a SetPass call (Section 3) plus fresh property uploads. With the SRP Batcher active, that cost shrinks so much that scenes with lots of unique materials — the exact case batching and atlasing are built to avoid — stop being nearly as painful.

The requirement is on the shader side: its per-material properties need to sit inside a constant buffer block Unity recognizes, using the name UnityPerMaterial. Every built-in URP and HDRP shader, and every default Shader Graph output, already follows this convention. A hand-written shader has to opt in explicitly:

// Simplified excerpt from a URP-style shader's HLSL code.
// Properties declared inside this exact CBUFFER are what makes
// the shader SRP-Batcher compatible.

CBUFFER_START(UnityPerMaterial)
    float4 _BaseColor;
    float _Metallic;
    float _Smoothness;
CBUFFER_END

There is no code to write on the C# side to turn this on — it is automatic once every shader in play qualifies. What you can check is whether it is actually happening: the Frame Debugger (Section 13) labels a qualifying draw call as an "SRP Batch" instead of a plain draw call, and the Frame Debugger's own statistics panel reports an "SRP Batches" count for the frame. A single shader in the scene that does not qualify — a legacy Built-in Render Pipeline shader pulled into a URP project, most commonly — is enough to knock every object using it back out to ordinary, more expensive draw calls, while everything else keeps batching normally.

8. Texture Atlases and Material Sharing

Every technique so far has the same unspoken requirement: the objects involved must already share one material. Static batching, dynamic batching, and GPU instancing all stop working the instant two objects need different textures, because different textures normally mean different materials. The technical-art chapter covered texture atlases (several smaller textures packed into one larger sheet) as a way to save texture memory and avoid duplicate files; the same technique is also what turns a pile of visually different objects into objects that can batch together, because after atlasing, they all point at the same shared material and just sample a different region of the same shared texture.

The technical-art chapter's approach shifted and scaled a material's texture-sampling window (mainTextureOffset and mainTextureScale) to pick one tile out of a grid. The other common approach — useful when different meshes have completely arbitrary UV layouts, not a neat grid of tiles — is to remap the mesh's own UV coordinates once, so every vertex already points at the correct region of the shared atlas, and the material itself never needs to change per-object at all:

using UnityEngine;

public static class AtlasUVRemap
{
    // Remaps UVs that are currently in the 0-1 range of a standalone
    // texture into one cell of a gridSize x gridSize atlas, e.g.
    // cellX = 2, cellY = 1 inside a 4x4 atlas.
    public static Vector2[] RemapToAtlasCell(Vector2[] originalUVs, int cellX, int cellY, int gridSize)
    {
        Vector2[] remapped = new Vector2[originalUVs.Length];
        float cellSize = 1f / gridSize;

        for (int i = 0; i < originalUVs.Length; i++)
        {
            float u = (cellX + originalUVs[i].x) * cellSize;
            float v = (cellY + originalUVs[i].y) * cellSize;
            remapped[i] = new Vector2(u, v);
        }

        return remapped;
    }
}

A worked trace: an original UV coordinate of (0.5, 0.5) — dead center of its own texture — remapped into cell (2, 1) of a 4x4 atlas:

The payoff shows up directly in the material count from Section 3's BatchAudit. Take a cluster of 40 background props that used to need 40 separate single-texture materials, repack their textures into one shared atlas, remap their UVs, and re-run the same audit:

Before atlasing:
Renderers: 40
Unique materials: 40
Best case SetPass calls (if perfectly sorted): 40

After atlasing:
Renderers: 40
Unique materials: 1
Best case SetPass calls (if perfectly sorted): 1

Going from 40 unique materials to 1 does not just help sorting — it is what makes static batching, dynamic batching, and mesh combining possible for this cluster in the first place, since all three require a shared material as a precondition. Atlasing is frequently the step that has to happen before any of Sections 4 through 6 can do anything at all.

9. LOD — Level of Detail

The technical-art chapter built an LODGroup using fixed screen-relative-height thresholds — 50%, 15%, 2% — chosen as reasonable defaults. This section covers where numbers like that actually come from, so you can pick your own instead of guessing.

LODGroup switches meshes based on screen-relative height: the fraction of the screen's vertical height the object's bounding box currently covers, from 0 (invisible) to 1 (fills the screen top to bottom). Using a screen fraction instead of a raw world-space distance is deliberate — it automatically accounts for both the object's own size and the camera's field of view, two things a fixed "switch at 20 meters" rule would get wrong the moment you changed either one.

The relationship between screen-relative height, object size, distance, and field of view comes from basic trigonometry: an object of world-space height h, at distance d from the camera, viewed through a vertical field of view fov, fills roughly this fraction of the screen's height:

screenHeight =~ h / (2 * d * tan(fov / 2))

Rearranged to solve for distance, given a target screen-relative height threshold, this tells you exactly where a LOD switch will happen in meters, instead of picking a threshold by eye and hoping it feels right:

using UnityEngine;

public static class LODDistanceCalculator
{
    // Returns the camera distance, in meters, at which an object of
    // the given world-space height will cross the given screen-relative
    // height threshold (the same 0-1 number an LODGroup's LOD uses).
    public static float DistanceForScreenHeight(float objectWorldHeight, float screenRelativeHeight, float verticalFovDegrees)
    {
        float fovRad = verticalFovDegrees * Mathf.Deg2Rad;
        return objectWorldHeight / (2f * screenRelativeHeight * Mathf.Tan(fovRad / 2f));
    }
}

For a 2-meter-tall character, a 60-degree vertical FOV camera, and the 50% / 15% / 2% thresholds from the technical-art chapter:

DistanceForScreenHeight(2f, 0.50f, 60f)  =~  3.46 m   (switches to LOD1)
DistanceForScreenHeight(2f, 0.15f, 60f)  =~ 11.55 m   (switches to LOD2)
DistanceForScreenHeight(2f, 0.02f, 60f)  =~ 86.60 m   (culled)

Those numbers say the same 50%/15%/2% thresholds that felt reasonable for a 2-meter character would put the LOD0-to-LOD1 switch inside 3.5 meters — uncomfortably close, likely to be seen as a visible pop during normal play — while the same thresholds on a much bigger object, say a 20-meter building, would push that same switch out to 34.6 meters. This is exactly why a single set of "good" percentages does not transfer between assets of very different sizes: the percentages need to be picked with the actual object size and camera FOV in mind, using the formula above, not copied from a different asset that merely looked fine.

using UnityEngine;

public class SetupLODGroup : MonoBehaviour
{
    public Mesh highDetail;
    public Mesh mediumDetail;
    public Mesh lowDetail;
    public Material sharedMaterial;

    void Start()
    {
        LODGroup group = gameObject.AddComponent<LODGroup>();

        LOD[] lods = new LOD[3];
        lods[0] = BuildLOD(highDetail,   0.35f); // switch below 35% of screen height
        lods[1] = BuildLOD(mediumDetail, 0.12f); // switch below 12%
        lods[2] = BuildLOD(lowDetail,    0.03f); // switch below 3%, culled after that

        group.SetLODs(lods);
        group.RecalculateBounds();
    }

    LOD BuildLOD(Mesh mesh, float screenRelativeHeight)
    {
        GameObject child = new GameObject(mesh.name);
        child.transform.SetParent(transform, false);

        child.AddComponent<MeshFilter>().mesh = mesh;
        Renderer renderer = child.AddComponent<MeshRenderer>();
        renderer.sharedMaterial = sharedMaterial;

        return new LOD(screenRelativeHeight, new Renderer[] { renderer });
    }
}

10. Frustum Culling

A camera does not need to consider the entire scene every frame — only the region of space it can actually see. That region is called the view frustum (a truncated, four-sided pyramid: a near plane close to the camera, a far plane at the draw distance, and four side planes connecting them, angled outward according to the field of view). Frustum culling means testing every object's bounds against those six planes and skipping any object entirely outside all of them — no draw call, no vertex processing, no pixel shading, because the GPU is never told about it in the first place.

Unity performs this automatically for every Camera, every frame, using each renderer's bounding box, so ordinary gameplay code never has to think about it. It becomes worth writing by hand in two situations: custom systems that decide visibility themselves before Unity's normal renderer path even runs (a custom instancing system deciding which instances to include in this frame's batch, for example), or simply to understand what is happening under the hood:

using UnityEngine;

public class ManualFrustumCheck : MonoBehaviour
{
    public Camera cam;
    public Renderer target;

    void Update()
    {
        Plane[] frustumPlanes = GeometryUtility.CalculateFrustumPlanes(cam);
        bool visible = GeometryUtility.TestPlanesAABB(frustumPlanes, target.bounds);
        Debug.Log(target.name + " inside frustum: " + visible);
    }
}

With the target rock sitting in front of the camera, the console reads:

Rock_12 inside frustum: True

Walk the camera past the rock so it is now behind it, and the very same line of code prints the opposite result on the next frame:

Rock_12 inside frustum: False

Frustum culling is essentially free to benefit from — it needs no baking, no setup, and no per-object opt-in — but it only helps with objects that are outside the view cone entirely. An object can be squarely inside the frustum and still be something the player cannot possibly see, if something else is standing directly in front of it. That gap is what Section 11 closes.

11. Occlusion Culling

Occlusion culling skips objects that pass the frustum test — they are inside the view cone — but are still completely hidden behind something closer to the camera: a crate sitting directly behind a solid wall, a room full of props behind a closed door. Unlike frustum culling, this cannot be computed cheaply on the fly for a complex scene (testing every object against every possible occluder, every frame, is itself far too slow), so Unity's built-in system is a baked one: visibility data is precomputed once, in the Editor, and the camera reads that precomputed data at runtime instead of testing raw geometry.

Setting this up means opening Window > Rendering > Occlusion Culling, marking large solid objects as Occluder Static (things that can hide other objects), marking objects that should be considered for culling as Occludee Static, and running a bake. A big scene can have hundreds of candidate occluders, and not all of them are worth the bake time: a thin fence post technically blocks a sliver of view but almost never hides anything meaningful, while a building wall or a terrain ridge blocks a huge amount. A size-based filter is a practical way to flag only the objects likely to be worth it, rather than marking everything solid in the scene by hand:

using UnityEditor;
using UnityEngine;

public class AutoMarkOccluders
{
    const float minOccluderSize = 3f; // meters, along the largest bounds axis

    [MenuItem("Tools/Auto-Mark Large Objects As Occluders")]
    static void MarkLargeObjects()
    {
        int marked = 0;

        foreach (Renderer renderer in Object.FindObjectsOfType<Renderer>())
        {
            Vector3 size = renderer.bounds.size;
            float largestAxis = Mathf.Max(size.x, size.y, size.z);

            if (largestAxis >= minOccluderSize)
            {
                GameObject go = renderer.gameObject;
                StaticEditorFlags flags = GameObjectUtility.GetStaticEditorFlags(go);
                flags |= StaticEditorFlags.OccluderStatic;
                flags |= StaticEditorFlags.OccludeeStatic;
                GameObjectUtility.SetStaticEditorFlags(go, flags);
                marked++;
            }
        }

        Debug.Log("Marked " + marked + " objects as occluders (largest axis >= " + minOccluderSize + " m).");
    }
}

Running this over a street scene with 340 total renderers, where only the buildings and boundary walls are large enough to matter, prints something like:

Marked 27 objects as occluders (largest axis >= 3 m).

Only after marking do you actually bake, from the same Occlusion Culling window's Bake tab. Once baked, walking the camera through the scene and watching the Frame Debugger shows draw calls disappearing entirely for objects around a corner or behind a wall the camera cannot see past — those objects never reach the GPU at all for that frame.

12. Distance Culling Per Layer

LOD reduces an object's detail as it gets farther away; frustum and occlusion culling remove objects the camera cannot see at all. There is a third, much blunter tool that sits alongside both: simply refusing to draw entire categories of object past a fixed distance, regardless of screen size or visibility. A camera's layerCullDistances sets exactly that — a separate draw-distance cutoff per layer (the same layer system used for physics collision matrices and raycasting), so small props can vanish at 30 meters while trees stay visible out to 100, without touching LOD settings on either one.

using UnityEngine;

public class SetupLayerCullDistances : MonoBehaviour
{
    public Camera cam;

    void Start()
    {
        float[] distances = new float[32]; // one slot per Unity layer, 0-31

        distances[LayerMask.NameToLayer("SmallProps")] = 30f;
        distances[LayerMask.NameToLayer("Trees")] = 100f;
        // any layer left at 0 falls back to cam.farClipPlane instead

        cam.layerCullDistances = distances;
        cam.layerCullSpherical = true; // distance from camera position, not view-plane depth
    }
}

The difference between layerCullSpherical = true and the default false matters near the edges of the screen: the default measures distance along the camera's forward axis only (view-plane depth), so an object far to the side but close in that forward-axis sense can be treated as "near" even though its actual distance from the camera is much larger. Spherical culling measures true straight-line distance instead, which is more accurate but costs a little more CPU per object to compute — worth it for a cutoff that needs to look consistent across the whole screen, not just dead ahead.

This tool is intentionally crude compared to LOD — there is no fade, no simplified mesh, just present or absent — which is exactly why it fits categories where a hard cutoff is acceptable or even desirable: small clutter that the player was never going to focus on anyway, distant background trees a fog effect will hide regardless, or debug-only gizmos that should never appear in a build at all.

13. Reading the Frame Debugger: Finding Why a Batch Broke

Every technique in this chapter can silently stop working the moment one small detail changes — a script touches .material instead of .sharedMaterial, a prop gets baked lighting that differs from its neighbors, someone bumps its scale negative on one axis. The scene still renders correctly, so nothing looks wrong — it just quietly costs far more draw calls than it should. The Frame Debugger (Window > Analysis > Frame Debugger) is the tool for catching that.

A practical workflow for tracking down a broken batch:

• Open the Game view's Stats overlay first, as a cheap sanity check — note the total batches and SetPass call count before you go looking for a specific problem.
• Open the Frame Debugger and press Enable while the game is running (or paused on a representative frame).
• Step through the draw call list one entry at a time using the arrow buttons, watching the Game view update to show exactly what that single draw call rendered.
• Find a run of objects you expected to be one batch, and see where the count of draw calls jumps up instead of staying flat.
• Click the draw call right after the jump and read the right-hand panel — it names the specific reason that draw call could not join the previous batch.

That right-hand panel's wording maps directly onto the sections in this chapter:

A worked trace of the process: stepping through a street scene, draw calls 12 through 27 all show "Static Batch (16 renderers)" — good, that whole cluster of rocks merged as expected. Draw call 28 is a plain, unbatched draw call for a single rock, and the panel reads "Renderers have different materials." Selecting that one rock in the Hierarchy and checking its Inspector shows its Material slot pointing at "Rock_Mat (Instance)" instead of the shared "Rock_Mat" every other rock uses — a script had called renderer.material.color = tint; on it at some point, silently forking off a private copy exactly as the warning in Section 3 describes. Swapping that line for a MaterialPropertyBlock call, as shown in Section 6, fixes it without losing the per-rock tint.

The single most common root cause behind a broken batch, across a real project, is the same one Sections 3 and 6 both warn about separately: something, somewhere, read .material instead of .sharedMaterial. It is worth searching a codebase for .material (excluding .sharedMaterial matches) as a first move whenever a scene's draw call count looks higher than it should.

14. Glossary

• Draw call — one CPU instruction telling the GPU to render a specific mesh with a specific material.
• SetPass call — a GPU pipeline state change (shader, textures, render state) that a draw call needs when the material differs from the previous draw call.
• CPU-bound / GPU-bound — describes which side of the frame budget is actually the bottleneck for a given scene; the fix for one does little for the other.
• Static batching — combining the meshes of never-moving objects that share a material into one buffer, once, ahead of time.
• Dynamic batching — automatically merging small, moving meshes that share a material into a combined buffer, rebuilt every frame.
• GPU instancing — sending one mesh to the GPU once, plus a list of per-instance transforms, and drawing every copy in a single call.
• SRP Batcher — a URP/HDRP feature that caches per-material data on the GPU, cutting the CPU cost of each draw call without necessarily reducing the draw call count.
• MaterialPropertyBlock — a set of per-draw-call override values (like a color) that does not create a new material and does not break batching.
• Texture atlas — several smaller textures packed into one larger sheet, letting objects that use them share a single material.
• LOD (Level of Detail) — keeping multiple versions of a mesh at different detail levels and switching between them based on screen presence.
• Screen-relative height — the fraction of the screen's vertical height an object's bounding box currently occupies; the value an LODGroup switches on.
• View frustum — the truncated pyramid of space a camera can see, bounded by a near plane, a far plane, and four side planes.
• Frustum culling — skipping objects entirely outside the camera's view frustum, automatic and unbaked.
• Occlusion culling — skipping objects inside the frustum but fully hidden behind something closer, using precomputed (baked) visibility data.
• Occluder / occludee — an object that can hide others (occluder) versus an object that can itself be hidden (occludee), the two flags used when baking occlusion data.
• Layer cull distance — a per-layer draw-distance cutoff set through Camera.layerCullDistances, independent of LOD or the camera's overall far clip plane.
• Frame Debugger — a Unity window that steps through a single frame's draw calls one at a time and explains why any two of them did not batch together.

15. Exercises

using UnityEngine;

public class InstancedRockField : MonoBehaviour
{
    public Mesh rockMesh;
    public Material rockMaterial; // "Enable GPU Instancing" checked
    public int rockCount = 500;

    Matrix4x4[] matrices;

    void Start()
    {
        matrices = new Matrix4x4[rockCount]; // 500 fits under the 1023 limit, one call is enough

        for (int i = 0; i < rockCount; i++)
        {
            Vector3 pos = new Vector3(Random.Range(-40f, 40f), 0f, Random.Range(-40f, 40f));
            Quaternion rot = Quaternion.Euler(0f, Random.Range(0f, 360f), 0f);
            matrices[i] = Matrix4x4.TRS(pos, rot, Vector3.one);
        }
    }

    void Update()
    {
        Graphics.DrawMeshInstanced(rockMesh, 0, rockMaterial, matrices);
    }
}

using UnityEngine;

public class TintedCrate : MonoBehaviour
{
    void Start()
    {
        Renderer r = GetComponent<Renderer>();
        r.material.color = new Color(Random.value, Random.value, Random.value);
    }
}

using UnityEngine;

public class TintedCrate : MonoBehaviour
{
    static MaterialPropertyBlock block;

    void Start()
    {
        if (block == null) block = new MaterialPropertyBlock();

        Renderer r = GetComponent<Renderer>();
        Color randomTint = new Color(Random.value, Random.value, Random.value);

        block.SetColor("_Color", randomTint);
        r.SetPropertyBlock(block);
        // r.sharedMaterial is never touched, so all 200 crates still
        // point at the exact same Material asset and stay batchable.
    }
}

fovRad = 50 * (pi / 180) =~ 0.8727 rad
tan(fovRad / 2) = tan(0.4363) =~ 0.4663

distance = objectHeight / (2 * screenRelativeHeight * tan(fov/2))

LOD1 distance    =  8 / (2 * 0.25 * 0.4663)  =  8 / 0.23315   =~  34.31 m
culled distance  =  8 / (2 * 0.03 * 0.4663)  =  8 / 0.027978  =~ 285.90 m