# A trigger collider in Unity doesn't allow the player to pass through

It's my understanding that checking "Is Trigger" on a collider should allow rigid bodies to pass through without collision prevention, but my trigger isn't doing that consistently. The player cannot pass through, but other objects can.

The trigger is a cube primitive with "mesh rendered" unchecked so that the cube won't be visible. The cube has a box collider with "is trigger" checked, and also a script. The script currently doesn't do anything except output from Debug.Log in OnTriggerEnter() as a test.

Primitives are able to pass through. The test is just a basic Unity sphere with all the default settings, including a sphere collider. The only change was that I added a RigidBody.

Imported models also pass through. I have a simple .blend model with a rigid body and box collider.

The player does not pass through. The main difference between the player's object and the other imported model is that the player is using a custom mesh collider which is different than the player's rendered mesh. The rendered mesh is the game object and the low-poly collision mesh is a child of that object.

I've tried several variations, including switching the player from a mesh collider to a box collider, and also moving the box collider to the main mesh rather than a child mesh, but the results are the same. The player stops moving as soon as he hits the location of the trigger's box collider.

Any ideas are appreciated. Thanks in advance.

Here's a screenshot of the scene layout, with the invisible trigger collider selected.

Also pictured is the hierarchy showing that the trigger collider ("Jump Pad Trigger") has no children. On the right is displayed every component that the trigger object has. I've also moved the collider from its original location several times to prove that it's not another object in the scene that the player is colliding with.

• Indeed, a rigidbody can avoid collisions, but not triggers, if a collider's hasTrigger is activated (true), and if they are set to collide on the collision's matrix. It would be good if you shared your scene layout, maybe there is another object on the same position where the collider is collisionable, or maybe the trigger mesh has a child object that is collisionable. – LifGwaethrakindo Mar 25 '18 at 20:22
• @LinkWindcrafter: Thanks, I've updated the answer. – Nightmare Games Mar 26 '18 at 1:21
• Ordinarily a body should pass right through a trigger, as you say. So if could be a script on the player or on the trigger is reacting to the trigger overlap and preventing movement. Can you show us the contents of this JumpPad script, and any movement scripts being used on your player? It's also possible that it's coincidence, and the player is getting snagged on the edge of some non-trigger collider that just happens to sit near the trigger boundary. – DMGregory Mar 26 '18 at 1:28
• @DMGregory: Yeah, it was the car script. Thanks again! – Nightmare Games Mar 26 '18 at 5:04

It was in the car's movement code.

Even though trigger colliders can be passed through, raycasting into them apparently still fires off the moving object's collision handlers (depending on your physics settings). Good to know.

I figured it out when I tried driving backward through the trigger and it worked fine.

I had a bit of old code in my vehicle's movement script to mitigate some weird physics behaviors during head-on collisions only.

  void OnCollisionEnter ()
{
check_forward_collision ();
}

void OnCollisionStay ()
{
check_forward_collision ();
}

void check_forward_collision ()
{
bool collision_front = false;
Vector3 ray_start = transform.position + new Vector3 (0f, .5f, 0f);

collision_front = Physics.Raycast (ray_start, transform.forward, 3f);

if (collision_front && forward_speed > .3f)
{
forward_speed = .3f;  // <-- THIS LINE
}
}


When the player would continue pushing forward against a wall with the button held down, the car would sometimes climb the side of the wall or drive underneath it. This function would raycast forward and reduced the player's speed if the hit was directly in front.

This old code was apparently getting fired off by the trigger collider. I don't need it any longer, since I fixed those physics problems a different way.