Jump to content
  • Advertisement
Sign in to follow this  
mr_jrt

Simple collisions when initially in contact

This topic is 4840 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

For the purposes of simplicity the problem is the rigid-body interaction between a sphere and a plane, though the actual usage is a air hockey simulation. I noticed a prblem when the puck seemingly randomly (though intermittently) passed through the walls. I realised this was due to it being exactly the radial distance from the plane due to the rounding issues of floats, and as I checked for collisions using "if (t > 0) collide". I'm currently using the equation t = - ( ( dot(L,P) ) / ( dot(L,V) ) ) ...where: * L is the plane adjusted so its distance from the origin has had the radius of the sphere subtracted from it * P is the position of the sphere * V is the velocity of the sphere This gives t < 0 if the sphere is moving away form the plane, t > 0 if it is moving towards the plane, and 0 if it is moving parallel to it. Thus "if (t > 0)" determines if/when a collision will occur. The problem is that this doesn't account for one unique situation, when the bodies are in contact, but not actually penetrating; this also produces t=0, and is thus a problem. I attempted to work around this by setting the ignored parallel 't=0' to a random negative number, and changing the code to "if (t >= 0)"; this allows these collisions to be detected correctly. The second stage of simulation is of course moving the objects, but here lies my current problem. Now that I've determined that t=0 is valid, I am unable to use velocity correctly, as the usage requires: p2 = p1 + (v * t) ...which of course will result in a stationary object ad infinitum. I'm quite stuck here. Any ideas? I suspect that I need to prevent this situation from occuring rather than attempoting to deal with it when it does, but I'm unsure how to achieve that. Another thought is using a better integrator, as I'm only using a basic Euler at the moment given the simplicity of things, but as a consequence I cannot alter velocity without restarting the simulation frame. *Sigh* It's never simple, is it...

Share this post


Link to post
Share on other sites
Advertisement
Collision detection is rife with problems such as those you describe, and you just have to find ways to deal with them :-|

A couple of ideas:

1. Introduce a small epsilon to keep your puck away from other objects at all times. When a collision occurs at a t > epsilon, only move to t - epsilon, which should prevent interpenetration at the beginning of the next step. If the collision occurs at t <= epsilon, don't move at all. (This won't solve all problems, but will help.)

2. Have your collision detection routine handle both static and swept intersections. For collisions where t > 0, return a contact point and normal. When the objects are initially intersecting or just touching (t = 0), return a penetration vector. Then, choose an appropriate collision response based on the type of collision. For swept, you could move the object near the point of collision and then reflect the velocity vector. For static, you could resolve the interpenetration (plus an epsilon), and then reflect the velocity vector.

Ok, that wasn't a very good post (and I realize I didn't address all your questions), but I gotta go. I'm sure you'll get some other (probably better) responses, though.

Share this post


Link to post
Share on other sites
Following on your train of thought, I seem to have something workable by adding a bodge special case for dot(L,P)==0, where I then use std::numeric_limits<float>:min() instead of 0. This results in a +t and is thus sufficient to enable the collision response to occur workably.

It's not the best solution, but it'll do until I'm a bit more capable with these problem domain. Thanks for your suggestions.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!