Diagnosing and Fixing Crowd Performance in a Unity/WebGL Third-Person Game

Starting the Investigation

The existing CharacterPerson NPC controller already had performance-conscious architecture:

• Coroutine-based patrol logic instead of per-frame Update() polling.
• Pooled WaitForSeconds instances to eliminate garbage collection churn.
• Animator.cullingMode = CullCompletely to skip animation evaluation off-screen.
• Custom distance-based AI LOD reducing NavMeshAgent obstacle-avoidance quality and patrol frequency for distant characters.

None of that explained the sluggish frame rate. Rather than assuming the existing LOD system was broken, the first step was pulling up the Unity Profiler’s CPU Usage and Rendering modules to observe where frame time was actually spent.

Root Cause #1: LOD Culling Wasn't Actually Culling

Inspecting the LODGroup on the character prefab revealed a critical flaw: LOD 3's transition was set to 0%. This meant there was no “Culled” region below it.

In a normal LOD pipeline, once a character's on-screen size drops below the last threshold, Unity disables the renderer entirely (zero draw calls, zero cost). Here, because LOD 3 extended all the way to 0%, every character kept rendering its lowest-detail mesh forever, regardless of distance — even characters barely a few pixels tall near the camera's far clip plane.

Root Cause #2: Empty Renderers Paying Full Skinning Cost

After applying the culling fix, frame time improved noticeably. However, a new dominant cost surged in the profiler:

This pointed directly at mesh skinning overhead rather than general draw-call submission. Inspecting the character prefab explained why:

• Each NPC was constructed from a modular character system featuring 17 separate SkinnedMeshRenderer components (arms, chest, hair, hands, head, hip, legs, shirt, pants, shoes, accessory, hat, item, etc.), bound to a shared humanoid skeleton and swapped per LOD.
• Several slots (accessory, hat, item) were empty (0 triangles) on characters without those items equipped — yet their renderer components remained enabled.
• Each enabled component paid full per-frame tax: bone matrix computation, bounding volume updates, and skinning dispatches for non-existent geometry.
• Even at LOD 3 (445 total triangles), every character carried 17 renderer instances. In Unity, skinning and bounds overhead is driven heavily by renderer count, not just triangle count.

void Awake()
{
    _agent = GetComponent<NavMeshAgent>();
    _anim = GetComponent<Animator>();
    if (_anim == null) _anim = GetComponentInChildren<Animator>();
    if (_anim != null) _anim.cullingMode = AnimatorCullingMode.CullCompletely;

    // Disable renderer slots with no geometry (unequipped accessory/hat/item),
    // so they don't cost bone-matrix/bounds updates every frame.
    foreach (var smr in GetComponentsInChildren<SkinnedMeshRenderer>())
    {
        if (smr.sharedMesh == null || smr.sharedMesh.vertexCount == 0)
        {
            smr.enabled = false;
        }
    }
}

A Dead End Worth Including: Chasing a GC Hypothesis That Wasn't the Cause

Later in the same play session, two clearly separated stretches of frames revealed an alarming failure mode: sustained multi-frame CPU plateaus (30–66ms for multiple consecutive frames) rather than isolated spikes. These plateaus visually correlated with denser clusters of GC allocation activity in the profiler timeline.

On WebGL, where garbage collection cannot run incrementally like on desktop, this immediately appeared to be GC pauses. Rather than assuming and modifying code speculatively, the investigation rigorously validated the hypothesis:

Additional Optimization Pass: Rendering Setup & Build Size

Alongside crowd optimization, a broader hygiene pass was executed for WebGL load-time targets:

What This Investigation Demonstrates