Physics2D.Distance returns wrong result with circle-like capsule inside the box collider.

Unity Engine
,
1

Physics2D.Distance(Collider2D, Collider2D) returns wrong result with circle-like capsule collider that the width and height have the same value.

I wrote a simple script to visualize the result by Physics2D.Distance().
The cyan and magenta points are pointA and pointB, and the yellow arrow is normal * distance
It works correctly between regular capsule and box and simple polygon:

860×404 4.33 KB

But it didn’t work if the capsule degenerate to a circle in some particular angle and position:

736×444 3.29 KB

And I also tried with actual circle collider and box with exactly same position and rotation:

704×325 2.88 KB

The left one is circle collider, right is the capsule.
I thought both should have exactly same result.

btw, I found out that there was a report about capsule: Unity Issue Tracker - Physics2D.Distance returns incorrect distance between colliders
But it’s not the identical problem since my issue is only happens with circle-like capsule.
And it doesn’t make sense if the reason is “case is too complex”.

Case 1354786
Issue Tracker: Unity Issue Tracker - Physics2D.Distance returns zero when CapsuleCollider has a size of (0.1, 0.1)

2

You are also taking that issue out of context when you say “case is too complex”. For that issue, “case” was referring to iterations required and collider complexity to completely solve the overlap and not to do with project complexity or anything else. Just so you know, I’ll confirm that the issue you reference above has nothing whatsoever to do with your issue.

So for your report I can confirm that it’s related to the capsule being degenerate i.e. the width/height are identical (a circle) which results in the two vertex that make up the capsule being perfectly overlapping. This leads to degenerate edge/normal but due to floating-point precision, even a tiny change stops this happening so for instance, at the specified position at (0.1, 0.1) causes the issue but so does (1, 1) but (2, 2) doesn’t.

Because the physics engine cannot deal with such degnerate capsules, behind the scenes we take steps to force a tiny artificial separation. We chose to do this over just making it an error because we try to deal with it gracefully for you. By default we add a numerically significant offset (0.00001) to stop this degenerate case when it’s detected but in your report, it’s failing to do so correctly which is the bug and will be fixed. When dealing with such precision issues, we have to choose a threshold, you’ve found an edge-case where the threshold needs to be changed.

Thanks for the report, we’ll get that part fixed ASAP.

3

Thank you, massively, for this. And sorry you experienced it. I have had something similar with circles and perfect hexagons, but was never able to think through how to show it or what it exactly was that was going on.

It must have taken a lot of time and effort to cogitate about how to show this, and make an exact example, and been most disconcerting trying to figure out if you’re doing something wrong, or if it’s Unity.

Hope you can find a way around the issue whilst the bug fix is done.

`

How many more of these sorts of fudges exist, and is there a list of them, so when we observe unexpected oddities we can check against that list for possible reasons before fumbling around in the dark for days?

4

There is no problem with circles/polygons and this problem does not relate to that. These are not circle or polygons.

These are not fudges, it’s software engineering. For a capsule to be detected it has to exist as a line and a normal. Two overlapping points don’t form a line so are degenerate. We can choose to stop a dev using these or allow these by using the direction of the capsule as a guide to slightly extend it. I mean, have you looked at something like Box2D? There are compromises everywhere just like any other piece of software; this is engineering.

This is a bug and easily fixed.

I would also like to ask you to please not derail this thread as you have in the past.

5

Is there a similar fudge (software engineering) occurring between circles and polygons that could be causing a similar fail?

6

Ignoring the fact that your question is vague, this is not the thread to start your own discussion for your problem.

7

It’s exactly the same as above, with the only differences being that I’m using a circle collider in the middle, not a capsule, and an exact hexagon as the external shape. All other things the same.

8

What you are describing has nothing whatsoever to do with the problem above no matter how much you want it to be. As expected you are hijacking the thread. Last warning; if you have an issue then either create your own thread or report a bug.

9

Just so you know, I didn’t mean to say the old issue I reference above doesn’t make sense. it’s understandable for solving more complex polygon collision required more iterations.

I meant to say that issue is not my issue. And tried to raise a reason why I said that is not my issue because of my issue was not a complex case obviously. cuz I gueesed QA and devs could probably thought it’s identical issue with the above one, then ignore my issue. (actually QA did in mail at first.)

Thanks for replying the thread.
It’s really good to know the fix is in progress. I’m looking forward it.

1 Like
10

I’ve actually fixed the issue this morning so I’m just writing a bunch of tests for it now then I’ll create a PR and backports and get it queued.

Again, thanks for the detailed report.

1 Like