How do I avoid 3D AABB collision response getting stuck at block edges?

Question

I want the player to be able to slide along cubes, but without getting caught at the seam between 2 adjacent cubes. I've gotten it so that I can do x collision, with sliding, and y, and z, but I can't do them together, probably because I don't know how to resolve it correctly.

Here's an example:

[] 
[]
[] 
[]O
[]

Pretend all the tiles are touching. O is the player (moving upward). The methods I was trying would get the player stuck between the cubes because the z axis was responding and kicking me out.

I don't know how to resolve this in all 3 directions, like how would I go about telling which direction I have to resolve in. My previous methods involved me checking 4 points in a axis aligned square around the player, I was checking if these points where inside the cubes and if they where fixing my position, but I couldn't get it working correctly.

Answer 1

I am working on a cube engine and solved this problem by treating each movement step as three separate axis-aligned movements, each having its own collision test and response. Thus, the upward motion never sees the blocks on the left, because it's either before the leftward motion (free to move) or after (in which case the leftward motion was stopped at the appropriate position), but in either case the upward motion does its collision test directly upward and so does not see the blocks of the wall.

The disadvantage I see is that fast diagonal motions may "stick out to the side" and hit things they shouldn't, but I haven't seen that in practice yet.

Answer 2

its always a good idea to make the objects to move around in your world be smaller then the world they are to move around in.

In a non-oriented collision system (things can not rotate) you would just pass the contact pair to the collision resolution system then determine from the velocity vector if it was moving toward that block. if not do nothing and clear the collision. otherwise resolve as normal. this works best on non-oriented collisions because the resolutions can be handled quite easily.

for oriented collision systems you just need to calculate the contact normal, but realistically if the object is able to rotate should make the movable object be smaller then the space to be traversed even while rotated.

though if it is a move by move system then you could also accomplish it with a move by move bool system