Weird issue (Bug??) Physics.OverlapCapsule.

Unity Engine
1 
var overlaps = Physics.OverlapSphere (bottomPosition, Radius, GetCollisionLayerMask (), QueryTriggerInteraction.UseGlobal);
var overlaps2 = Physics.OverlapSphere (topPosition, Radius, GetCollisionLayerMask (), QueryTriggerInteraction.UseGlobal);

var capsule = Physics.OverlapCapsule(bottomPosition, topPosition, Radius, GetCollisionLayerMask(),QueryTriggerInteraction.UseGlobal);
var capsule2 = Physics.OverlapCapsule(topPosition, bottomPosition, Radius, GetCollisionLayerMask(),QueryTriggerInteraction.UseGlobal);

I have having a weird scenario with overlap capsule on unity 2020.1.14f1.
in that specific scenario:

  • “overlaps” returns 2 collisions. [Collider1, Collider2]
  • “overlaps2” returns 1 collision.[Collider1]
  • “capsule” returns 1 collision[Collider1]
  • “capsule2” returns 1 collision [Collider1]

Visually in the scene both colliders are inside the actual capsule points.

Why is collider2 not being captured by the capsuleOverlap ? This seems really weird behavior since both spheres are “the caps of the capsule”.

Am I missing something really obvious on my setup ?
This seems really weird behavior, which I am quite confident was not happening on 2019.

2

Another weird update :

cebbzm

So that capsule is doing a Raycast that just renders a hit.
When you toggle the BoxCollider it momentarily detects the hit and then, just stops until I tick and untick again.

Whats going on here ?

3

Another Update.
Creating a new project solved the issue… in the Editor.
Now when play testing the game in Edito Mode, it works perfectly. But sadly, if build the game the issue is present at runtime.

Does anyone have an idea on what is causing this?

4

Search this forum. There are dozens of reports of this kind of OverlapSphere/Capsule behaviour, stretching back years. They’re too busy implementing their own half-baked physics engine to worry about their ancient bugs in existing code.

(Yes, I got here searching for solutions, it’s just so depressing)

5

But is that true? You do know that the 2D physics (Box2D) and 3D physics (PhysX) are different devs than those working on the 3D DOTS Physics right? It’s easy to make up stories like this but I’m here to tell you that there are dedicated and passionate devs on 2D/3D physics here at Unity.

Is there a reproducible bug on the 3D physics bug list? I couldn’t see one at a quick glance. The main reason why bugs like this are not solved are that they are either not reported or just cannot be reproduced.

Also, there are always dozens of reports but also know that there’s also a huge proportion of these reports that are user error. We get bug reports all the time like this where it’s basically a bug in the users project. If it’s not then we really do appreciate them because it’s something we can sort out.

If it comforts you, we are certainly not off with our heads in the clouds thinking of non-useful things to work on. For instance, since the start of the year 2D physics has maintained a zero bug count with the occasional valid one coming in but being resolved in days.

I don’t work on 3D physics but go ahead and produce a bug report so QA can verify it and get it into the hands of those devs who do care about it.

6

I can agree that this was user error in my case. There are FOR sure weird interactions with Overlaps and Depenetration functions, but as @MelvMay just mentioned, 99% of those are user errors, the others are situations that really hard to reproduce, but they exist (either floating precision issues, or some other thing that is happening in the background that I havent been able to pinpoint). The capsule implementation has some weird logic with sizings, so the overlap capsule doe snot behave 100% like you expect. It took me ages to figure that one out.

7

Yes and to be clear I am saying that bug reports can contain a lot of user error but they also contain valuable bug reports that pass QA verification that we don’t frown upon when we get them; they are valuable and are not ignored. A search of posts that “might” be the same thing are not something that we actively look at.

The thing to be careful of that catches a lot of devs out is just driving everything with transforms. Physics objects should be moved by the component that is dedicated to the task i.e. the Rigidbody(2D). When you change the Transform then ONLY the transform is changed and no other part of Unity including any of the physics engines. The renderers only know when they come to render per-frame and read it. Physics (by default) doesn’t run per-frame which is often ignored/unknown so you can expect that running a query after modifying a Transform won’t change anything in physics because physics doesn’t even know about it yet. Not saying this is this issue but it’s one of many user errors/misunderstandings that get in the way as unfortunate as it is.

A classic one is instantiating something that includes physics components at the origin then immediately changing the Transform then performing a query. The query won’t see it because it’ll be at the origin. Stuff like this is easy to describe but with real scripts moving things with Transforms then querying them, this point becomes super important and can even manifest itself intermittently.