GPU Instancing on a skinned-mesh material can never take effect

Skinned meshes don’t go through the GPU Instancing path. Each SkinnedMeshRenderer is skinned and drawn on its own, however many identical copies exist — twenty of the same enemy is twenty draws. So Enable GPU Instancing on a material used only by skinned meshes does nothing, and under URP/HDRP it does something slightly worse than nothing: the flag also drops that material out of the SRP Batcher.

What the scan looks at

Across the loaded scene(s): materials with GPU Instancing enabled that have at least one SkinnedMeshRenderer user and zero MeshRenderer users. If any MeshRenderer uses the material, instancing might legitimately batch those, so the rule stays quiet.

The fact holds under the Built-in pipeline too — instancing still doesn’t apply to skinned rendering — the SRP Batcher clause is just added on top when the project is on an SRP.

Why it shows up

This is the other half of the blanket “tick Enable GPU Instancing on every material” pass (the first half being MAT004). Character and creature materials are exactly what such a pass lights up, and they’re the ones where it can never pay off.

How to fix it by hand

Untick Enable GPU Instancing on those materials. If you actually need many copies of a skinned character rendered cheaply, instancing on the material isn’t the mechanism — the options are:

• Bake animation to vertex textures / use an animation-instancing package, which turns the crowd into non-skinned instanced meshes.
• Swap distant characters for non-skinned LOD proxies, which can instance.
• Reduce the number of concurrently visible skinned renderers with culling and LOD groups.

What PerfLint does about it

Report-only, at Info, and no bulk action. The same material could be placed on non-skinned meshes in another scene, a prefab, or at runtime — a scene walk cannot see those, so switching the flag off in bulk could regress a case the scan never observed. The finding names the materials so the review is a minute’s work.