Dropping a box over a plane: timestep issue?

[silene]

I'm new to Bullet; I have discovered it while trying to combine a physics engine with Ogre. More precisely, I have been playing with the tutorial from OgreBullet (since I wanted to quickly experiment the combination of Ogre and Bullet). By the way, the Bullet version is 2.78.

The aforementioned tutorial is quite simple: you just throw a box, it drops on a static plane, it rolls/bounces a bit, then stops. The program works well and the behavior of the box seems fine. Physical settings are: box is 5-unit wide and weights 1 unit, gravity is 9.81. The box is thrown horizontally with a speed of 7 and it drops from 18 units before touching the plane. Friction of the plane is 0.8, restitution is 0.1. Friction of the box is 0.6, restitution too.

I wanted to try units closer to human scale, so I have changed them to: box is 0.1-unit wide and weights 32 units, gravity is still 9.81, horizontal speed is 10 and it drops from 1.80, friction is 1.0, restitution is 0.1. Now everything goes wrong. After bouncing/rolling a bit, the box gets halfway inside the ground and starts spinning like crazy. After a while (up to 20 seconds), the box suddenly pops out of the ground and abruptly stops.

I have read Bullet's manual, Bullet's tutorial, and searched a bit in the forums, but I didn't find anything useful. The two suggestions I kept encountering did not help. First, my values do not seem out of the ranges suggested in the manual. Second, using m_splitImpulse=true seems useless, since OgreBullet does not create a btDynamicsWorld object but just btCollisionWorld. [EDIT: I misread the code, it is a btDiscreteDynamicsWorld object, so setting m_splitImpulse is possible. It doesn't help though: the boxes are still stuck halfway and they now spin endlessly, never popping out.)

So I'm stuck and I can't get Bullet to produce a sane behavior for this simple case. Any hint at what I'm doing wrong?

[silene]

I did some more experimenting, in particular with Bullet's own BasicDemo. At first, I wasn't able to reproduce the issue, and then I succeeded by just changing the timestep in stepSimulation from 60Hz to 45Hz. Note that the program itself runs at 60Hz, which is the frequency of my display. Similarly, changing the timestep from 60Hz to 80Hz does fix the issue with OgreBullet's tutorial: no more spinning boxes.

Anyway, while I now know how to fix the issue, I still don't understand the root cause. I fear I will encounter the issue again as soon as I use something more complicated than a single box. Could anyone shed some light on it? I don't understand why the behavior is so dependent on the timestep value, especially since Bullet seems to have a dedicated algorithm for box-plane collision.

[jazztickets]

box is 0.1-unit wide and weights 32 units

That seems way too heavy for something that size. What happens if you change the weight to something smaller?

[silene]

box is 0.1-unit wide and weights 32 units

That seems way too heavy for something that size. What happens if you change the weight to something smaller?

I just tried with 0.001 units and it doesn't make a bit of difference. The boxes still dive into the ground and spin, once they stop moving.

[jazztickets]

Try about 0.1 of linear damping and 0.3 angular damping.

[silene]

Try about 0.1 of linear damping and 0.3 angular damping.

Boxes stopped spinning. Instead they just vibrate, never coming to a stop. (By taking a closer look, boxes were already vibrating when there was no damping; it's just that the vibration was hidden by the rotation.) Thanks for your suggestions; I'm now convinced the bug is in Bullet.

[jazztickets]

I don't know if i'd call it a bug, since you're pushing the limits for stable simulation. Can you not just keep your boxes around 1 unit wide and then scale everything accordingly?

In general I try to keep everything 0.5 to 10 units for size, 0.5 to 15 for mass, 60 HZ to 100HZ for timestep, and use 0.1 to 0.3 damping.

[silene]

I don't know if i'd call it a bug, since you're pushing the limits for stable simulation. Can you not just keep your boxes around 1 unit wide and then scale everything accordingly?

In general I try to keep everything 0.5 to 10 units for size, 0.5 to 15 for mass, 60 HZ to 100HZ for timestep, and use 0.1 to 0.3 damping.

Sure, I could scale everything. But I was kind of hoping that the documentation would be correct, so that I don't have to. Chapter 14 of the manual explicitly states that moving objects should be sized between 0.1 and 5. And since my objects are 0.2, they should have been in range. (I notice that I wasn't accurate in my description: 0.1 is the half-extent of my boxes, so their actual width is 0.2.)

By the way, scaling doesn't help at all. Changing both the dimension of the boxes and the gravity leads to a system that behaves exactly the same. I guess it is really a matter of adjusting the timestep to match the ratio between the box size and the gravity. (There is an obvious dimension mismatch, so one might have to put a square root somewhere.)

[mi076]

I did some more experimenting, in particular with Bullet's own BasicDemo. At first, I wasn't able to reproduce the issue, and then I succeeded by just changing the timestep in stepSimulation from 60Hz to 45Hz.

I'm now convinced the bug is in Bullet.

don't understand, then why you consider it is a bug in Bullet?

[silene]

I did some more experimenting, in particular with Bullet's own BasicDemo. At first, I wasn't able to reproduce the issue, and then I succeeded by just changing the timestep in stepSimulation from 60Hz to 45Hz.

I'm now convinced the bug is in Bullet.

don't understand, then why you consider it is a bug in Bullet?

Because I can reproduce the issue at 60Hz with boxes that are 0.1-unit wide at default gravity, which is supposed to work according to the manual. (If you prefer, you can also reproduce the issue with boxes that are 1-unit wide, as long as you increase the gravity by trivial world scaling.) Note that this is with the damping values and mass suggested by jazztickets (not that it makes any difference though).

At the very least, it is an issue with the documentation. But the fact that boxes do not slow down although they are partly into the ground makes me believe it is more than just the documentation being overly optimistic. My expectation would be that, once four box vertices have found their way into the ground (don't ask me how), Bullet would consider that there is contact between the box and the ground, apply friction, and bring the box to a stop.

[jazztickets]

By the way, scaling doesn't help at all. Changing both the dimension of the boxes and the gravity leads to a system that behaves exactly the same. I guess it is really a matter of adjusting the timestep to match the ratio between the box size and the gravity. (There is an obvious dimension mismatch, so one might have to put a square root somewhere.)

Wait, why are you scaling gravity? Just change the size of your box to 1 (and possibly your plane) and move your camera back. Problem solved.

[silene]

Wait, why are you scaling gravity? Just change the size of your box to 1 (and possibly your plane) and move your camera back. Problem solved.

Think about it: gravity is a constant expressed as length over squared time. If you don't scale it, the physics will look like low gravity. For instance, if you drop a 0.1-unit-wide box from a height of 1.8 units in a gravity of 9.87, it will take 0.6 seconds to reach the ground. If you drop a 1-unit-wide box from a height of 18 units in a gravity of 9.87, it will take 1.9 seconds to reach the ground; scaling failed. But if you drop a 1-unit-wide box from a height of 18 units in a gravity of 98.7, it will take 0.6 seconds to reach the ground. When you scale the world, you have to scale the gravity too.

[jazztickets]

Oh, right. For some reason I thought you were keeping the height the same distance. Well I think the moral of the story is don't use small objects with sub 100HZ timesteps.