# AABB > AABB collision response?

I'm really confused about how to fix this in 3d? I want it so that I can slide along cubes but without getting caught if there's 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. e.g.

``````[]
[]
[]^
[]O
[]
``````

Pretend all the blocks are touching. `O` is the player, `^` is the direction the player is moving, with the methods which I was trying I would get 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 direction, 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.

-
A screenshot would be nice. –  ashes999 Apr 1 '12 at 16:58
You should merge your collision meshes to one big mesh as much as you can. This solves problems like you're having and makes detecting collisions cheaper. However there is probably also a solution without merging collision meshes so I wont post this answers. –  Roy T. Apr 1 '12 at 17:09
will your absolute collisions be axis-aligned, or will they be oriented? –  gardian06 Apr 1 '12 at 19:48

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.

-

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

-