Bullet in 2D

[Peter]

Hi,

I'm currently evaluating Bullet for a 2D project, and I'm having a bit of trouble getting my rigid bodies to stick to two dimensions.

All rigid bodies in the world are using btCompoundShape objects with multiple btConvexHullShapes. Each convex hull shape is a 2D mesh extruded from -5 to 5 on the z-axis. In order to constrain the x and y rotation axes and the z-axis movement, I've tried the following:

• Setting the inertia along the x and y axes to 0, as suggested in the manual for character animation.
• Using a hinge constraint.
• Using a Generic6DOF constraint as described here.

All these methods work most of the time. But when bodies start colliding at rapid speeds (~200 units / sec) they often break their constraints and rotate slightly around x or y to resolve the collision, shifting up or down on the Z-axis, resulting in 2D overlap.

Is there a fool-proof method for clamping Bullet to two dimensions?

Thanks!

NB. I've looked closely at Box2D as well, but Bullet has support for raycasting and kinematic bodies that are proving very useful. As I'm not an experienced physics programmer I don't know which needs more work, adding those features to Box2D or constraining Bullet to 2D.

[Erwin Coumans]

NB. I've looked closely at Box2D as well, but Bullet has support for raycasting and kinematic bodies that are proving very useful. As I'm not an experienced physics programmer I don't know which needs more work, adding those features to Box2D or constraining Bullet to 2D.

Perhaps some combination of Box2D and Bullet would work, such collaboration benefits both projects. Otherwise, I would recommend going for Box2D and ask Erin for the timelines for raycast and kinematic objects.

Thanks,
Erwin

[chunky]

All these methods work most of the time. But when bodies start colliding at rapid speeds (~200 units / sec) they often break their constraints and rotate slightly around x or y to resolve the collision, shifting up or down on the Z-axis, resulting in 2D overlap.

Have you tried simply upping the internal tick rate of bullet?

The thread you linked about using a generic6dof constraint is the one containing code I wrote, and it's working well for me, but I think it's worth noting that my timestep is significantly higher than the default 1/60th of a second - it's actually 1/180th of a second.

That's pretty serious granularity, but my spaceships can move really pretty fast, and my framerate is currently [if I uncap it] about 850 fps on my mac. Plenty high enough to warrant a 2/3 decrease in tick length. If you do this, though, you need to up the number of ticks you allow per call to world->stepSimulation. Overall it leads to much higher consumption of CPU power, but fewer catastrophic failures at higher framerates [where "catastrophic failure" means "managing to go so fast you get through level boundaries without colliding with them"].

The numbers I actually pass around are based on stuff I covered in this thread

Gary (-;