GDKB

Collision vs Trigger

Intermediate20 Minutes readUpdated July 21, 20263 related concepts

A collision is a physical overlap between two objects that the physics engine actively resolves — pushing them apart, stopping motion, applying an impact response — so they can't pass through each other. A trigger is an overlap the physics engine only *detects and reports*, without any physical response — objects pass straight through, and code decides what, if anything, should happen. Both are detected through the same underlying shapes (colliders), but one produces physical resolution and the other produces a notification.

On this page

Collision vs Trigger

Summary

A collision is a physical overlap between two objects that the physics engine actively resolves — pushing them apart, stopping motion, applying an impact response — so they can't pass through each other. A trigger is an overlap the physics engine only detects and reports, without any physical response — objects pass straight through, and code decides what, if anything, should happen. Both are detected through the same underlying shapes (colliders), but one produces physical resolution and the other produces a notification.

Why This Matters

A wall needs to physically stop the player from walking through it — a collision. A quest marker that should notify the game when the player walks into its radius should not stop the player from moving through that space at all — a trigger. Using collision where a trigger was needed would make the player bounce off an invisible quest marker; using a trigger where collision was needed would let the player walk straight through a solid wall. The distinction exists because "detect an overlap" and "physically respond to an overlap" are genuinely different requirements, and conflating them produces exactly these kinds of bugs.

Mental Model

A collision is a locked door; a trigger is a motion-sensor mat. Walking into a locked door physically stops you — you cannot proceed until something changes. Walking over a motion-sensor mat doesn't stop you at all — you walk straight across it, but the mat still notices you were there and can set off an alarm, open a different door, or log the event. Both "notice something arrived" — but only one of them also physically blocks it.

Core Explanation

  • A collider defines a physical shape used for overlap detection, regardless of collision or trigger mode. The same box, sphere, or mesh collider component can act as either — the is trigger flag is what determines which behavior applies, not a fundamentally different component.
  • Collision produces a physical response; trigger produces only a notification. A collision overlap causes the physics engine to push the objects apart (or stop them) and typically fires a "collision entered" callback; a trigger overlap causes no physical response at all and fires a separate "trigger entered" callback instead.
  • At least one of the two overlapping objects usually needs a Rigidbody/physics body for either kind of event to fire. A purely static, non-physics object overlapping another purely static object typically won't generate collision or trigger callbacks at all — physics engines generally require at least one side to be dynamic.
  • Triggers are for detection-and-react logic; collisions are for physical simulation. Pickups, quest zones, and damage-over-time areas are naturally triggers; walls, floors, and solid characters are naturally collisions.

Syntax / Theory

C# (Unity)

csharp
public class Wall : MonoBehaviour
{
    void OnCollisionEnter(Collision collision) // Physical overlap — resolved automatically.
    {
        Debug.Log($"{collision.gameObject.name} collided with the wall.");
    }
}
csharp
public class CoinPickup : MonoBehaviour
{
    void Start() => GetComponent<Collider>().isTrigger = true; // No physical response.

    void OnTriggerEnter(Collider other) // Detection only — the player passes through.
    {
        if (other.CompareTag("Player"))
            Collect();
    }
}

C++ (Unreal)

cpp
void AWall::NotifyHit(UPrimitiveComponent* MyComp, AActor* Other, /*...*/)
{
    // Collision — physically resolved by the physics engine already.
}

void ACoinPickup::NotifyActorBeginOverlap(AActor* OtherActor) // Trigger-equivalent.
{
    // Overlap only — OtherActor passed through, no physical response.
}

Unreal distinguishes "Block" (collision, physically resolved) from "Overlap" (trigger-equivalent, detection only) via each component's Collision Response settings — the same underlying two-behaviors-from-one- shape model as Unity's isTrigger flag, expressed with different naming.

Unreal Blueprint

On Component Hit (Block/collision) and On Component Begin Overlap (trigger-equivalent) are the corresponding Blueprint event nodes, matching OnCollisionEnter/OnTriggerEnter in C#.

Practical Example

A damage zone (lava, a hazard area) needs to detect the player entering without physically blocking them from walking through it.

csharp
public class LavaZone : MonoBehaviour
{
    void Start() => GetComponent<Collider>().isTrigger = true;

    void OnTriggerStay(Collider other) // Fires every frame the overlap continues.
    {
        if (other.TryGetComponent<Health>(out var health))
            health.TakeDamage(damagePerSecond * Time.deltaTime);
    }
}

The player visually walks into the lava's collider shape — a trigger, by design, applies no physical push-back — while still reliably triggering damage for as long as the overlap continues.

Common Mistakes

  • Leaving isTrigger off for something meant to be a detection-only zone. A quest marker or pickup left as a solid collider physically blocks the player instead of letting them walk through it and be detected.
  • Expecting a trigger to physically stop movement. A trigger, by definition, never produces a physical response — code that relies on OnTriggerEnter to also block movement needs to add that stopping logic itself; the physics engine won't do it automatically.
  • Forgetting that at least one overlapping object typically needs a Rigidbody/physics body. Two purely static colliders overlapping often produce no callback at all, a common and confusing source of "why isn't my trigger firing" bugs.
  • Using OnTriggerEnter when OnTriggerStay (or vice versa) is actually needed. A one-time pickup should react on Enter; continuous damage-over-time needs Stay, since Enter fires only once per overlap begin, not repeatedly while the overlap continues.

Game Development Example

A level combines both collision (for solid geometry) and triggers (for interactive zones) working together naturally in the same space.

csharp
public class DoorTrigger : MonoBehaviour
{
    [SerializeField] private Animator doorAnimator;

    void Start() => GetComponent<Collider>().isTrigger = true;

    void OnTriggerEnter(Collider other)
    {
        if (other.CompareTag("Player"))
            doorAnimator.SetTrigger("Open");
    }
}

The door's own frame is a solid collision collider (the player can't walk through the door itself), while a separate, larger trigger volume in front of it detects the player's approach and opens it — two different collider purposes cooperating in the same scene.

Best Practices

  • Decide up front whether a given object needs physical resolution (collision) or detection-only (trigger), and configure the collider accordingly — don't default to one out of habit.
  • Use Enter/Exit callbacks for one-time reactions and Stay callbacks for continuous effects, matching the callback to the actual desired behavior.
  • Remember at least one side of an overlap typically needs a physics body for either kind of callback to fire, and verify this first when a collision or trigger event isn't firing as expected.
  • Keep collision (physical) and trigger (detection) responsibilities on separate, clearly-named colliders when an object needs both, rather than toggling one collider's mode back and forth.

Exercises

  1. Build a solid wall using a normal (non-trigger) collider and a separate coin pickup using a trigger collider, and confirm the player physically stops at the wall but passes through the coin while still triggering collection.
  2. Take the LavaZone example and change OnTriggerStay to OnTriggerEnter, then describe how the damage behavior changes for a player standing still inside the lava.
  3. You're designing an enemy that should physically block the player from passing through its body, but also needs a larger "detection radius" that notices the player approaching from a distance. Decide how many colliders this enemy needs and what mode each should be in, and justify the design.
  4. Research why most physics engines require at least one of two overlapping objects to have a dynamic Rigidbody for collision/trigger callbacks to fire, and explain what performance problem this requirement helps avoid.
  • Components — collision and trigger behavior both come from a collider component attached to a game object; understanding components as attachable capability is the necessary foundation.
  • Events — collision and trigger callbacks (OnCollisionEnter, OnTriggerEnter) are themselves a form of event notification, following the same "something happened, interested code reacts" pattern.
  • Prefabs — interactive trigger zones (pickups, doors, hazard areas) are frequently built and reused as prefabs, sharing consistent collider configuration across many placed instances.

Further Reading

Related Concepts