After every collision fix, you should push the object to above the plane, so it never actually stays in contact with the plane, but just a little above the plane. If you like, I can post the code I use to do this.

sounds like the way you do things is every update you apply gravity and motion to your object, then to do collision detection to see if it is passing through a plane and do a velocity flip bounce or something

I'd guess that what is happening, is as it bounces lower and lower, eventually it gets so close to the plane that your collision detection 'misses' the collision, because floating point numbers are kinda innacurate and your object might appear to be on the other side of it by random chance.

first of all, it is a good idea to lose this entire method of bounce-bounce-bounce to simulate contact with the floor
and instead develop a notion of, objects 'at rest' touching the floor and not having gravity move them anymore
This should lead to savings since an object you already know is touching the floor isnt going to need to have infinitesimal bounces and responces every update...

Additionally, if possible you should add the concept of 'inside' and 'outside' of the map, so that even if an object falls through a floor polygon, subsequent updates should realize it is outside the map and thus must have collided with the floor sometime in the past (but missed), then do a correction.

the problem might also be with how your collision responce works, do you only change the objects future velocity when it hits? or do you also reposition it to account for the fact that inbetween update intervals is when the actual collision happened, so it really has moved up a little already?

Quote:
I've been doing some more work on this and I think it may be due to the objects at some point lying exactly on the plane. I'm guessing I should move they a little away from the plane that they have hit as CadeF suggested.

it is an inprecision problem. As muc has u lower the EPSILON u will still at some point have a case where the number is between zero and epsilon and it is taken as zero not as Epsilon. I faced this in some bsp projects, and it was due to some art stuff. BSP is NOT a general algorithm, this means if u have 2 objects above each other and one of the vertices is lsightly misplaced the whole BSP is changed and u will get many bugs. Most solutions are to always use basic solid geometry object (spheres,...) and use unary operations on them to get the shapes. Now this will result in a gd BSP but not very good art.