Rigidbodies Slide at Rest

[hjmediastudios]

So I've been working on a game using the Urho3D engine, which uses Bullet for physics. The game itself takes place on a small spherical planetoid, with the gravity at the center. On each physics-engine "step," all rigidbodies in the scene have a force applied on them toward the center of the (static rigidbody) planetoid. This works well until the bodies hit the planet surface, at which point they react appropriately and should come to a complete stop. The problem is that once the bodies have stopped moving toward the planet (i.e. they're fully settled on the surface), they continue to slide along the surface, very slowly- they seem unable to come to a complete stop despite the fact that they're solidly placed on the planet surface. The sliding seems more or less patternless- many bodies will slide along the planet counterclockwise, but some slide clockwise or "sideways" across the surface.

I've tried a number of different things to resolve this:

1. Increasing the friction, both linear and rolling, on the rigidbody and the planet. This has no visible effect, even when the friction is set to an absurdly high value or even an "infinity" value.
2. Increasing the linear and angular damping on the bodies. This has an effect, for sure; the bodies make a far more sluggish descent to the surface, but once they hit the planet, their sliding continues as normal, with no visible difference in speed between the damped and undamped versions.
3. Adjusting the collision margin on both the bodies and the planet- besides the bodies "sinking" a little deeper into the planet, this has no effect, and the sliding continues unabated.
4. Changing the collision shape type of the planet. The bodies all have standard box or capsule colliders (which seems to make no difference in the sliding). The planet collider, for game reasons, needs to be a triangle mesh collider, although I have tested a perfectly-spherical planet using a sphere collision shape, with no effect on the sliding.
5. Manually setting the linear velocity to zero on each physics update. This stops the sliding, but it also stops all other motion.

I've done a lot of testing on the Urho3D side of things, and the problem seems to be an issue in the Bullet simulation itself. The values are passed from Urho3D to Bullet, and vice versa, just fine.

Can anyone perhaps provide some insight as to what's going on here, and how to fix it?

[Flix]

I've tried this myself, and with a minimal tweaking of the rigid body parameters (friction,damping and sleeping threshold) I was able to get good results (see attached file).

RoundWorldDemo.7z

(The only drawback is that libOpenGLSupport uses too few sections to render spheres: the result is that when the left mouse button is pressed, the boxes that are shot seem to float in the air a bit over the surface... but this does not apply to your case of course).

P.S. It could be cool to find some algorithm to calculate the "per body gravity" of objects in a world made by a btCompoundShape with many btMultiSphereShapes in it

[Daixiwen]

I'm just guessing here, maybe a Bullet guru can correct me
I think that the problem comes from the fact that the physics simulation is discreet and assumes that the force is constant during the whole simulation step, but in fact it isn't. If you have a look at the schematic below (force in red, speed in blue), Bullet will assume that the red force is always facing down. You only correct the force vector after the step has been finished, and then it's too late. This will especially be a problem if you have substeps, but it may also be the case within a substep. Bullet sees your system as an unstable equilibrium.


If this is what is happening, I don't see any easy way to correct it. It may be possible to offset the sphere centre by a fraction of the speed opposite (see below schematic, it's a lot easier to explain that way ) when you apply the force to an object colliding with the sphere, but I'm not sure that would be very stable. Another way would be to damp the velocity yourself after the simulation step, again only for the objects colliding with the sphere.

[hjmediastudios]

Flix: Thanks, I'll take a look at what you've got and report back.
Daixiwen: I'm pretty sure what you describe is not my issue; I have disabled the automatic gravity and call the appropriate addForce() method on each body before I run the physics solving step.

[Daixiwen]

I don't think it matters that much. The problem I described in my first drawing doesn't only apply to gravity, it is the same when using ApplyForce(), simply because the direction of the force that you apply with ApplyForce() won't change during the step. It will only be reoriented towards the sphere centre the next time you call ApplyForce().

[Basroil]

Have you tried Sphere-sphere collision?

[Bauer]

Had a similar problem in Urho3D. However, in my case I had a Box and a StaticPlane CollisionShape. For me, the Box stopped gliding around once I set all Box angularFactors to 0.