You scattered 200 free GLB street lamps down a level, ticked Enable GPU Instancing on the material, and the frame time didn't move. That's not a bug in your import — GPU instancing is a no-op under Unity's default URP setup. The SRP Batcher takes priority over GPU instancing, and once a shader is SRP Batcher-compatible (every URP/Lit shader is, by default), Unity batches through that path instead and quietly ignores the instancing checkbox. Checking the box doesn't error, doesn't warn you, and doesn't do anything.
Why the checkbox lies to you
GPU instancing and the SRP Batcher solve the same problem — too many draw calls — with different mechanics, and Unity only runs one per material at a time. The SRP Batcher batches by shader variant: any number of materials using the same URP shader get combined into fewer batches, regardless of mesh. GPU instancing batches by mesh+material identity: it needs the *exact same* mesh and *exact same* material repeated many times. When both are available, URP's render pipeline checks SRP Batcher compatibility first, and if the material qualifies (it almost always does with `Universal Render Pipeline/Lit`), instancing never gets evaluated.
This matters specifically for GLB imports because glTFast and UnityGLTF both generate URP/Lit materials by default. Every prop you drop in from a free 3D catalog is SRP Batcher-eligible out of the box, so the "Enable GPU Instancing" checkbox you see in the material Inspector is functionally decorative unless you go out of your way to disable SRP batching for that draw path.
What actually changes draw calls
Open Window → Analysis → Frame Debugger and step through a scene with 200 instances of one lamp. Under URP with SRP Batcher on (the default), you'll typically see one SRP Batch covering all 200 — already close to optimal, because the batcher only pays a per-material-property-change cost, not a per-object one. Turning on GPU instancing on top of that changes nothing, because the SRP Batcher already claimed the draw path.
The case where instancing actually wins is narrower than most tutorials imply: hundreds to thousands of *identical* mesh+material pairs where even the SRP Batcher's per-batch overhead becomes the bottleneck, or where you're drawing procedurally from code (terrain grass, particle-driven props, crowd fill) without individual GameObjects at all. Below roughly 50–100 instances, the setup cost of a separate instancing path isn't worth it — the SRP Batcher already handles it.
| Technique | Batches by | Works with URP default | Best for |
|---|---|---|---|
| SRP Batcher | Shader variant | Yes, on by default | Mixed materials, moderate object counts |
| GPU Instancing | Identical mesh + material | Only if SRP Batcher is bypassed | Thousands of identical props, procedural draws |
| Static batching | Combined mesh, build-time | Yes | Non-moving props, disables instancing on the object |
Forcing real instancing when you need it
If you're placing thousands of identical props (a forest of the same tree, a field of the same rock) and profiling shows the SRP Batcher's overhead is still the bottleneck, skip GameObject-based instancing entirely and draw directly:
```csharp
// Bypasses SRP Batcher path; draws N copies of one mesh+material in one call
Graphics.RenderMeshInstanced(renderParams, mesh, 0, matrices);
// matrices: Matrix4x4[] of per-instance transforms, max 1023 per call (pre-2022.2)
```
`RenderParams` carries the material and layer; you build the `Matrix4x4[]` array once from your scatter positions and reuse it. This sidesteps SRP Batcher comparison entirely because there's no per-object Renderer component for it to batch.
Gotchas
Static batching silently disables instancing on any GameObject it successfully combines — check the Static flag on your scattered props before assuming instancing is active. Per-instance color or property variation (tinting individual lamps) requires `MaterialPropertyBlock` set through `MaterialPropertyBlock`-aware shaders; setting `.material` directly on each instance breaks both SRP batching and instancing by creating unique material instances. And on mobile GPUs, instancing's per-draw setup cost can exceed the savings below a few hundred instances — profile on-device, not in the editor.
If your imported GLB uses a custom or Shader Graph material instead of stock URP/Lit, confirm it actually exposes the Enable GPU Instancing toggle in the Inspector at all — shaders without instancing variants compiled in won't show the checkbox, which is a faster diagnostic than digging through the Frame Debugger. Mismatched import scale from Blender-exported GLBs (covered in our Unity 6 pink materials and scale fix) also throws off matrix math if you're building instance transforms by hand — normalize scale on import first.
For scattering assets at scale, pulling props programmatically instead of dragging them in one at a time is worth the setup; see our walkthrough on automating GLB downloads through the REST API. And if you're tracking Unity's runtime changes that touch batching behavior going into next year, we cover what's shifting in Unity 7's CoreCLR swap.
A prop like the Lo-Fi Street Lamp is a good stress test for this — identical mesh, identical material, exactly the repeated-instance case instancing exists for. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships — see pricing.
Run the Frame Debugger on your own scene before changing anything. If you see one SRP Batch already covering your scattered props, GPU instancing has nothing left to win — the checkbox was never going to help.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*