Jump to content
  • Advertisement

Archived

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

Zakwayda

Collision response...

This topic is 5268 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

I''ve finally got my sphere/polygon soup collision detection working, based on Kaspar Fauerby''s paper on ellipsoid/tri collision (thanks, Kaspar). I''ve still got a couple of problems with collision response, however. When my object runs into a 90-degree corner, it behaves correctly. It stops dead, and then slides up or down if you change your pitch. However, I have problems with both acute and obtuse angles. In an acute angle (less than 90 degrees), the object stops dead and won''t slide up or down. I''ve discovered that this is happening because the coldet routine is reaching maximum recursion depth and dumping the object back to its original position. So there''s something about the acute corner that causes the object to bounce back and forth (not in real time, but within the recursive collision calls) indefinitely. In an obtuse angle, the object ''jiggles'' back and forth. That is, instead of stopping dead (except for sliding up and down) as it should, it shakes back and forth from frame to frame. I know a lot of you have dealt with collision response already, be it using BSP, brushes, polygon soup, or whatever. So I''m wondering if any of you have encountered these problems, and if you have any advice on how to address them. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
the fact that it''s'' reaching it''s recursion limit is bad. that should not happen. so there is a problem there.

I assume you have the collision point/normal, all you have to do is to reflect/slide the ball''s velocity along that normal, and that should be the response. There are several problems due to floating point innaccuracies, so you have to play with thresholds to avoid getting stuck or missong collisions.

Share this post


Link to post
Share on other sites
Hey oliii,

Yeah, I''m sliding along the collision plane. To deal with floating point innaccuracy, I''m moving my object just short of the collision point so that it will not be initially intersecting next frame.

I remember reading somewhere that acute corners can cause problems with this type of algorithm. Has anyone else tested their collision response with acute corners? I certainly would like to figure out what I''m doing wrong so I can handle these cases correctly...

Share this post


Link to post
Share on other sites
there are several things you can try.

when sliding, don''t kill the normal velocity totally, leave a small elasticity. If you use displacements, add to the displacement, (Normal * 0.01f) or something. For velocities, add a small Vup similarly.

you can push the sphere up above the plane, by adding (Normal * 0.01f) to the collision point and moving the sphere there. That can cause problems when you collide in some sort of tunnel or very narrow corridor.

you can move the sphere by 0.99f of the calculated time of collision. however, as the velocity/displacement gets reduced, then the fudge becomes negligeable, and since if you get stuck, it means at generally low speeds, it might not impact as much.

Share this post


Link to post
Share on other sites
I'm not sure I understand the difference between the first two options (nothing wrong with your explanation, I'm sure, I'm just missing something). Initially I was using option 2 (pushing the sphere out a bit along the poly normal). But this was causing me to slip through corners, and (as you mentioned) it can cause other problems.

What I'm doing now is more like option 3, but instead of going 99% of the way, I'm just stopping a centimeter or so short of the goal (so if the distance to the intersection point is 50 centimeters, I'm moving 49). This seems to be the best way to do things, since you don't run the risk of 'pushing' your object into intersections with other geometry (a hazard of the 'push out along the plane normal' approach).

Anyway, the problems with acute and obtuse corners remain the same. In an obtuse corner, the object slides from one wall to the other one frame, and then back again the next frame, causing it to jiggle from frame to frame. In an acute corner, the object bounces back and forth within the recursive coldet function until maximum recursion is reached, so it gets stuck.

So I'm trying to figure out solutions to both those problems, but so far no luck. Thanks for your input so far, oliii. Any further thoughts from you or anyone else will be appreciated.


[edited by - jyk on June 12, 2004 1:48:10 AM]

Share this post


Link to post
Share on other sites
well, with concave geometry, these things will always happen wit hthe kind of approach you take.

i think keeping track of contact points might be a solution. when something collides and its normal velocity falls under a certain threshold, create a permanent contact point that will be destroyed when the normal distance reaches some other small treshhold.

then, when applying a force like gravity, you first deduct the influences of all contact points (normal forces), which should give you an acceleration in the right direction. or maybe a more stable method would be to ensure somehow that the resultant speedvector doesnt have a negative dotproduct with any of the contact normals.

this may or may not sound like a good idea, one thing i do know is that it gets complicated when a couple of spheres lie stacked upon eachother. i guess it involves a lot of matrix solving then, which might well be out of your scope.

i believe there are some good ways to iteratively solve for all contant point constraints, in a way much like a verlet mass spring system, but i wouldnt know how exactly or where to find it so ill shut up.

Share this post


Link to post
Share on other sites
"well, with concave geometry, these things will always happen wit the kind of approach you take."

Thanks - if that''s true, then that''s exactly what I needed to know.

I was thinking I might have to deal with contacts, but I was hoping not to. But what I really want is a completely robust sphere/polygon soup collision system, so I guess I''ll need to think about these convex and concave cases.

All the input is very helpful. If anyone else stumbles across this thread and has any thoughts, please share!

Share this post


Link to post
Share on other sites
I don''t remember having problems with obtuse angles. even with an ultimate obtuse angle of 180 degree like on a single triangle, with no culling.

the third option is good, yes. I think that''s what Quake3 does. the second option is changing the position of the sphere directly, while the first option is adding a small extra velocity/displacement to the sphere, so it won;t brake the algorithm, but make the sphere jiggle up and down a little bit.

if you have the code somewhere, I can have a look

Share this post


Link to post
Share on other sites
quote:

Thanks - if that''s true, then that''s exactly what I needed to know.



well never say always: maybe there are some very good solutions, but i dont know them. for example a resting sphere with gravity on it will always be bouncing around a bit. if you can handle all cases with none or such minor inconvenieces, id be interested to know how you pulled it off.

Share this post


Link to post
Share on other sites

  • 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!