Original Post
Hi, Myself and a friend have used the NeHe tutorials to make an Open GL graphics engine and have implemented a custom physics collision response system which works well with our player models (which are always spherical for the implementation we have in mind). However, as soon as we implement gravity we hit a problem. All of our 'forces' and positions are vectors. Currently each tick of our engine works like this: Add current velocity to gravity, friction and drag acting on the player. Add this to the current position and store it as 'proposed position' Run collision checking: Check if the 'proposed position' will collide using ray-triangle intersection. If it does Find intersection point by looking at range to collision and multiplying the normalised velocity vector by the range to collision which is taken in terms of (-length(velocity) to +length(velocity)) hence the value is effectively the percentage of the velocity we moved before colliding. We make the position of the player this position (taking into account the radius so that the player only just touches the triangle it collided with). We find the surface normal of the triangle we collided with and multiply with the dot product of the inverse velocity and the normal. Then we double this value and add it to the velocity to get the resultant velocity. This is scaled by the "elasticity" of the material and it is used in the frame of collision to add on the distance that was not traveled (the percentage we moved past the collision point) in the direction of the new velocity. [This all works great for surface-surface collision in the level, although we have a little hack in for the radius so that you actually only collide at the point of your radius that intersects the velocity if drawn from the centre of the actor.] If it does not We make the position of the player the 'proposed position' and make the new velocity the velocity calculated earlier. Then we draw the player at their position. The problem seems to be that when the player collides with the floor (due to gravity) it bounces up (as you'd expect) and then drops and bounces and drops and bounces and drops and bounces and so on and so forth until it is shaking the screen enough to give you a major headache. We have tried stopping the model moving if the velocity is too small but all this does is make the model almost impossible to move because it's stuck in the floor. If we damp the collisions the same problem happens. We have tried everything we can think of to effectively stop gravity occuring when you are colliding but we then just bounce higher because we have no gravity acting on us then you go above the collision 'zone' so we bounce again! We apply gravity as -9.8/framerate because we use 1unit to 1m conversion (-9.8Nm per second= 1Kg at 9.8m/s acceleration). We actually apply it by adding this value onto the velocity as described above. My friend likes Newtonian Physics, I like quantum physics so to him gravity is a downward push, to me it is a inverse upwards pull so it is entirely possible we are messing up the way we equate gravity. So, 1. Is there a better way to apply gravity to avoid this problem? Ideally I'd like to apply gravity inversely proportional to height, however we use a dynamic map so I can think of no really clever way to tell where the 'floor' is because we must be able to use ramps. [I should point out that using a different system we perfectly modelled gravity when we don't have ramps because you can entirely cancel velocity when colliding but this means you don't roll down ramps] 2. If not, is there a way to avoid the bouncing? We have hacked the engine by only using spheres so we don't mind hacking gravity too. Any other advice would be appreciated! Thanks for any help in advance, - Peter
