Peculiar multiple-rigidbody-trigger problem.

I have a simple test situation boiled down from a problem I'm having.

Two game objects, Cube1 and Cube2. Each of Cube1 and Cube2 are built from the model following.

Each has a child... CubeChild1 is a child of Cube1, and CubeChild2 is a child of Cube2.

Cube1 and Cube2 have rigidbodies, each with gravity turned off.

CubeChild1 and CubeChild2 each have a box collider that is in trigger mode. There are no other colliders.

Cube1, Cube2, CubeChild1, and CubeChild2 each have a common script "SimpleOnEnterTrigger" as below:

using UnityEngine;
using System.Collections;

public class SimpleOnEnterTrigger : MonoBehaviour 
    void OnTriggerEnter(Collider collider)
        Debug.Log( + " . OnTriggerEnter (" + + ")");


To reiterate the point, Cube1 and Cube2 (including children) are identical except for naming, and the naming is just so the debug outputs distinctly.

On running the scene, I drag Cube1 cube on top of Cube2. I get the following output:

CubeChild1 . OnTriggerEnter (CubeChild2)
Cube2 . OnTriggerEnter (CubeChild1)

It is strange enough already -- there is an asymmetry. CubeChild1 is getting the collision message in the one direction, but CubeChild2 is not! Instead, the message ends at the parent, Cube2.

When I run the scene again, but move Cube2 on top of Cube1, I get exactly the same debug output. This is consistent in the sense that it should not matter which Cube is being moved.

I would have expected that the results would be symmetric. Either the messages would both end up going to the nearest parent gameobject containing a rigidbody, or (and this seems to make more sense) the messages would go to the gameobject containing the trigger.

Using kinematic rigidbodies doesn't seem to make any difference.

Why the asymmetry?

Its not a matter of filtering the colliders in OnTriggerEnter, which I knew I'd have to do. All the expected messages get sent, but just to unexpected places.

This comes up in a practical situation. I have a vehicle with a rigidbody (and, full disclosure, actual non-trigger colliders), which also needs to carry around some trigger volumes with it. It will interact with other such vehicles, and I need to identify when these trigger volumes interact with the partners. This is the boiled-down version to illustrate.

If a Unity developer doesn't know for sure, then I don't know how any of us can be expected to understand compound trigger parenting. However, the solution to your problem should be to add kinematic rigidbodies everywhere you have triggers; when I do this, I get predictable messages sent, on those kinematic game objects (instead of their parents). The parents can still have non-kinematic rigidbodies.

Also, you don't need to use System.Collections if you're not utilizing coroutines in a script, and .name is a property of Unity's Object. Therefore, your script can be condensed to

using UnityEngine;

public class SimpleOnEnterTrigger : MonoBehaviour  {

void OnTriggerEnter (Collider collider) {
    Debug.Log(name + " . OnTriggerEnter (" + + ")");


For the record, the workaround I came up with is to put a script in the GameObject with the rigidbody as well (in this case, Cube1 and Cube2) whose purpose is only to pass on the OnTriggerEnter to a relevant child object's version of OnTriggerEnter, for specific processing. This actually works in both the variations I tried and in the practical situation, though I don't know if there are as yet unseen holes.

However, this is somewhat unsatisfying, as you don't know, for example, when the message arrives at Cube1, what trigger in a child of Cube1 is involved (if it has multiple children with triggers). You do know the other collider involved, so this might be enough to deduce where the message is to go.

(Remember, the point here isn't that the messages are getting lost, but they're being sent to the trigger gameobjects sometimes, and a parent rigidbody in the same hierarchy at other times).

I'm sure other people have come up with different ways of trapping the various places messages could end up, and rerouting the messages.

However, Jesse's answer of adding a kinematic rigidbody with every trigger seems the most robust and general, and I'm going to start there.

Someday I may see whether message rerouting (if I can make trapping and rerouting messages robust) or extra kinematic rigidbodies is more CPU intensive.