more collision detection woes

Started by
3 comments, last by The Rug 15 years, 1 month ago
Hi I currently have a collision system written in Java whereby if 2 shapes are found to intersect, they are moved apart along shortest distance possible. For example, box A moves towards box B at 0.1 unit per frame. When they collide they will overlap by 0.1 units, so box A should be moved back by 0.1 units. Except my program is telling them to move apart by a value which is only approximately 0.1, and moves it back too far, leaving a small gap. This causes the objects to seemingly vibrate against each other. This seems to be because of a floating point inaccuracy when calculating the distance. Hopefully that explanation was good enough. Can anyone shed any light on what I might have done wrong here? thanks everyone
the rug - funpowered.com
Advertisement
There are two possibilities. The first is that your computation lacks precision, so the floating-point error is too large (for a value of 0.1, I would expect the error to be smaller than 0.0001 in the very worst case). The second is that, despite a very small error, the code that uses the corrected position is unstable and behaves wildly in the presence of even the slightest inaccuracies.

You have to identify which case you are in, and correct the corresponding piece of code.
Thanks++, I think I located the problem. As far as I can tell it was because I was not rounding properly when drawing.

Now I have a new problem. When my object collides with two surfaces that are not perpendicular (ie. goes into a corner) the object jitters about wildly. I drew this diagram to help explain:


Basically, the object moves down and right, thus overlapping 2 surfaces. As the collision response moves the object out of one surface (along that surface normal, picture in red) it gets pushed futher into the other surface. It is then moved out of this surface, but its final position is not at rest in the corner. The next frame, this repeats, so the object never seems to stop jumping around. You can probably picture what happens.

Is this a common problem? Or am I uniquely bad at figuring these things out? ;)
the rug - funpowered.com
What about waiting to do your collision response until you know all your collision normals and then adding them up, normalize that value and use that as your resolution normal?

Don't know if that would work but just an idea off the top of my head.
I don't think that would work, since its not only the normal but also the distance that needs to be taken into account. The object would still end up partially inside the wall(s). Thanks for the suggestion though :) I will test it when I get home just incase.

Has this problem not come up for anyone else? Or have I chosen a design which is flawed from the outset?
the rug - funpowered.com

This topic is closed to new replies.

Advertisement