Hello,
At bepu 1 each entity can have a friction and a bounciness, in v2 we need to calculate a physics material between two objects.
Which is the formula to have a friction and bounciness similar to bepu1? I'm interested at the extremes 0 and 1, and only one object is kinematic.
How does the inertia.InverseInertiaTensor affects those values?
Regards.
[V1 to v2]Friction and bounciness
Re: [V1 to v2]Friction and bounciness
v1 had a callback that could be set to anything, but the default was multiplicative: https://github.com/bepu/bepuphysics1/bl ... ger.cs#L77Which is the formula to have a friction and bounciness similar to bepu1?
It's worth noting that bounciness does not exist as it did in v1: https://github.com/bepu/bepuphysics2/issues/52
It comes with some fundamental issues, so I've been waiting to see how long I can get away with not having it at all
![Razz :P](./images/smilies/icon_razz.gif)
The inertia tensor affects angular motion. You can think of it as 'angular mass'. Objects with higher inertia around an axis will require larger torques to achieve the same angular acceleration around that axis. So it's not directly related to material properties, but a very low inertia (or high inverse inertia) object will be more likely to roll instead of slide, all else being equal.How does the inertia.InverseInertiaTensor affects those values?
-
- Posts: 5
- Joined: Mon Jul 06, 2020 10:32 am
Re: [V1 to v2]Friction and bounciness
None of the demos can show how to implement a ball free fall to the ground and then bounce in V2, even if the shot ball hits the ground, it does not bounce, that is too abnormal. Can you simply implement a boundciness example, or show the key code shows how to implement it?
-
- Posts: 5
- Joined: Mon Jul 06, 2020 10:32 am
Re: [V1 to v2]Friction and bounciness
Wow,I see the demo after i add it to demo set,that's amazing , thank you for your quick reply and the fast coding. cheers! ![Very Happy :D](./images/smilies/icon_biggrin.gif)
![Very Happy :D](./images/smilies/icon_biggrin.gif)
-
- Posts: 5
- Joined: Mon Jul 06, 2020 10:32 am
Re: [V1 to v2]Friction and bounciness
In fact, what I want is to simply implement the Unity3d's physic material parameters through "hack" method,I really don't like the spring setting...
physic material{
dynamic friction,
static friction,
bounciness,
friction combine method: average,
bounce combine method:average,
}
But i don't know how to do it with INarrowPhaseCallbacks...
physic material{
dynamic friction,
static friction,
bounciness,
friction combine method: average,
bounce combine method:average,
}
But i don't know how to do it with INarrowPhaseCallbacks...
Re: [V1 to v2]Friction and bounciness
There is no exact mapping of coefficient of restitution/bounciness to v2's parameters.
-Damping ratio of 0 is undamped, which corresponds to a full bounce. In practice, the timestep durations necessary for real time simulation will introduce extra damping when the true version of the simulation can't be faithfully integrated, hence why increasing substep counts can help.
-Damping ratio of 1 is critically damped, which means position error will be corrected as quickly as possible without overshooting.
-Damping ratios above 1 remove even more energy, causing error to be corrected even more slowly.
In theory, the frequency value shouldn't affect a bounce at 0 damping, but it does due to the integrator's limitations. Lower frequency values- 5 to 15 as a first guess- can make it easier since the impacts as squishier and last more frames. Higher substep counts (shorter timestep durations) allow higher frequency values with the same behavior.
You could blend the spring settings in different ways to get something similar to an 'average' blend versus 'min' or 'max'. You may want to make it simpler and simply flag objects as bouncy or not; bouncy objects would have a float.MaxValue maximum recovery velocity and whatever frequency you can handle at the simulation timestep size you're using, and then configure 'bounciness' by blending the damping ratios. You could convert a coefficient of restitution of 1 to a damping ratio of 0, and a CoR of 0 to a damping ratio of 1. There's no rigorous physical basis for that, but if you squint it accomplishes something similar.
You could also try to track impacts across frames and adjust velocities accordingly to hack in a standard coefficient of restitution style velocity bias, but it's going to be very tricky to produce the expected impulse without modifying the constraints. Even if you went that far, you'd still have to deal with the incompatibility of the velocity bias approach and speculative contacts, and there is simply no good solution there.
-Damping ratio of 0 is undamped, which corresponds to a full bounce. In practice, the timestep durations necessary for real time simulation will introduce extra damping when the true version of the simulation can't be faithfully integrated, hence why increasing substep counts can help.
-Damping ratio of 1 is critically damped, which means position error will be corrected as quickly as possible without overshooting.
-Damping ratios above 1 remove even more energy, causing error to be corrected even more slowly.
In theory, the frequency value shouldn't affect a bounce at 0 damping, but it does due to the integrator's limitations. Lower frequency values- 5 to 15 as a first guess- can make it easier since the impacts as squishier and last more frames. Higher substep counts (shorter timestep durations) allow higher frequency values with the same behavior.
You could blend the spring settings in different ways to get something similar to an 'average' blend versus 'min' or 'max'. You may want to make it simpler and simply flag objects as bouncy or not; bouncy objects would have a float.MaxValue maximum recovery velocity and whatever frequency you can handle at the simulation timestep size you're using, and then configure 'bounciness' by blending the damping ratios. You could convert a coefficient of restitution of 1 to a damping ratio of 0, and a CoR of 0 to a damping ratio of 1. There's no rigorous physical basis for that, but if you squint it accomplishes something similar.
You could also try to track impacts across frames and adjust velocities accordingly to hack in a standard coefficient of restitution style velocity bias, but it's going to be very tricky to produce the expected impulse without modifying the constraints. Even if you went that far, you'd still have to deal with the incompatibility of the velocity bias approach and speculative contacts, and there is simply no good solution there.