Skip to main content
gamedev.net
🔒 Locked

Physics engine bugs

Started by Orwin Mar 24, 2006 at 5:03 AM 5 replies 1k views
Original Post
Orwin
Orwin
Hey, I wrote a small physics engine for my 2D car racing game, but for unknown reasons it often doesn't run correctly. You can download it here : http://zone51da.free.fr/physikv2.zip (wait a few seconds before moving the car) As you can see, when there is a collision the cars often stick themselves, an aberrant collision response is calculated and I don't understand why. But perhaps you will understand after my explanations : //Car movements I use 4 forces to move the cars : - Propulsion force - Air friction - Left brake (for turning) - Right brake These forces are applied to the car center to create an angular momentum (with the famous crossproduct formula). Then I integrate the result to determine the velocity and I integrate again to determine the car position and the car angle. //Collision detection If a car1's vertex is into the car2's polygon, or conversely, the engine will detect a collision. This algorithm is efficient but the second step, side contact detection, is less obvious : I select the side which is nearest of the vertex contact and I memorize the distance (called dist) between this side (called cSide) and the vertex contact. //Collision response I noted that adding the vector R to the current velocity is sufficient to compensate the velocity component in cause of the collision. R = normal(cSide)*dotproduct(normal(cSide),-current_velocity) i.e, the projection of the velocity vector on the cSide normal. Or R' = (1+E)*normal(cSide)*dotproduct(normal(cSide),-current_velocity) where E is a rebound coefficient. Thus the new velocity is : V(t) = V(t-1) + R So to calculate the reaction force RF after a collision, I use the acceleration definition : RF = m * acceleration = m * dV/dt = m*(V(t) – V(t-1))/dt = m*R/dt RF = m*normal(cSide)*dotproduct(normal(cSide),-current_velocity)/dt I try to take into account the parameter dist but the results are not better. Any idea ? [Edited by - Orwin on March 24, 2006 5:24:46 AM]
someusername
someusername
Objects sticking together after a collision is a quite usual phenomenon...
99% of the times it happens because, although people resolve the collision (they calculate the response forces/changes in velocity etc.), they leave the objects in a position where they still intersect! In fact they don't even change the objects' positions at all!
This is obviously wrong if you actually wanted to handle the collision. The collision detection will still flag a collision between them in the next frame... and in the second next frame... and so on!
When you find that two objects collide, before you do anything else, move them back (using their current velocities) by as much as necessary until they don't collide. Then do your OnCollision() stuff.


And something else...
Quote:

So to calculate the reaction force RF after a collision, I use the acceleration definition :
RF = m * acceleration = m * dV/dt = m*(V(t) – V(t-1))/dt = m*R/dt
RF = m*normal(cSide)*dotproduct(normal(cSide),-current_velocity)/dt

The response force should be:
RF = "mass" times "the acceleration that RF will exert on the car",
thus:
RF = m*( "velocity after collision" - "velocity before collision")/"duration of collision"

What you're actually doing is: RF = "mass" times "car's acceleration upon impact".
This is why it doesn't look good.
To find the car's speed after collision, you can model is as inelastic collision of two point masses. Hit ""coefficient of restitution" in wikipedia. It will take you right to the formulae you should use.


And one last thing.
Quote:

These forces are applied to the car center to create an angular momentum (with the famous crossproduct formula).

The things you're talking about need a 3rd dimension in order to be defined, but your demo is 2D. How is that? Is the entire infrastructure in 3D and you're just drawing things 2D?
someusername
someusername
Haven't dealed with these in two dimensions AP, but I think what you're talking about is the perpendicular dot product operator.

From what I know, the cross product z of two vectors x,y in n-dimensional space is defined as:
zi = eijk*xj*yk, i=1,...,n
where eijk is the permutation tensor.

What meaning would this expression have in less than three dimensions?
To begin with, the permutation tensor would always degenerate to zero since its indices can never take 3 mutually different values.
Orwin
Orwin
Quote:
When you find that two objects collide, before you do anything else, move them back (using their current velocities) by as much as necessary until they don't collide. Then do your OnCollision() stuff.

Ok. I have updated the engine here: http://zone51da.free.fr/physikv2a.zip

Quote:
RF = m*( "velocity after collision" - "velocity before collision")/"duration of collision"

For me, "velocity before collision" = V(t-1).
And, "velocity after collision" = V(t-1) + R according to my geometric observations (http://zone51da.free.fr/rebond_en.gif)
Therefore:
m*("velocity after collision" - "velocity before collision")/dt
= m*(V(t-1) + R - V(t-1))/dt
= m*R/dt

Quote:
The things you're talking about need a 3rd dimension in order to be defined, but your demo is 2D. How is that? Is the entire infrastructure in 3D and you're just drawing things 2D?

Yes, I use 3D-vectors for drawing 2D-cars :)




Promit
Promit
Quote:
Original post by someusername
Haven't dealed with these in two dimensions AP, but I think what you're talking about is the perpendicular dot product operator.

From what I know, the cross product z of two vectors x,y in n-dimensional space is defined as:
zi = eijk*xj*yk, i=1,...,n
where eijk is the permutation tensor.

What meaning would this expression have in less than three dimensions?
To begin with, the permutation tensor would always degenerate to zero since its indices can never take 3 mutually different values.
Curious that you can talk about tensors no problem, yet you don't know a fundamental detail of mechanics. Anyway, angular momentum/acceleration is defined as a vector perpendicular to the plane of rotation, with the direction of rotation choosing the direction of the vector. Which means that the angular momentum in a 2D space is still 3 dimensional, but two dimensions will always be 0, and the third will be x or -x, where x is angular speed and the sign indicates direction.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
someusername
someusername
Quote:
Original post by Promit
Curious that you can talk about tensors no problem, yet you don't know a fundamental detail of mechanics.

To satisfy your curiosity, I studied maths, not newtonian mechanics...
Is there some particular reason why anyone with a basic understanding of tensor notation should also be good in mechanics?

Quote:

Original post by Promit
Anyway, angular momentum/acceleration is defined as a vector perpendicular to the plane of rotation, with the direction of rotation choosing the direction of the vector. Which means that the angular momentum in a 2D space is still 3 dimensional, but two dimensions will always be 0, and the third will be x or -x, where x is angular speed and the sign indicates direction.

I thought angular momentum/velocity reduced to scalars in 2d. I'll take your word on it.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.