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???
e=1, behaving as super-elastic collision
-
- Posts: 63
- Joined: Tue Mar 27, 2012 7:20 am
- Location: India
- Contact:
e=1, behaving as super-elastic collision
- Attachments
-
Restitution.xml
- (20.05 KiB) Downloaded 405 times
Re: e=1, behaving as super-elastic collision
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.
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
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
-
- Posts: 63
- Joined: Tue Mar 27, 2012 7:20 am
- Location: India
- Contact:
Re: e=1, behaving as super-elastic collision
Sorry to revive the old topic again..
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.
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?
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 (13.83 KiB) Viewed 1905 times
Re: e=1, behaving as super-elastic collision
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.
Still trying to see if anything can be done about it.
William
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.
- t1: A and B velocities are integrated
- t1: Collision resolution (none in this step)
- t1: A and B positions are integrated
- t1: A and B are detected to be in collision after moving according to their velocities
- END: A's velocity = (0, -1)
- t2: A and B velocities are integrated
- t2: A's velocity = (0, -1 + g * dt) = (0, -1.25)
- t2: A and B collision is resolved
- t2: A's velocity = (0, 1.25).
- t2: A and B positions are integrated
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 1 guest