- Home /
Compute Penetration with off-center colliders
I'm trying to use the newly exposed ComputePenetration function in Unity 5.6.0b9. It seems to work as expected when the involved colliders are centered on the game object's origin, but I'm getting strange results when testing with colliders that are not centered in their object's origin when the object has a rotation and a scale.
The image below shows one of the situations where Physics.ComputePenetration doesn't seem to work. The yellow line shows the depenetration direction using the center of the collider and the red line shows the depenetration direction using the transform position of the collider (as shown in the Unity Docs).
Find the whole setup in a Unity Package here.
I have updated the attached unity package with the fix I mentioned in my reply.
Having problems in 2017.1 f0 with this. Not fixed vs tall level colliders which are offset from y = 0
Answer by oscarlosu · Mar 13, 2017 at 11:38 AM
Followed a suggestion in the Unity Forums by @recursive and got good results. The idea is this:
Save collider centers
Set collider centers to zero
ComputePenetration with extracted center positions (they are in local space in the collider)
Reset collider centers
This should probably be done internally by Physics.ComputePenetration, but it seems to be a good fix for now. I have tested it with all the 3D collider types and it seems to work, with the exception of the TerrainCollider.
This issue has been confirmed as a bug, to be fixed in the next released version of Unity.
having the same issue. glad to see it's a bug and not me going crazy. decided to resolve by generating convex mesh colliders, but will follow the @recursive workaround if I run into any issues.
do you have a tracking number for the bug report?
It wasn´t made into a new ticket because they were already aware of the problem. It is supposed to be fixed now in 5.6, although I haven't verified myself. I did however discover the same problem with the relate method Collider.ClosestPoint(Vector3 position). Likely also an issue with Physics.ClosestPoint(...).