Physics.ComputePenetration() is buggy with capsules

hi,
First of all, thank you *so* much for exposing this much-needed functionality

Unfortunately I think there's a bug in ComputePenetration() when used with capsules. I'm colliding a capsule vs a bunch of convex meshes, and am experiencing a lot of "ghost" collisions where the query returns a positive collision result despite the capsule not touching the mesh.

Switching from a capsule to a sphere fixes these problems completely, suggesting that the issue is with the capsule (rather than a bug in my code).

I've attached a screenshot -- here you can see the capsule standing in mid-air, because it thinks it's colliding with one of the meshes below it. (It's definitely *not* colliding in reality, sorry if the camera angle isn't ideal)

Please let me know what else I can do to help.

Thanks,
Raigan

 

Hi, I have the same problem in my nights and weekends project.

After trying to figure out where this was coming from for 2 days now, it looks like the Center property of capsule colliders (will test boxes and spheres as well) isn't respected when rotation isn't set to identity. I should have a reasonable test case in a few hours (after I clean up my debugging code) and upload it tonight or tomorrow.

 

I can confirm the same issue. I was scratching my head for a long time and I tried everything but the capsule collider doesn't seem to be working as intended.

 

It seems like the function is often returning inaccurate data right now.

- ComputePenetration can return false when called inside OnTriggerEnter for the 2 corresponding triggers
- ComputePenetration can keep returning false when called in OnTriggerStay, and 2 colliders are visually heavily overlapping

This should not really happen as it makes no sense.

You can test for yourself by making a static sphere trigger and dropping other sphere triggers with a rigidbody onto it. Depenetrate + set kinematic in OnTrigger methods and you'll notice the falling spheres end up in random inaccurate positions, when you'd expect them to look like they're sticking to the static sphere.

 

I'm still working on my little test project before I upload it to the bug checking (may just make a quick smaller one instead), but I was able to get a workaround for the moment:

* Zero out center before you call ComputePenetrate
* manually apply world-rotated center when you call the function.
* restore centers so collider(s) are in the same place if you need them for other purposes.

It's something to consider if people want to make some progress on whatever it is they're doing until a fix shows up. Otherwise, you really can't use capsule centers unless you don't rotate, the results just get completely nonsensical.

 

I've put in my own bug report. Case # 866670.

 

Just spent a few hours wondering what I was doing wrong (weird capsule penetration results against corners of convex mesh colliders), and it appears I have encountered this problem too. There's definitely a good chance this is an actual bug

 

Also encountered problems with Physics.ComputePenetration when the involved colliders are not centered on their game object's origin and the game objects have scales and/or rotations. Tried out your suggestion in a dummy project and it seems to work perfectly for all the 3D collider types except the TerrainCollider, which has some issues.

I attach a dummy project where I tested it, in case it helps someone else (tested in Unity 5.6.0b9). Also, before I found this post, I asked about this in Unity Answers.

Thanks.

EDIT: I'm having trouble updloading the project file. Will try again later.

 

I may have discovered another issue, I'll confirm it's still a problem in beta 11.

It seems that the same ComputePenetration() calls (number and input) show worse performance when called in FixedUpdate() vs Update(), I will look into rigging up an example project if this is still the case. I noticed it a few weeks ago in beta 9 but I've been crunching on a day job project for a while.

 

Looks like the FixedUpdate performance scaling issues are still there in 5.6.0f1 beta,
I submitted a specific minimum repro project. Case #894183

 

Thanks for letting us know the status!