Sign in to follow this  
Daniel Miller

A collision problem that I have a hard time explaining

Recommended Posts

I'm sorry if I'm not explaining this well. Let's say I have two objects in a game that are side-by-side and touching. <-[][] I decide to move them both to the left. If I check collision on each object before it moves, and if I happen to check the object on the right first, I will detect a collision even though there shouldn't be one (because the object on the left is moving the same direction). The solution I would think is to move all objects and then check for collision. Then, I get another problem. Those two objects are sill moving towards the left, but now there are two more objects, side-by-side and touching, moving towards the right. ()()-> <-[][] If I check collision using the second method, how will I possibly "undo" the movement? The middle two objects will be intersecting, so I move them back. Now, the two middle objects are intersecting the two outer objects. Do I move the outer objects back as well? Is this how it's supposed to be done? It seems incredibly clunky.

Share this post


Link to post
Share on other sites
Depends how accurate you wanna be, but generally, simply don't bang your brain on it too much.

AB-> <-CD

You compute the next state of each objects (B has velocity, C has opposite velocity). Then you detect collision pair-wise. You will find B and C colliding at some point in teh frame. Then yuo move them to that time, compute the collision response, and you have.

A <-BC-> D

And then you start again, try to find new collisions withing the reminder of the frame time. You will need carefully selected tolerances, or you can enter 'infinite collision loop' mode, where you detect a large number of collisions happening almost simultaneously (think spheres dropping into a funnel).

If the objects are touching, say A and B, and you want to consider this a collision (infinitesimal intersection detected), push the objects apart (won't move much). The collision response should not apply any change in velocity, since the relative velocity of A abd B and the collision normal will be pointing in the same direction. It's sort of the basic of collision response, and prevent the objects sticking onto each others.

YOu can also don't bother with that much, and treat collisions for each objects independantly, like Quake and other do. That simplifies collision detection a lot, and give semi-accurate results, which can be good enough for some games.

If you just want to detect intersections, it's even simpler. Just go through all the objects, and process intersections and collision response one by one, regardless of order. YOu can run that check several times a frame.

Share this post


Link to post
Share on other sites
The other method is to solve collision by representing time as a dimension, and extruding the objects through it.

If these are 2D rectangles: [] []

Then looking from the side: _ _

The vertical axis now represents the time. And you extrude the objects through it, getting something like this, resulting in (n+1) dimensional objects:

_ _
\\\\
\\\\


To check for collisions, you now check for collisions between these (n+1) dimensional objects.

In your case, there is no collisions, regardless of which order you check them in ( with obvious exception of numberical errors).

Granted, this method is much more complex, especially since for 3D objects you need to check collisions between 4D geometry, but still, it's one way.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this