Bullet Units

[Spuddy]

I am new to Bullet and have read that there are restrictions on the range of units where dimensions should be in the range 0.2 to 5 for accurate simulation. Although I have a degree in Mechanical Engineering, those days are long gone, and I'm a bit rusty on my maths. The objects I'm intending to use in my game are about 5cm in diameter. I assume Bullet's default units are meters and kg so 5cm = 0.05m and that would put things well outside the safe limits. Even if I use centimeters for my units, then that would put my objects at the upper 5 unit limit and I'm still unsure what value I would need to supply for gravity and whether internal constants would need changing to match. Is there a simple API function call to set the units that are used for dimensions and mass ? Maybe a multiplier can be set for the dimensions that alters all other internal constants ? Thanks !

[sparkprime]

People sometimes say that the default units are meters and kg, but it doesn't really matter, they can be inches and pounds as long as you supply all of your data in the right units. Metres and kg makes most sense though.

The range of values is important though. This is on the issues list http://code.google.com/p/bullet/issues/detail?id=45.

The "too small" problem is due to constants in the dynamics world and solver. Noone has said precisely what/where these constants are, but the collision margin (default 0.04) is one of them. Possibly noone even knows/remembers exactly what constants there are My favourite solution would be just to export these constants with get/setters and put a list of them somewhere in the documentation. I would like this because a) it should in theory allow massive ranges to be used as long as the constants are suitably chosen b) it allows fine tuning and perhaps more realistic behaviour even for simulations within the "standard" ranges, and c) by playing with the values, people can probably learn more about the simulation itself, which could be useful for debugging and general community understanding.

I'm not sure what the "too big" problem is all about. I've used lots of things that are bigger than 5 and they have worked fine. If you scale up the gravity and typical object velocities as well, then you may need to increase the collision margin so that more accurate correct collision impulses are computed.

There are limits on the size of the "world" though, i.e. the bounding box that encloses all the bounding boxes of the objects in the world. This is due to the implementation of some of the broadphase algorithms (the algorithm that runs first to compute a list of (object,object) pairs that may be colliding, so that slower algorithms can then work only those pairs). You can choose what broadphase algorithm you like best. I can't remember the difference between any of them and it's not documented but you can search the forums. Check the API documentation to get a definitive list as they all extend btBroadphaseInterface.

[Spuddy]

The problem I'm having is that if I multiply my object dimensions by say 50 to get them into the 0.2 to 5 range and multiply gravity by 50 too so they drop realistically instead of floating down like feathers, then they jitter after landing. The object lands and then jiggles around and rotates about its vertical axis and never comes to a standstill. Is there any way to deal with this ? Thanks !

[sparkprime]

What collision shapes, sizes, gravity, and so on are you using?

Do the demos work correctly?

Try increasing the linear/angular sleeping threshold inside btRigidBody. I believe the unit is velocity.

From the dynamics world, get the solver info structure, and increase the number of iterations.

You could also try turning on the split impulse feature, although i'm not sure this will have any effect with static/dynamic collisions.

Some kinds of simulations (stacking in particular, or where the ratio of object velocity to size is high) really need a smaller internal step size. Try 100hz or 200hz instead of the default 60hz.