Avatar/Wall collision response
by SR · in Technical Issues · 02/27/2002 (3:30 pm) · 5 replies
Collision repsonse with one collision point it fairly straight forward, but how about when there are multiple points of collision? For example, if a user walks into the corner of a room.
In this case, you want to back out of both intersections. If you're guaranteed perpendicular walls, this is a simple matter of adding the response vectors together. But if the walls don't meet at 90 degree angles, this doesn't work.
I've tried averaging the intersection points together and treating it as a single collision, and it works fairly well, but it's numerically unstable (even after making sure only to use a closest-convex set of intersection points).
Anyone else have some insight on this? I'm willing to show the source of what I have so far if anyone's really interested. I've just run out of ideas to try, and there aren't many online resources for this kind of problem (that I've been able to find). Maybe one of the GG guys worked on the collision response code for Tribes? :)
Thanks for any help.
In this case, you want to back out of both intersections. If you're guaranteed perpendicular walls, this is a simple matter of adding the response vectors together. But if the walls don't meet at 90 degree angles, this doesn't work.
I've tried averaging the intersection points together and treating it as a single collision, and it works fairly well, but it's numerically unstable (even after making sure only to use a closest-convex set of intersection points).
Anyone else have some insight on this? I'm willing to show the source of what I have so far if anyone's really interested. I've just run out of ideas to try, and there aren't many online resources for this kind of problem (that I've been able to find). Maybe one of the GG guys worked on the collision response code for Tribes? :)
Thanks for any help.
#2
One collision does occur... but in this case it occurs two times. One to direct the user away from the wall or object and the other directs the user away from the other wall or object.
Let's say the user is moving from SW to NE (on a flat map where "up" is the same as North)
Let's represent this movement vector with /
No, there is a wall to your East. Uhoh! Okay, let's compensate for that by altering the movement vector accordingly: Now the player's move vector looks like this: |
You can't move to the east, but you continue to move North (slower than before... so this | should be smaller compared to the / before)
Now, there's a wall to the north! uhoh! Now we must reduce the northern movement to 0... all we are left with is .
. means the player isn't moving at all.
This isn't technically detailed, but it explains (for the most part) how collision can be handled (by altering movement vectors) This is the only way I've really worked with it, and it works pretty well. Hopefully you've had at least high school physics, because without it movement vectors don't make too much sense with collision.
I'll try to help with general questions on collision, but I'm not the pro when it comes to code details with it.
02/27/2002 (5:53 pm)
I haven't worked much with object collision in torque, but the basis of what you're talking about is sort of correct.One collision does occur... but in this case it occurs two times. One to direct the user away from the wall or object and the other directs the user away from the other wall or object.
Let's say the user is moving from SW to NE (on a flat map where "up" is the same as North)
Let's represent this movement vector with /
No, there is a wall to your East. Uhoh! Okay, let's compensate for that by altering the movement vector accordingly: Now the player's move vector looks like this: |
You can't move to the east, but you continue to move North (slower than before... so this | should be smaller compared to the / before)
Now, there's a wall to the north! uhoh! Now we must reduce the northern movement to 0... all we are left with is .
. means the player isn't moving at all.
This isn't technically detailed, but it explains (for the most part) how collision can be handled (by altering movement vectors) This is the only way I've really worked with it, and it works pretty well. Hopefully you've had at least high school physics, because without it movement vectors don't make too much sense with collision.
I'll try to help with general questions on collision, but I'm not the pro when it comes to code details with it.
#3
Matt: That's an interesting approach I haven't throught of, if I'm reading you correctly: Instead of backing out of the collision from the new position, modify the movement vector that got you to that position and recalculate. I'll see what I can come up with tomorrow.
Thanks for the responses, guys.
02/27/2002 (6:15 pm)
John: Already have it, looked at it; they use impulse response calculations, which is overkill for my purposes. I just need to be able to back out of the collision, not bounce off of it (which is admittedly a better system overall, but I don't have a physics engine in place yet).Matt: That's an interesting approach I haven't throught of, if I'm reading you correctly: Instead of backing out of the collision from the new position, modify the movement vector that got you to that position and recalculate. I'll see what I can come up with tomorrow.
Thanks for the responses, guys.
#4
You'd move ahead .2 units and if there's a wall there, back .2 units (quick enough so that it isn't noticable) The problem with this approach is it sometimes doesn't handle sliding collisions that smoothly. And if you get crappy framerate it will be noticable (or with very high speeds)
There are ways to fix it, but there's gotta be a "newer" way to deal with collision.
02/27/2002 (6:21 pm)
Yes, that is the thing I used when I worked with *shudder* Dark Basic.You'd move ahead .2 units and if there's a wall there, back .2 units (quick enough so that it isn't noticable) The problem with this approach is it sometimes doesn't handle sliding collisions that smoothly. And if you get crappy framerate it will be noticable (or with very high speeds)
There are ways to fix it, but there's gotta be a "newer" way to deal with collision.
#5
To use his example, there is a wall to the north and to the east. You are headed NE into the corner.
In addition, the reason for bouncing off of the wall is that either the wall or the player has rebound of some sort. That is, it is assumed that one or both will deform slightly on impact, but then revert back to normal shape, propelling the mobile object (the player) away from the immobile object (the walls) some small amount. So we treat the player a bit like a rubber ball.
When the player hits the corner, they will either strike one wall first or both simultaneously. If both are struck at the same time, arbitrarily select one wall as first (since the efect is the same either way). So now, naturally or artificially, one impact precedes the other.
On the first impact, there will be rebound at an angle equal but mirrored across the normal of the wall. Do not reflect directly off of the wall. If the player is perfectly resilient, there is no loss of velocity. Since the player is not perfectly resilient, there is a loss of velocity, but the change in vector is still the same. Assume that the player loses half it's velocity. Then:
The red line is the initial vector. The blue line is the vector after impact, but at half the velocity. The green line is the vector after the second impact, but at half the velocity of the green vector (1/4th the vel. of the red).
This seems simplistic, but unless the player has spin (like english in billiards) this does a good job of providing a solution. Don't want to bounce off the wall? Take away more velocity on impact. But leave the resulting direction intact. Have many points of contact? Find a first (natural or artificial as above) impact and work from there. Just make sure you mirror the vector based on the surface normal's direction. Have different materials? Make sure each one reduces the reflected velocity appropriately and let the chips fall where they may. Want to slide along a surface? Make the surface reflect a velocity at almost 0. This is like bringing the player to a near stop. Then continue applying the force that put the player in contact with the surface as long as that force remains, whether it be the player walking into the wall at an angle or gravity itself.
Just remember that in the absence of other forces, velocity and vector are constant. Impacts tend to produce a mirrored exit vector. Forces include player motive force, gravity, and friction. Surface friction induces spin, altering the reflection angles and the velocity (think billiards english again), while all other friction is due to the medium you pass thru (air, water, lava, etc) and simply alters velocity.
That may not be what you are after, but it may be helpful to others... I dunno.
02/28/2002 (8:30 am)
If you want to bounce off the wall, Matt's approach, slightly modified, does work well, even with many materials and points of impact.To use his example, there is a wall to the north and to the east. You are headed NE into the corner.
In addition, the reason for bouncing off of the wall is that either the wall or the player has rebound of some sort. That is, it is assumed that one or both will deform slightly on impact, but then revert back to normal shape, propelling the mobile object (the player) away from the immobile object (the walls) some small amount. So we treat the player a bit like a rubber ball.
When the player hits the corner, they will either strike one wall first or both simultaneously. If both are struck at the same time, arbitrarily select one wall as first (since the efect is the same either way). So now, naturally or artificially, one impact precedes the other.
On the first impact, there will be rebound at an angle equal but mirrored across the normal of the wall. Do not reflect directly off of the wall. If the player is perfectly resilient, there is no loss of velocity. Since the player is not perfectly resilient, there is a loss of velocity, but the change in vector is still the same. Assume that the player loses half it's velocity. Then:
The red line is the initial vector. The blue line is the vector after impact, but at half the velocity. The green line is the vector after the second impact, but at half the velocity of the green vector (1/4th the vel. of the red).
This seems simplistic, but unless the player has spin (like english in billiards) this does a good job of providing a solution. Don't want to bounce off the wall? Take away more velocity on impact. But leave the resulting direction intact. Have many points of contact? Find a first (natural or artificial as above) impact and work from there. Just make sure you mirror the vector based on the surface normal's direction. Have different materials? Make sure each one reduces the reflected velocity appropriately and let the chips fall where they may. Want to slide along a surface? Make the surface reflect a velocity at almost 0. This is like bringing the player to a near stop. Then continue applying the force that put the player in contact with the surface as long as that force remains, whether it be the player walking into the wall at an angle or gravity itself.
Just remember that in the absence of other forces, velocity and vector are constant. Impacts tend to produce a mirrored exit vector. Forces include player motive force, gravity, and friction. Surface friction induces spin, altering the reflection angles and the velocity (think billiards english again), while all other friction is due to the medium you pass thru (air, water, lava, etc) and simply alters velocity.
That may not be what you are after, but it may be helpful to others... I dunno.
Torque Owner Josh Albrecht