I have been having trouble with a custom character controller I am making. The root of the problem lies with collisions. I am trying to make movement code, but I have a problem with ground movement. Pay attention to this gif. It might be hard to notice due to the low frame rate, but the collider registers collisions with objects (in red) that do not point out of the ground. They share the same y-position as the ground. I've printed the normals of the collisions, and there are a lot of normals that are perpendicular to the normal of the ground (which is causing the rigidbody to get stuck).

The problem lies with collisions in unity. If I were to print the y-position of the bottom of my collider, it would be just a tad lower than the y-position of the ground. The collider actually rests below the ground by an almost negligible amount (which is why it doesn't always collide with these objects).

Here is what I have tried: I created a function that runs at the beginning of every FixedUpdate() that uses current collisions to change the y-position of the rigidbody. It only runs on collisions that would ground the player (meaning that they are below the collider). The problem with this approach is that the same issue can occur with walls, meaning that the collider can get stuck on walls. I cannot create another function that would do the same for walls for various reasons.

Here is what would fix the issue: I need help figuring out how I can make collisions more discrete in unity. Colliders rest slightly below objects when ontop of them. They can also "sink" just a little into walls. In other words, colliders can rest into other colliders, and I need this to stop.

Any help is appreciated. Thank you.

  • 1
  • \$\begingroup\$ Have you tried making your collision continuous on your block? Discrete collisions resolve AFTER the fact by applying forces. This is why it's slightly below. Continuous collisions will only simulate to the point of collision, and apply the resolution forces there. It might resolve your issue at the cost of some performance. Although modern continuous collision is very performant albeit not as much as discrete. \$\endgroup\$ – gjh33 Apr 8 '19 at 13:26
  • \$\begingroup\$ @gjh33 Yes I have. It does not solve the problem. \$\endgroup\$ – blackhole Apr 8 '19 at 23:36
  • 1
    \$\begingroup\$ Why does character stop sometimes when entering the red zone? Is red zone supposed to register those collisions? What is a purpose of a red zone? \$\endgroup\$ – Candid Moon _Max_ Apr 13 '19 at 9:36
  • 1
    \$\begingroup\$ You're unlikely to be able to change the way the physics engine detects & handles contacts. So let's instead focus on the problem it causes for your game: why do you have these nearly-coincident surfaces in the first place? To reduce distractions for the physics engine, could we set the red object as a trigger or separate it onto a non-colliding physics layer, and check for overlaps with the red region in a different way? The more you can tell us about what this red patch is supposed to do, the better we can help you achieve those goals. \$\endgroup\$ – DMGregory Apr 13 '19 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.