Started by Mar 05 2011 02:04 PM

,
10 replies to this topic

Posted 05 March 2011 - 02:04 PM

I found a possible mistake in Brian Mirtich's phd thesis, specifically his method for resolving rigid body collisions with friction.

I've written up the details and a fixed version of the collision response algorithm here:

http://www.euclidean...rianMirtich.pdf

I've also created a small C app demonstrating the simple "2D collisions with friction algorithm" at the bottom of the following page:

http://www.euclidean...tical/index.htm

I thought maybe someone on this forum might find it useful, my apologies if I've wasted everybodys time with this post.

I don't hang out on this forum (this is my first post) if you want to contact me you can do so by email (see the pdf for my address).

I've written up the details and a fixed version of the collision response algorithm here:

http://www.euclidean...rianMirtich.pdf

I've also created a small C app demonstrating the simple "2D collisions with friction algorithm" at the bottom of the following page:

http://www.euclidean...tical/index.htm

I thought maybe someone on this forum might find it useful, my apologies if I've wasted everybodys time with this post.

I don't hang out on this forum (this is my first post) if you want to contact me you can do so by email (see the pdf for my address).

Posted 07 March 2011 - 06:05 AM

I found a possible mistake in Brian Mirtich's phd thesis, specifically his method for resolving rigid body collisions with friction.

I've written up the details and a fixed version of the collision response algorithm here:

http://www.euclidean...rianMirtich.pdf

I've also created a small C app demonstrating the simple "2D collisions with friction algorithm" at the bottom of the following page:

http://www.euclidean...tical/index.htm

I thought maybe someone on this forum might find it useful, my apologies if I've wasted everybodys time with this post.

I don't hang out on this forum (this is my first post) if you want to contact me you can do so by email (see the pdf for my address).

Its good that you've gone to the effort of writing a paper and a website article on this

The way most games handle friction these days is simply by adding another impulse to oppose tangential motion in to the already existing contact solving for normal impulse.

Using impulses instead of LCP or QP allows you to do away with all worries concerning solution-less edge-cases, and even allows you to treat static friction as well as dynamic

Cheers, Paul.

Posted 07 March 2011 - 06:42 AM

Thanks for the post

The method I describe/corrected is an impulse based method. The question is how you work out the impulse when friction is involved. The most common method I've seen is to calculate the impulse without friction lets call it J, then apply a tangential impulse of J times the coefficient of friction. However, this gives unrealistic looking simulations, and can increase the energy of the system, which even in game physics looks unacceptable.

The method I give for 3D collisions isn't particulary efficient (involves solving a differential equation numerically), but the method for 2D collisions is pretty quick it doesn't involve any loops just a series of checks to determine which case we lie in. It should be comparable to the speed of the naive approach in common use but gives much better looking results.

I thought people would be interested but so far you are the only person who's glanced at it.

Rahil

The method I describe/corrected is an impulse based method. The question is how you work out the impulse when friction is involved. The most common method I've seen is to calculate the impulse without friction lets call it J, then apply a tangential impulse of J times the coefficient of friction. However, this gives unrealistic looking simulations, and can increase the energy of the system, which even in game physics looks unacceptable.

The method I give for 3D collisions isn't particulary efficient (involves solving a differential equation numerically), but the method for 2D collisions is pretty quick it doesn't involve any loops just a series of checks to determine which case we lie in. It should be comparable to the speed of the naive approach in common use but gives much better looking results.

I thought people would be interested but so far you are the only person who's glanced at it.

Rahil

Posted 07 March 2011 - 07:57 AM

Thanks for the post

The method I describe/corrected is an impulse based method. The question is how you work out the impulse when friction is involved. The most common method I've seen is to calculate the impulse without friction lets call it J, then apply a tangential impulse of J times the coefficient of friction. However, this gives unrealistic looking simulations, and can increase the energy of the system, which even in game physics looks unacceptable.

No problem

What i do when calculating an impulse with dynamic friction is this:

Calculate relative normal velocity, compute normal impulse.

Calculate relative tangential velocity (just the total velocity minus the the velocity in direction of normal), compute impulse.

The tangential impulse magnitude should be clamped at the normal impulse magnitude, of course, to stop it being too strong (it would still never introduce energy, though even without this). Its also scaled by the coefficient of dynamic friction (between 0 and 1)...

No energy is ever added to the system this way, since we're only ever removing velocity...

The method I give for 3D collisions isn't particulary efficient (involves solving a differential equation numerically), but the method for 2D collisions is pretty quick it doesn't involve any loops just a series of checks to determine which case we lie in. It should be comparable to the speed of the naive approach in common use but gives much better looking results.

I thought people would be interested but so far you are the only person who's glanced at it.

Rahil

People do read these threads, just takes time

Cheers, Paul.

Posted 07 March 2011 - 10:09 AM

Sorry it seems it takes a while for the board or my browser to update the view counter on this post. For the past 2 days it read 0 views but it has suddenly shot up to 139.

I agree your method doesn't sound like it causes an increase in energy, though I'm not sure I completely understand it. My understanding is this:

1) find the impulse in the normal direction using "the standard" frictionless impulse equation and apply the impulse.

2) find the impulse in the tangent direction by imagining the object is colliding with an imaginary perpendicular surface (do you still use the coefficient of restitution in this impulse calculation?)

3)Scale the impulse by the coefficient of friction.

4)Check if the tangent impulse is larger then the normal impulse if so reduce the tangent impulse to the same size. Then apply the tangent impulse.

Is this your algorithm?

I agree your method doesn't sound like it causes an increase in energy, though I'm not sure I completely understand it. My understanding is this:

1) find the impulse in the normal direction using "the standard" frictionless impulse equation and apply the impulse.

2) find the impulse in the tangent direction by imagining the object is colliding with an imaginary perpendicular surface (do you still use the coefficient of restitution in this impulse calculation?)

3)Scale the impulse by the coefficient of friction.

4)Check if the tangent impulse is larger then the normal impulse if so reduce the tangent impulse to the same size. Then apply the tangent impulse.

Is this your algorithm?

Posted 07 March 2011 - 11:48 AM

Sorry it seems it takes a while for the board or my browser to update the view counter on this post. For the past 2 days it read 0 views but it has suddenly shot up to 139.

I agree your method doesn't sound like it causes an increase in energy, though I'm not sure I completely understand it. My understanding is this:

1) find the impulse in the normal direction using "the standard" frictionless impulse equation and apply the impulse.

2) find the impulse in the tangent direction by imagining the object is colliding with an imaginary perpendicular surface (do you still use the coefficient of restitution in this impulse calculation?)

3)Scale the impulse by the coefficient of friction.

4)Check if the tangent impulse is larger then the normal impulse if so reduce the tangent impulse to the same size. Then apply the tangent impulse.

Is this your algorithm?

1) is correct

2) The target is to form the tangential velocity - which is what we would like to remove some of; this is simply the total velocity minus the normal velocity. Once we have this we can compute an impulse to reduce it. I never deal with restitution in any of my physics engines over the years; games never seem to call for it....

3) is correct

4) is mostly right, there are some subtleties involved here since the solver is an iterative accumulated impulse solver...

Cheers, Paul.

Posted 07 March 2011 - 12:22 PM

Sounds like a similar system to Box2D. Thanks for the info.

Posted 07 March 2011 - 01:06 PM

Sounds like a similar system to Box2D. Thanks for the info.

Yes, exactly - but in 3d

To test it you don't need sequential impulses, you can just do as you say and clamp once

Posted 07 March 2011 - 06:18 PM

Using impulses instead of LCP or QP

Sequential impulse, like in Box2d or Bullet in 3D and quickstep in Open Dynamics Engine are all equivalent to projected gauss seidel/successive overrelaxation.

So sequential impulse is an iterative method to solve the LCP, and the word "instead" is not applicable.

When you add friction constraint rows where the clamping values depend on previous contact normal constraint rows, it becomes a non-linear complementarity problem/NCP, but let's not nitpick about that.

Sequential impulse differs from Brian Mirtich's 'impulse based dynamics', even though they both have the word 'impulse' in the name. Sequential impulse is in fact a constraint based formulation, but intuitively explained by Erin Catto.

Thanks for the long write-up rahilbaber, I hope to read it soon.

Thanks,

Erwin

Posted 08 March 2011 - 08:22 AM

Thanks Erwin.

I doubt you'll learn much from my document if you're familar with Mirtich's thesis. The key differences are always integrate with respect to p_z (not u_z) and be aware that two compression/decompression phases can occur. The derivation becomes simpler when you don't have to worry about integrating with u_z, so I thought it would be worth rewriting also I collected the formulas in one place to make an explicit algorithm for people who aren't concerned with the technical details.

The LCP approach to sliding contacts seems really interesting as does the SI / PGS method of solving them. I hope to really understand the Bullet implementation in the very near future. Are you planning on creating any documents to explain how Bullet works for simpletons like me who are less knowledgeable of the whole LCP and PGS approach. I am aware there are slides and source code available for download but a not overly technical document fully explaining the key ideas would be great.

Rahil

I doubt you'll learn much from my document if you're familar with Mirtich's thesis. The key differences are always integrate with respect to p_z (not u_z) and be aware that two compression/decompression phases can occur. The derivation becomes simpler when you don't have to worry about integrating with u_z, so I thought it would be worth rewriting also I collected the formulas in one place to make an explicit algorithm for people who aren't concerned with the technical details.

The LCP approach to sliding contacts seems really interesting as does the SI / PGS method of solving them. I hope to really understand the Bullet implementation in the very near future. Are you planning on creating any documents to explain how Bullet works for simpletons like me who are less knowledgeable of the whole LCP and PGS approach. I am aware there are slides and source code available for download but a not overly technical document fully explaining the key ideas would be great.

Rahil

Posted 08 March 2011 - 09:25 AM

So sequential impulse is an iterative method to solve the LCP, and the word "instead" is not applicable.

It is applicable when the traditional way to solve a system of constraints using LCP or QP involves generating a giant, inefficient matrix of constraints and sending this off to a memory hungry 'solver' which knows nothing about the problem domain and can quite easily 'die' with an infeasible solution.

Using impulses as the work-horse tool to solve a problem that can be expressed as an LCP is to me a very different thing than solving a general LCP

Cheers, Paul.