Wedge problem

You could bounce the sphere off the walls elastically. If you do this you should see the sphere come back at you after a finite number of impacts, much the same as a beam of light shone towards two mirrors forming an angle will be reflected back. You could reduce it''s speed by a fraction each time to match collisions elsewhere that lose energy.

But I can''t see why your algorithm is failing. If you check all collision surfaces and process them in time order it should work. As soon as a collision is detected work out when it first happened then move the sphere back to this point, e.g. by interpolating between it''s curent and previous position. Adjust it''s velocity due to the collision (obviously it should be moving away from or along the surface) and continue.

Because this is the first surface it collides with it cannot be intersecting any other surfaces at this time. But because this collision might push it into another surface redo the checks STARTING FROM THE TIME OF THE COLLISION, dealing with any collisions you detect.

In theory you could end up with dozens of collisions to process at once, but if you reduce it''s speed/velocity at each collision you can quickly bring it to rest and so avoid too many calculations.

Another solution is: don''t have very narrow angles in the game world. They are mathematically expensive to deal with and lead to other problems, such as the player, NPCs, cameras etc. getting stuck in them. If you have them you have to weigh up the cost of writing code to deal with them in the physics, AI, navigation, etc.

Thanks for you help johnb, I''ll have another look at it. I now think the problem might be to do with floating point rounding errors and the sphere intersecting one (or both) of the polys.
And I''ll have a word with my level builder to remove the wedge

Cheers again,

Fleejay

I think the problem is in step 2.
Don''t move the sphere as close to the poly as possible.
If your simulation uses discrete steps
through time (as most do), just move the sphere
back to its previous location when it collides
with something. Of course, then you might want to
make sure that by moving the sphere back, you haven''t
caused another collision. Each object in your simulation
will have to remember their previous location
(and rotation for objects that are not as symmetric
as a sphere).



Steven Borkman
Home Page: http://www.borkman.mygamesite.net
Video Game Page: http://www.dev.mygamesite.net

Personally I use an ''unembed sphere'' method after each poly collision. So the code goes like this:

1 - Do swept volume sphere test to find first poly collision
2 - Move sphere to collision point and clip velocity to ''sliding plane''
3 - unembed sphere from poly (move it epsilon away from poly perpendicular to sliding plane)
4 - keep on looping back to (1) until no collisions are found, or the sphere is moving by less than epsilon.

NB. Make sure step 1 accepts polys that the sphere is already inside.

Using this algorithm, the sphere would have it''s velocity clipped by the wedge, but it would also be kept from going through it by the ''unembed sphere'' step.

You *shouldn''t* have to do the ''unembed sphere'' stuff, but in practice (due to floating-point errors etc) it makes the whole system much more robust and stops spheres slowly edging their way through polys.