# Collision.Impulse is sometimes reversed

I’m seeing some odd behavior with Collision.Impulse that I don’t understand. In short, it seems that the force direction is often the reverse of the direction I expect.

For example, I have a “shattering” behavior where an object “breaks” into pieces when it’s hit by a strong collision. I then impart some of the collision force onto the nearby fragments. For example, here the cube just hit the wall. Most of the pieces are now falling, and some of the pieces have been pushed back:

To get the force involved in the collision, I’m access collision.impulse. But often, I’m finding that the value is in the exact opposite direction of what I’d expect. For example, here’s some log output of various times launching this cube into the wall with the same force applied each time:

Impulse from Block1 is (0.0, 0.0, -89254.3)
Impulse from Block1 is (0.0, 0.0, 89254.3)

I don’t understand why the Z component is sometimes about 90,000, and other times it’s -90,000. In both cases I’m looking at this from an OnCollisionEnter event that exists on the wall, which has a kinematic rigidbody on it.

I could maybe understand the issue if the block were significantly penetrating the wall on impact, and Unity couldn’t decide whether it should exit to the front or rear of the wall. But the block doesn’t penetrate the wall at all.

Anyone have any idea why collision.impulse is often reversed like this?

2 Likes

Hello! Did you solve this problem? I have the same, my impulses are looking reversed sometimes… Like this:

No, I never got an answer or figured out what was going on with that. But I ended up with a different solution to my problem.

The thing I was trying to do was to allow the heavy block to keep moving forward as it broke through the wall. That was difficult, because the wall was initially a kinematic rigidbody, so the block lost all of its velocity upon hitting the wall. I tried to use collision.impulse to reapply the same force to the block, to keep it moving, but that was giving the weird results.

So, the approach I took was to look at the relativeVelocity on the collision, and assign that velocity to the block. I actually reduce it a little bit, to simulate it losing some speed from the collision. It’s not exactly accurate or realistic, but it looks fine.

So, maybe look at collision.relativeVelocity?

1 Like

Order of collision is not guaranteed, basically who hits who first? It is better to use relative velocity where possible, this will tell you how fast something was hit, then use mass.

Thanks. That’s a really simple way to understand this. I probably got hung up on the idea that one object was moving, and the other was stationary. But I get what you mean about not being able to predict the order that the physics system will resolve the collisions, or from which object’s perspective. Glad I ended up using relativeVelocity, as you recommended.

I understand that order can be different. but I think that contact.firtstCollider and otherCollider should show me this information to understand the impulse direction. without this information impulse is unusable at all

I have the same issue. anyone got solutions? thank you

2 Likes

It is 2023 now and they still don’t seem to be interested in solving this problem.
RelativeVelocity seems to be useful when OnCollisionEnter.
But when OnCollisionStay is called, relativeVelocity is 0, so in this case, relativeVelocity is not useful for correcting the direction of the Impulse.
I dont know what i can do then.

Contact points tell you the normal of the contact (that is, the direction), which collider is the “first” one and which one is the “other” one. The impulse is applied along the normal direction, there’s no need to use relativeVelocity here.

I don’t think there’s anything missing? You should always be able to work out the impulse direction using the normal.