   best way to handle sphere/terrain collision?
  i'm now sitting over this problem for over three weeks trying this and trying that but somehow don't get a satisfying result.what i have is a terrain build out of a triangle mesh ( hence no height map just arbitrary mesh ). now for getting things started i use a sphere somewhere at the body that i want to send colliding with the terrain. my main problem is stuck-prevention. i have a collision routine that is able to determine the distance traveled along a direction vector until the sphere collides with a triangle. if this happens a sliding normal is caluclated.the first try is to move only up to the collision with the triangle and then stop. in this situation i get quickly stuck as after hitting the wall i will be colliding with it immediatly again the next frame no more getting away from it.second try has been to use a back-off. hence if i hit the wall i use the sliding normal to back of 0.001 ( 1mm )of the wall and sliding along it. this prevents stuckage but not completely. if the sphere just happens to move close enough to the wall to not hit while moving but giving a hit the next frame ( due to float unpreciseness ) then i get stuck again. to get around this i used a code which detects each frame if i am stuck in geometry and moves me slightly away from it ( along the face normal ) until i'm free. yet again this can end in a race condition ( in very bad situations ). this has been the best aproach so far, but i need something else. another nasty effect is bobbing in corners which are not 90°.so i'm stuck at this point. if i allow the sphere to move tightly up to the wall i get stuck the next frame. if i allow a small gap i push away the stuck problem ( but it's not fully solved ) and i introduce nasty bobbing in corners.no matter what way i turn around i seem to always get stuck. there has to be an error margin somewhere in the algorithme to prevent stuckage but wherever i place the error margin i get stuck at another place or have nasty side effects.what's the best way to approach the problem? allowing objects to get in touch with walls while colliding or forcing them at a small gap away from the wall?   
  This has been discussed a few times in this forum, but I'm not sure where the threads are. Anyway, I also dealt with all the problems you mention when implementing swept-sphere tri-soup coldet, and was finally able to get it all worked out. I keep saying that I'll clean up my working code for this and make it available, but I haven't yet.I used a static collision resolution step in addition to the swept test to catch cases where the sphere wound up intersecting with geometry at the end of the step; it sounds like you're doing this also. For really extreme cases where even that resulted in recursion (such as the sphere being stuck exactly between two surfaces), I just bailed back to the original position after some number of iterations.As for getting stuck or bobbing in corners, I addressed this with a 'crease' vector, which is parallel to the cross product of the normals of the two surfaces. This system can be extended to handle oddly shaped corners where multiple faces come together, and produces the correct sliding response.That's about all the detail I can come up with at the moment, but I can tell you that I was very happy with the results that I got using the above methods.   ;  used that bail-out on the statis test too but for some reason if i go back to the fail-safe position i end up bobbing forth an back in come situations.one odd thing is that using the method of keeping a small gap between sphere and the wall i end up with a strange 'climbing' in 90° corners. so if i am nearly perpenticular to one of the wall faces my player starts to slowly climb up. no idea where this comes from, but is annoying.in fact i have also a bit of another, more odd thing. this 'sliding' around the map is nice and ok but i want to do some special stairs/slope code. for that i need my sphere to move around the map ignoring heights. hence on stairs those sliding spheres tend to first move up the step and then forward and then up again and so forth. in fact i want in the end the sphere to move constantly forward but hopping up steps one-by-one ( real-world movement of head is then simulated using animation and offsets ).but somehow i'm stuck there with the same problem. i use a sphere swept as first test ( and some more to detect steps and alike ). still this 'stuckage' problem and bobbing in corners exists there too so i need to fix that problem first before i can get my stairs code working.so the gap-to-wall is more robust than a close-up approach?   