5
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ A screenshot would be nice. \$\endgroup\$
    – ashes999
    Apr 1, 2012 at 16:58
  • \$\begingroup\$ 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. \$\endgroup\$
    – Roy T.
    Apr 1, 2012 at 17:09
  • \$\begingroup\$ will your absolute collisions be axis-aligned, or will they be oriented? \$\endgroup\$
    – gardian06
    Apr 1, 2012 at 19:48

2 Answers 2

1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .