Question: Restitution causing explosive forces with friction

[e2-dunstan]

Apologies, not sure where else to ask this. I've been following the book for implementing a physics engine and looking at the source code here for reference.

There seems to be a problem with the calculation for FrictionImpulse. It seems to work absolutely fine until bodies with restitution are introduced. Any contact with a coefficient of restitution greater than 0.5 is guaranteed to cause explosive forces, and it's highly likely for values lower than that too. Often the objects just disappear out of existence due to such high changes in velocity.

I believe the problems come from the dynamic friction calculations and the use of the desired delta velocity (only var which is influenced by restitution).

Has anyone come up with a solution to this sort of thing? Thanks.

[qwiff-dogg]

I'm following the book as well, making my own engine implementation. It's hard to gauge what the cause of explosive forces is in your case, as it depends on the arrangement of your scene.

In my case I can cause explosive forces between rigid bodies by placing them in close proximity and causing a collision. As the collision resolution is based on moving interpenetrating objects apart, this will cause a chain reaction of impulses, leading to an explosion-like effect.

This is as expected and a result of rigid bodies having nowhere to go (since they can't compress), hence the build-up of impulses during resolution.

See the screencap for an example. The restitution is set to 0. The impulses are calculated using the "friction" algorithm here. https://github.com/idmillington/cyclone-physics/blob/master/src/contacts.cpp#L350-L375, but I can reproduce it using the frictionless version as well.

So the only suggestion I can give is that the effect that you're seeing may simply be a result of the collision resolution algorithm. Increasing restitution only makes the result more visible.

Hope this helps. I know it's an old issue.

[owen-1108]

This is an old issue but it seems that the underlying issue with the contact resolution in this book comes down to the contact matrices. It would appear that the matrices are using an {XZY} convention in leu of the standard {XYZ}. Looking at https://github.com/idmillington/cyclone-physics/blob/d75c8d9edeebfdc0deebe203fe862299084b1e30/src/contacts.cpp#L76-L89 This only works if contactTangent[0] & contactTangent[1] are a result of normal x {0,1,0}=Zcontact & normal x contactTangent[0] =Ycontact respectively. Later in the code contactToWorld.setComponents(contactNormal,contactTangent[0], contactTangent[1]); Consider the case where normal = {1,0,0} then contactTangent[0] becomes {1,0,0} x {0,1,0} = {0,0,1} and contactTangent[1] becomes {0,0,1} x {1,0,0} = {0,1,0}. Following the setComponents function the following matrix will be |1 0 0| // 1 2 3 Books Row-Major access layout |0 0 1| // 4 5 6 |0 1 0| // 7 8 9 After swapping the Z and Y elements stability improved however it was not great still. The case where Z was the most major component in the contacts was causing numerical errors and following the same process presented in the book, after adding in the Z case stability again improved but the simulation would still break under "reasonably" intense conditions. When printing out the determinates of the contact matrices both positive and negatives where being presented which lead to testing out the Gram-Schmidt process using the normal as v1 and the expected orthonormal base respecting a right handed system choosing the corresponding v2 and v3 as the expected unit vectors (Imagine rotating the normal 3D axis to where normal is where {1,0,0} is). This dramatically improved stability across the entire simulation.

I hope this may help anyone who needs it with this section of the book