Bug - Capsule sliding along series of boxes

[JasonTPG]

So I have a reproducible issue that is causing us problems. We set up a series of boxes so that they are adjacent to each other with their tops all at the same height, essentially creating a larger plane from a series of boxes. Then we drop a capsule on this plane and push it around with some basic forces. Frequently it will 'hit' the edges of these boxes where they meet and cause the capsule to bounce up into the air. The plane does not have to be be made of boxes, a Triangle Mesh has exhibited the same behavior when passing over the edges of the triangles. This occurs more frequently as the speed of the capsule increases and the capsule bounces proportionally higher based on the speed.

We had a similar scenario a couple years back using Bullet 2.67 and did not have this issue, we noticed this after upgrading to 2.74 (though it may have been introduced prior to 2.74 as we went from 2.67->2.74 directly). I created a simple test case using nothing but Bullet and a basic DirectX btIDebugDraw implementation to isolate that the behavior does not exist in 2.67 but does in both 2.74 & 2.76.

My test scene is 20 static (0 mass) boxes of half-extents (1, 1, 1). I placed them 2 units apart along the X axis to create a row of boxes. I then drop a capsule of (.5, 2) with mass of 1 from 3 units above and begin applying forces in the +/- X direction to based on user input. To make sure we weren't hitting small gaps between the boxes I have also tried half-extents of (1.25, 1, 1) while maintaining the same 2 unit separation so that they have some very obvious overlap, but the capsule still seems to bounce when encountering the edges.

Thanks for the help,
Jason

[SteveSegreto]

Hi,

I'm not a big expert, but I thought the btKinematicCharacterController was created to avoid these kinds of issues. What would happen if you created a capsule as a ghost object of a btKinematicCharacterController instead?

[JasonTPG]

Hmmm, I'll have to look into that, I'm not the one who wrote our original usage, I'm just the one trying to find out why it's not working like it used to and I'm still fairly new to Bullet I did just find that this behavior does exist in 2.67, just a lot less frequently. I was able to 'run' back and forth several times without ever noticing it in 2.67 but in 2.74/2.76 it's happening constantly. So if anyone has any idea why it would be happening more frequently I would still be curious to know.

-Jason

[Erwin Coumans]

It is most likely because of the introduction of the 'contact processing threshold'. This means that the constraint solver processes contacts with positive distance, to increase stability.

You can disable this feature by using

Code: Select all

characterBody->setContactProcessingThreshold(0.f);

Another solution is to use a triangle mesh instead of boxes, in combination with the btInternalEdgeUtility. See Bullet/Demos/InternalEdgeDemo how to use this. This has been specially designed to deal with internal edges.
We could also adapt the btInternalEdgeUtility to deal with arbitrary collision edges but such extension hasn't been implemented yet.

Thanks,
Erwin

[JasonTPG]

Thanks Erwin, turning the Contact Processing Threshold down does appear to make the simulation behave like it did before (we still see the hitch but not nearly as often). We do have some Triangle Meshes that have exhibited this behavior that can probably benefit from the btInternalEdgeUtility so I'm going to look at that. Unfortunately our box-case is a data-driven scenario where the designers are placing preconfigured props, platforms, etc around the scene and when they string together a number of platforms is when we most often see this. We might be able to do some post-processing at runtime to convert the series of boxes into a single triangle mesh, have to do some more digging on that.

Thanks for your help,
Jason