When a ball rolls over the edge between 2 box colliders it gets nudged into the air. I believe this is because the ball is colliding with the underground perpendicular faces of 1 or both of the boxes.
I’ve previously posted about a similar issue where a ball will collide with the edges of flat colliders like adjacent planes or even the internal edges in a mesh. This particular problem can be solved by modifying the collision normals to use a face normal instead of an edge normal.
However, this approach doesn’t work correctly for boxes. I think this is because the algorithm ends up choosing the underground face instead of the face the ball is rolling on which just means the normal is in the opposite direction to the velocity. I can’t just tell the algorithm to use up for all collision normals since that would result in the ball rolling through walls and I’d like to be able to position objects with arbitrary rotations.
Additionally, I can’t use havok physics because we need the cross-platform determinism that unity physics should eventually bring.
Please could anybody help me to solve this problem?
If I’m not wrong, I believe this is an identical issue to that I had with planar collider faces creating jumping. I was responded to with the fact that Unity Physics cannot deal with these instances without modification, or using Havok. Please see this post, along with the linked talk: Unnecessary Collisions created at collider edges (results in bodies "jumping")
Hey, thanks for responding. I’ve seen that talk and implemented the proposed solution with regards to planes, as I said in my original post. Unfortunately that solution doesn’t seem to cover the case when the adjacent colliders are boxes, or I guess anything where more collision continues down at the seam. It would be nice to have some guidance on how to implement a general purpose solution to this problem.
Here, a sphere standing at a distance of 0f to box 1, and doing a colliderCast in the direction of the blue arrow (perpenticular to the contact surface with box 1), will find a hit represented by the red normal in the picture. This causes all sorts of compicated issues for me
I’m guessing this is most likely a floating point error issue, but I also didn’t have that problem in PhysX. I think what I’d really want in order to solve this is some kind of tolerance distance that could filter out hits in queries that have an extremely low “penetration distance” with the casted volume (in darker green in the following picture):
Hey @PhilSA , I’m going to assume this is a question related to character controller, with your previous work and posts in mind. Please correct me if I’m wrong.
We have the same issue in our implementation of the character, and it’s something known. The way we are fixing it is by introducing “skinWidth”, as sort of a wrapper around the character. What this means is that character always floats a few cm above the ground and never actually touches it. So when you cast horizontally, it doesn’t “see” the ground and therefore significantly reduces ghost collision problems.
Another approach would be to have another (a bit smaller) collider that you are casting. It boils down to the same idea - have a collider at a small distance from the actual ground/wall and reduce the ghost collisions.
I was trying to avoid “skin width” approaches because it often causes tunneling in those types of situations:
But maybe it was just my implementation of it that was faulty. I was simply offsetting my CC’s position by a small amount in the direction of the hit normal on every hit, but I guess doing a CalculateDistance + SimplexSolver.Solve() at every hit would solve it…
So unfortunate to have to pay that significant performance cost in order to solve that tiny edge case, but perhaps we have no choice
Did you check out our implementation of skin width? It’s just a value you subtract from every distance in CalculateDistance and ColliderCast hits? That way, when you have a skin width of 1cm, a hit at 5cm distance appears as if it’s 4cm away, giving you this buffer space to avoid actual touches. I’m having a hard time seeing how this would cause tunneling, it’s only safer to do so…
For anyone encountering this issue, try lowering the “Default Contact Offset” value in the Physics page of Project Settings. I was having this issue for days until I found some unreal forums talking about the same issue. I lowered the value from 0.01 to 0.001 and now I don’t have any more ghost collisions.
Please correct me if I’m wrong.