   Recovering from collision
  I''m not getting much response in the math forum. I guess it''s too simple to catch attention.I''m trying to recover from a collision with a sphere against a mesh. What I''m trying to do is allow "sliding" on faces, instead of just reseting the position back to where it was before the move. In other words, only stop the directions moving that collided, and allow the other directions to keep moving.I figured using the normal of the triangle I collided with would work perfectly, but I''m having some trouble. See here.How do most programmers handle mesh collisions? I know most games do "sliding", but how is it handled?Thanks for any help. 
  first of all, I calculate the sphere''s prediceted position at the end of the frame, like in normal updates. Then I try to constrain that point with the triangles of the world. At the end of the frame, the next sphere position will therefore be in a place where the spehre don;t intersect triangles (in theory). for collision detection then, I use a technique that gets the closest point on the triangle to the predicted sphere centre. If that point is inside the sphere, then the triangle collided. If so, I calculate the point on the sphere the closest to that point on the triangle. Then it''s simply a matter of moving the predicted sphere position so that the point on the sphere and the point on the triangle touch. For this to work, I use a verlet integrator, so there is no explicit velocity involved. This works, and generate sliding, but the objects won;t bounce. here is some peudo code void CSphre::Update(float dt){    Vector Temp = Target;    Target+= (Target - Position) + (Forces / Mass) * (dt*dt);    Position    = Temp;    for (int i = 0; i < num_triangles; i ++)    {   Vector Ptri;   Vector Psphere;   Ptri = ClosestPointOnTriangle(Target, Triangle[i].V[0], Triangle[i].V[1], Triangle[i].V[2]);   if ((Ptri - Target).DistanceSquared() > radius*radius)  continue;  Psphere = GetClosestPointOnSphere(Ptri, Target, radius);   Vector Displacement = (Ptri - Psphere);   Target += Displacement;    }}you can see a demo of this stuff here.http://uk.geocities.com/olivier_rebellion/simple_collision.zip ;  This is exactly what I should be doing.Why do you square the distance of the triangle and the radius of the sphere? My math is not up to high standards, but neither would be negative, would they? Is there another reason?EDIT - Ahh, I'm sorry, I didn't pay close enough attention. I see the Ptri - Target calculation could indeed be negative. Is that the only reason for the squaring?Umm, calculating the closest point on the sphere to any other point. Would one do that by getting a normalized direction vector to the other point and multiplying it with the radius?Thanks for the time put into your response, it is very helpful to see some code  EDIT - Also, how do you handle completely bypassing triangles when the frame rate is low or the movement too fast? For example, if the sphere moves more than it's radius in one frame.   [edited by - Jiia on May 12, 2004 7:36:51 AM];quote:Original post by Jiia  Why do you square the distance of the triangle and the radius of the sphere?It''s probably because this way you don''t have to calculate the square root of the distance. It''s faster. And Ptri-Target cannot be negative since there''s not such thing as a negative vector. And the length of a vector is always non-negative (>=0).quote:Umm, calculating the closest point on the sphere to any other point. Would one do that by getting a normalized direction vector to the other point and multiplying it with the radius?Yes, basically at least ;  there is a thread in the maths and physics forum about how to get the closest on a triangle from a point in space. it''s the same code I''m using, but without the need for a vector class. as to finding the cloest point from the sphere surface, yeah, normalise direction, multiply by radius. I do the ((Ptri - Psphere).MagnitudeSquared() > radius*radius) to check if the closest point on the triangle is inside the sphere. if not, no other points can be inside the sphere, so there is no collisions with that triangle. else, there is a collision, ect...quote:Original post by Jiia  EDIT - Also, how do you handle completely bypassing triangles when the frame rate is low or the movement too fast? For example, if the sphere moves more than it''s radius in one frame.   I don''t handle that case. I''d probably split the trajectory into smaller steps, and do several checks per frame along those steps. It''s a bad situation really, when the frame rate goes down, since you''ll be doing more processing => incerase calculations => drop frame rate even further... However, you can also do this if the sphere travels very fast (more than 1/2 it''s radius per frame), which makes more sense. To do a swept test, it''s a lot more problems. ;quote:Original post by nonpop probably because this way you don't have to calculate the square root of the distance. It's faster. And Ptri-Target cannot be negative since there's not such thing as a negative vector. And the length of a vector is always non-negative (>=0)Ahh, oops. Like I said, my math skills are rather pathetic. But they've improved more in the last 4 days than the last 5 years. At least now I know how to calculate the length of a vector sqrt(x*x + y*y + z*z) By the way, I'm still having a "jiggling" effect using your method, oliii. Do you experience this as well? When pushing against a corner? Or is it because I'm calculating something else wrong?In either case, you may want to try using the method I described. It seems to produce more realistic sliding. Try using the absolute values of the normal of the triangle and multiply it with the target vector, storing the result in the target vector. It works very well except for the jiggling. But I'm starting to think the jiggling is being caused by something else.EDIT - ahh, I explained that wrong. You can use the normal to get the percentage of each direction that you CAN'T move in. Plus you wouldn't use absolute values. Sorry bout that. So the calculation would be Target += TriangleNormal * (SphereRadius - DistanceToTriangle). So if the normal is pointing out towards X, the X coordinate would be reduced accordingly. [edited by - Jiia on May 12, 2004 9:03:05 AM];quote:Original post by oliii  I don''t handle that case. I''d probably split the trajectory into smaller steps, and do several checks per frame along those steps. It''s a bad situation really, when the frame rate goes down, since you''ll be doing more processing => incerase calculations => drop frame rate even further... However, you can also do this if the sphere travels very fast (more than 1/2 it''s radius per frame), which makes more sense. To do a swept test, it''s a lot more problems.Another solution for the low frame-rate problem could be to limit the max amount of time that can go by in one frame. But this would replace choppy movement with slowdown. Guess it depends on the game. ;  The way I solved the problem you're describing was to respond to collisions only after the bounding sphere has penetrated the mesh, instead of predicting whether it would collide next frame.  However, instead of moving back to its last position once it was found to penetrate the ground, I projected the sphere's center in the direction of the surface normal.  Then, I kill the normal component of velocity (zero bounce, only slide).Plane surfaceplane;dist = planedist(surfaceplane, sphere_center);if (dist < sphere_radius) // sphere is inside mesh (collision){    sphere_center += surfaceplane.normal * (sphere_radius - dist);    norm_speed = dot(sphere_vel, surfaceplane.normal);    sphere_vel -= norm_speed * surfaceplane.normal;}  [edited by - Schmerm on May 12, 2004 2:15:00 PM];  Schmerm > I pulled that method out of a hat, so it''s cool that you used the same idea (our math looks identicle). But not reseting the velocity shouldn''t cause it to bounce. My velocity stays constant as I push into the wall. When the sphere is reset to the correct location, it doesn''t make much difference if the velocity changes. Not as long as it''s being reset back to a good location.Honestly, the jiggling doesn''t bother me much. My game will use mouse clicks to move anyways, so no object will ever try to keep pushing on triangle faces 