e=1, behaving as super-elastic collision

Posts that don't fit into other categories.
maheshkurmi
Posts: 63
Joined: Tue Mar 27, 2012 7:20 am
Location: India
Contact:

e=1, behaving as super-elastic collision

Postby maheshkurmi » Tue Apr 02, 2013 11:56 am

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???
Attachments
Restitution.xml
(20.05 KiB) Downloaded 265 times

William
Site Admin
Posts: 378
Joined: Sat Feb 06, 2010 10:23 pm

Re: e=1, behaving as super-elastic collision

Postby William » Wed Apr 03, 2013 8:06 am

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
Posts: 63
Joined: Tue Mar 27, 2012 7:20 am
Location: India
Contact:

Re: e=1, behaving as super-elastic collision

Postby maheshkurmi » Wed Mar 21, 2018 9:27 am

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?
Attachments
superelastic collison.png
superelastic collison.png (13.83 KiB) Viewed 793 times

William
Site Admin
Posts: 378
Joined: Sat Feb 06, 2010 10:23 pm

Re: e=1, behaving as super-elastic collision

Postby William » Mon Mar 26, 2018 8:00 pm

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


Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 2 guests