Jitter of small box on plane

[GoogleCodeExporter]

What steps will reproduce the problem?
Interaction of smallish boxes on planes causes jitter/drifting, but box-on-box 
of the same size works fine.

What is the expected output? What do you see instead?
Don't bounce around, it bounces around.

What version of the product are you using? On what operating system?
svn2421, OS X 10.7.1

Please provide any additional information below.
Attaching minimalist modification of BasicDemo to demonstrate.

Original issue reported on code.google.com by ejtt...@gmail.com on 13 Sep 2011 at 9:05

Attachments:

• cube-plane-jitter.diff

[GoogleCodeExporter]

Issue 540 has been merged into this issue.

Original comment by erwin.coumans on 13 Sep 2011 at 11:41

[GoogleCodeExporter]

box-box is more stable because it uses a special collision detector that 
computes multiple contact points at once, unlike most other collision detectors 
in Bullet.
Also you can test with a convex hull made of the box corner points, for 
comparison.

You can see the result by disabling the special box-box detector:

    //make sure to disable the special box-box collision detector, replace it by the generic convex version
    m_dispatcher->registerCollisionCreateFunc(BOX_SHAPE_PROXYTYPE,BOX_SHAPE_PROXYTYPE,  m_collisionConfiguration->getCollisionAlgorithmCreateFunc(CONVEX_HULL_SHAPE_PROXYTYPE,CONVEX_HULL_SHAPE_PROXYTYPE));

You can use a smaller internal timestep to improve the stability:

m_dynamicsWorld->stepSimulation(ms / 1000000.f, 10, 1./240.);

Alternatively you can use a hacked inertia tensor for more stability of small 
objects:
localInertia *= 2.f;

Attaches is a modified BasicDemo that shows the various cases.

Thanks,
Erwin

Original comment by erwin.coumans on 14 Sep 2011 at 1:17

Attachments:

• BasicDemo.cpp

[GoogleCodeExporter]

So in a nutshell: this is not a bug but expected behavior, given such a small 
object using the default internal timestep of 60 hertz.

By the way, you also need to make sure to use a small collision margin: it is 
0.04 by default which is too large for an object of 0.05 units. The collision 
margin should be an order of magnitude smaller in general.

So the fix is to use a smaller timestep, if you are using very small objects:

m_dynamicsWorld->stepSimulation(ms / 1000000.f, 10, 1./240.);

Original comment by erwin.coumans on 14 Sep 2011 at 1:19

• Changed state: Invalid

[GoogleCodeExporter]

Thanks for pointing out the collision margin issue, I'll look into that.

Would it be possible to replicate the "special" collision detection contact 
point generation for planes?  That would be a more satisfying solution, and I 
naïvely expect it should be similar to handling a face of the box.  I could 
take a stab at it, but it would help if you would give a bit of direction, e.g. 
where is the relevant portions of the plane and box contact generation.

My interest is because using a box as the ground plane requires choosing some 
dimensions, beyond which things fall over the edge... it's one less thing to 
worry about if it's infinite (although I realize eventually there are still 
floating point resolution issues, but still...)

Original comment by ejtt...@gmail.com on 14 Sep 2011 at 2:33

[GoogleCodeExporter]

Let's discuss improving collision detection in this Bullet forum topic first:

http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7402

Original comment by erwin.coumans on 14 Sep 2011 at 5:15

[GoogleCodeExporter]

Issue 530 has been merged into this issue.

Original comment by erwin.coumans on 15 Sep 2011 at 1:22