Sliding collisions again
My earlier post on this topic was a book, so I'll simplify it a little .
on www.gametutorials.com, there is a tutorial on sliding collisions that takes this approach:
Assume that nothing exists in the world except triangles (a fair assumption in OpenGL for sure).
Collision-check every single triangle in the world one at a time with the camera (his simple example didn't involve octrees or BSP trees but I'm sure they could speed up the processing).
Let's call the minimum distance the camera should be from any surface "radius". As each triangle is checked, if the camera is more than 0 units but less than radius away from it, move the camera along that triangle's normal until it's radius units away.
A very simple, very well-defined approach. I have 2 questions:
1. Am I correct that if the camera's velocity is greater than radius, it's possible to go from the front of a surface to all the way behind the surface, bypassing the region in which the collision check would take place? Off the top of my head, you could keep an array of distances last frame and then you collision check would be, was it more than radius last frame and less than radius this frame? And then move along the triangle's normal until he's radius units in front of it. I can't think of a better solution than that.
2. I believe (and I've asked him to verify) that if 2 triangles have an acute angle between them that the results might be unexpected. This is hard to explain without a picture so I won't write a book, but I do believe that an acute angle will throw this off, and it seems to me that a rigorous solution that guarantees sliding the user out to a point that's radius units in front of every triangle could get very complicated - for example, if he's walking inside a cone.
Any thoughts on #1 or #2 here? Anyone else encountered this?
Re: Sliding collisions again
Sorry, your post is offtopic. You'll have more success if you post to a more generic math / physics / collision forum instead of a forum focusing on a graphics API.