Archived

This topic is now archived and is closed to further replies.

OrangyTang

Tricky object sliding with multiple collisions

Recommended Posts

I''m trying to get a moving object (the player, shown multicoloured) to react properly to my environment (shown grey). I''d like to get proper ''sliding'' behaviour where all objects are rigid and pushing into one another makes you slide against the surface. All geometry is represented as convex hulls. So far my current method is: 1. Detect collision (works fine) 2. Find collision edge (shown in cyan, seems to be working fine). 3. Backtrack the object to previous position. Project velocity vector onto collision edge. Move object by new velocity to get the new position. Now this works great when theres a single hull that the player is bumping into - the top object in the pic. Sliding works properly and you can''t actually penatrate the object. However when theres more than one hull that the player bumps into things start to break down. At the lower left all still goes fine, the player still stays within the curved inner surface. But the raised platform in the lower center causes problems - the player is able to hit the middle flat edge and slide though the top platform as shown. I think this is caused because the middle flat edge is done, which pushes though the player though the slanty edge. Then this means that the top hull doesn''t detect the object passing though the edge and so goes mute. Similar problems seem to occur when pushing the player down the middle of a V shape - it''ll slide down one edge and go though the other. I''m at something of a loss, how can you handle collision with multiple objects simultaniously in a robust way? Thanks.

Share this post


Link to post
Share on other sites
usually, you gotta find the first occuring collision, move the player to that time of collision, slide his velocity, and find a new collision with the new velocity, until the player''s velocity is 0, or the frame time is all spent.

Are you doing swept volume collision detection, or just overlap tests?

Share this post


Link to post
Share on other sites
quote:
Original post by oliii
Are you doing swept volume collision detection, or just overlap tests?

A bit of both - once an overlap is detected, I test the points to find one in the other hull. Then I backtrack this to get a swept line segment and test this against the other hull to get the actual collision edge. It seems to work resonably well for most of the time, except if you get two rectangles sharing an edge it can occasionally snag on the internal shared edge.

I don''t think your idea will work though - it''ll still mean that one object can push the player though another, it just means that it''ll happen slower (or it''ll always loop since they push the object back and forth continuously).

Share this post


Link to post
Share on other sites
actually his method does work, that's how it's done in professional games (download quake2 source and I believe it's in pmove.c). I do not understand why you would want to 'trace back to the original position' before projecting the velocity against the plane.

as he said, you're supposed to find the first collision, move the player to that point of intersection, project the velocity onto the plane (in quake it's actually projected somewheres between 1 and 5 percent OUT of the plane slightly) and then handle collisions with the new velocity until either your velocity is 0, the time runs out, you finally get to a point where you can move the full velocity, or you hit the maximum number of planes you can test against (again, in quake this is 4 or 5, I think).

EDIT: I'd also like to see your actual calculations for projecting the velocity, and I'd like to know if you are detecting collisions against partitioned worlds. Floating point inaccuracy is another problem, the actual point of intersection needs to be calculated epsilon units on the closer side of the geometry, and epsilon units on the farther side of the cutter planes when determining which planes have been crossed.

[edited by - Shadow12345 on November 14, 2003 4:55:35 PM]

[edited by - Shadow12345 on November 14, 2003 4:56:08 PM]

[edited by - Shadow12345 on November 14, 2003 5:31:46 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by OrangyTang
quote:
Original post by oliii
Are you doing swept volume collision detection, or just overlap tests?

A bit of both - once an overlap is detected, I test the points to find one in the other hull. Then I backtrack this to get a swept line segment and test this against the other hull to get the actual collision edge. It seems to work resonably well for most of the time, except if you get two rectangles sharing an edge it can occasionally snag on the internal shared edge.

I don''t think your idea will work though - it''ll still mean that one object can push the player though another, it just means that it''ll happen slower (or it''ll always loop since they push the object back and forth continuously).


Yes, you can have a multitude of collision tests, if say, you dropped a ball inside a narrow funnel. But that''s the price to pay. I think Quake does something else, like check if the previous plane hit by the object is not opposite to the new plane hit by the object. If it is, then the velocity is set to 0 automatically and no more collision tests are performed. Something along those lines.

In the general case, the objects won''t be pushed against other objects. The velocity will change, obviously, but then you test for collisions once again, no pushing. Doing a swept volume collisions with convex hulls seems difficult. But with spheres, it is a lot easier. You don''t even have to use convex hulls for your environments, just triangles (or segments in 2D).

for convex hulls, I guess you can use the binary time search algorithm, and a distance-calculation system, like V-clip.

If you still find objects overlapping, due to numerical innacuracies, you can do a fall back case, and push the objects out until they are free from interfering objects. This case should never really occur.

Share this post


Link to post
Share on other sites