e=1, behaving as super-elastic collision

[maheshkurmi]

In Restitution example (in Tests) when the value of coefficient of restitution is set to 1 (rightmost disc in attached example), it appears as super-elastic collision
speed of disc appears to increase after each collision, any Idea why???

[William]

This is due to floating point precision and the iterative nature of the collision resolution solver. Changing the restitution to 0.98 makes the last circle act as if it has a restitution of 1.0. If this is for learning physics, you can, in the interface allow them to set the restitution to 1.0, but use 0.98 by supplying your own CoefficientMixer.

Code: Select all

public class CustomMixer extends CoefficientMixer {
  public double mixFriction(double f1, double f2) {
    // just do what the default does
    return CoefficientMixer.DEFAULT_MIXER.mixFriction(f1,f2);
  }
  public double mixRestitution(double r1, double r2) {
    // just do what the default does
    double r = CoefficientMixer.DEFAULT_MIXER.mixRestitution(r1,r2);
    // the custom code (only return restitutions of 0.98 or less)
    return Math.min(r, 0.98);
  }
}


When a collision happens both body fixtures in the contact have their own restitution values; so they must be combined into one to solve the contact. Mixing the restitution values is the purpose of the CoefficientMixer. This CoefficientMixer does not change the fixture restitution values.

The Sandbox app allows even higher values of restitution than 1.0, so the clamping in the code above may be useful elsewhere.

William

[maheshkurmi]

Sorry to revive the old topic again..

This is due to floating point precision and the iterative nature of the collision resolution solver. Changing the restitution to 0.98 makes the last circle act as if it has a restitution of 1.0.

IMHO his seems to be incorrect explanation, since it is gravity rather than collision resolver which is the culprit here.
e=1 behaves absolutely correct in absence of gravity, and almost no energy is gained even after thousands steps.

For the example attached in topic, my observations are..
The speed of body increases due to gravity even after collision with the ground for extra distance(penetration length), and collision resolver sets this speed after resolving collision, which leads to additional kinetic energy mge (where e is penetration length).

the gain in energy becomes unacceptable in case of polygonal small objects where penetration is high.

If this is for learning physics, you can, in the interface allow them to set the restitution to 1.0, but use 0.98 by supplying your own CoefficientMixer.

The solution can't work as penetration depends on speed and height which is variable thats why correction factor needed is also variable.

Is there any solution now? can we compensate for the extra gravity impulse in collision resolver?

[William]

Looking at this deeper, here is what is happening:

Imagine two bodies, A and B. A is a ball falling and B is a floor. t1 and t2 represent 2 timesteps, one after another.

1. t1: A and B velocities are integrated
2. t1: Collision resolution (none in this step)
3. t1: A and B positions are integrated
4. t1: A and B are detected to be in collision after moving according to their velocities
5. END: A's velocity = (0, -1)
6. t2: A and B velocities are integrated
7. t2: A's velocity = (0, -1 + g * dt) = (0, -1.25)
8. t2: A and B collision is resolved
9. t2: A's velocity = (0, 1.25).
10. t2: A and B positions are integrated

So the problem is that the additional downward acceleration by gravity is added to A, but before we apply that additional acceleration to A's position, we resolve the contact - which flips the velocity. Then, when we advance A's position it moves up farther than it should due to the extra gravity added at the beginning of t2.

Still trying to see if anything can be done about it.

William