Skip to main content
gamedev.net
🔒 Locked

particles collision response

Started by vo1d May 24, 2006 at 11:50 AM 3 replies 850+ views
Original Post
vo1d
vo1d
Hi, please help with collision response in 3d! For example there is 3d scene with particles: * * * * ------ Each particle has position, velocity, force, radius, mass, elasticity
Bob Janova
Bob Janova
Although I posted this in a thread about 2D collision response, the same equations work for sphericl particles colliding in 3D.

Quote:
Original post by Bob Janova
The COR[coefficient of restitution] as I understand it is just the 'elasticity' of the collision, i.e. a post-multiplier *in the zero momentum frame* (more on that in a sec) of the final velocities.

The way we were taught this collision response in my physics course is as follows:

  • Transform the velocities of the objects into a zero-momentum frame (ZMF), i.e. where the total momentum of the bodies involved is zero. This is easy enough: the total momentum in the world frame is sum(mass×velocity), so the velocity of the ZMF is sum(mass×velocity)/2. To transform object velocities into the ZMF, just subtract that amount from them.
  • Perform the collision elastically. In a ZMF two-body collision, the objects head straight towards each other and leave in opposite directions, with opposite momenta. The final direction is controlled by the direction of the impulse, which for spheres is just a normalised version of r1-r2 (the displacement of centres) – henceforth d – and the magnitude is 2mv.d. Thus the final momentum of particle 1 in the ZMF is m1(v1-init+2(v1.d)d), and that of particle 2 the opposite.
  • If the collision is not elastic, multiply both momenta by the elasticity factor (0 to 1).
  • Transform the new velocities back into the world frame by adding sum(mass×velocity)/2 back in. (Opposite of step 1.)


[If the masses are the same you can ignore them and just work with velocities instead of momenta, but it may be best not to if you ever think you might have heavier circles. (the question here was about constant-mass particles)]

Remember to normalise the direction vector! Your collision detection ought perhaps to calculate this direction.

If you move onto non-spherical objects, where the impulse is not through the centre of each object, this method fails because it doesn't take account of angular momentum and angular KE. That's not a problem for you yet, but just a little heads-up.

Edit: The sign in m1(v1-init+2(v1.d)d) might be a minus sign, depending on which direction d is in. I'm notoriously bad with signs, so if your objects go in the wrong direction try the other one!


vo1d
vo1d
What means sum in "sum(mass×velocity)/2" ?

In "m1(v1-init+2(v1.d)d)"
v1.d - dot product ?
Bob Janova
Bob Janova
Quote:
What means sum in "sum(mass×velocity)/2" ?

The sum of (mass×velocity) for all (both) objects in the system, i.e. the total momentum present.

Actually, come to think of it that probably ought to be sum(mass×velocity)/sum(mass).

Quote:
v1.d - dot product ?

Yes.
vo1d
vo1d
second problem: if one particle come into other ( |p1-p2| < r1 + r2 ), position must be restored before collision response:

// restore position
normal = {p1 - p2) / dist
z = normal * (r1 + r2 - dist) * 0.5
p1 += z
p1 -= z

// response
vrel = v1 * n - v2 * n

if(vrel < 0)
{
j = -vrel * c / ((1 / m1) + (1 / m2))
n *= j
v1 += n * (1 / m1)
v2 -= n * (1 / m2)
}

if don't do it, response works bad for my first example, upper particles move down into lower

how to fix it?

sorry for my bad English :(

Topic Locked

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

Sign in to reply to this topic.