A special case of sphere / trimesh collision...

[gfm]

I want to be able to simulate a small sphere, about 0.2 units in size. It works fine as long as the ball velocity stays really small, but once I drop it onto a trimesh terrain from a good height it falls right through it. One frame its completely above the trimesh, the next frame its completely below it.

Obviously the bullet docs advise against small objects like this, but there must be a way!

I can bump the time step up to 500Hz and get substantially better results, but I can still find cases where it falls through. Plus 500Hz consumes a bit more CPU than I would like. There must be a better way!

In my case I can make an assumption: there's not supposed to be anything below my trimesh... So what if in SphereTriangleDetector::collide() I detected when the sphere is below the trimesh, project it back up a ways so its in contact with the trimesh again, then let it do the collision? Would I be crazy to do that, or is there a better way?

[Erwin Coumans]

Adding a single-sided triangle mesh could indeed improve this issue. If you have a good contribution for that we could accept it.

Have you tried latest Bullet 2.72 alpha?
http://code.google.com/p/bullet/downloads/list

It allows you to enable CCD Motion Clamping for fast/small objects. Can you try it out, and set those settings, just for your tiny sphere?

Code: Select all

//enable CCD if the object moves more than 'coreRadius' meter in one simulation frame:
body->setCcdMotionThreshold(coreRadius);
body->setCcdSweptSphereRadius(coreRadius);
Choose coreRadius a bit smaller than the actual btSphereShapeRadius.

Please let us know your results,
Thanks,
Erwin

[gfm]

Hey Erwin, thanks! That works pretty well.

However, for whatever reason, it causes the sphere to impact triangle edges a lot more frequently, causing strange/incorrect bounces when the sphere impacts a triangle edge (a "seem") in the middle of the trimesh. Does bullet assume only one contact was made between a sphere and a trimesh at a time? It seems like when you hit an edge within a trimesh it should average the normals of the contact points when calculating the force to use for resolution. (?)

Regardless, I solved the problem by having SphereTriangleDetector::pointInTriangle() take into account the radius of the sphere, so contacts on edges are treated as contacts within the triangle. So essentially the contact normal is always perpendicular to the plane of the triangle... This seems to work pretty well (for my case anyways), but it would be nice if the contact normal was the average of the two normals of the edges involved in the collision. Is there a quick'n'dirty way to make that happen?

Those two changes, sparkprime's applyDamping() change, combined with a secondary angular damping scheme, makes for a pretty realistic looking ball / trimesh behavior. Thanks for your help!

[pico]

Hi,

this is an old problem:

http://code.google.com/p/bullet/issues/detail?id=27
Issue 27: Provide solution to filter out unwanted collisions with internal edges of a triangle mesh.

This caused a lot of problems in our games as well. We 'fixed' it by replacing all triangle meshes with convex hulls. Ugly but it worked for our geometry.

I think a quick and dirty solution would be to set an treshhold for the normals difference of both triangles. If the difference between the two normals exceed the threshold then this edge must collide, if not then the edge must not collide. So you would get collisions at real edges and not fake collisions on subdivided planes.

[AlexSilverman]

Hi,

There was an old issue in Bullet, which kept changes made in the ContactAddedCallback from affecting the newly created contact point, but this has since been fixed. What this means, is that in your ContactAddedCallback, when the collision is between a triangle and anything, you can set the contact normal to that of the triangle. This should fix the behavior you're seeing.

- Alex

[RobW]

Hi,

I wrestled with this problem for a while (the internal edge problem), and I don't think it is as simple as setting the normal to that of the triangle surface. If you do that, the penetration depth is wrong, and if you naively calculated the penetration depth in the direction of the suface normal (i.e. using the radius of the sphere) you cannot roll off 'cliffs' correctly. However, if you don't have any such features, it works pretty nicely.

I guess it depends on how important nice rolling is in your application, but we went down the convex hull route too.

Personally, I think the solution is to create a penetration depth solver that correctly calculates the penetration depth along the triangle suface normal. I have actually implemented this, but haven't yet been able to iron out some edge cases where it falls down (especially when penetration is very shallow).

[AlexSilverman]

Rob,

You're quickly traveling out of my depth I'm not sure how the penetration depth problem you mention would manifest itself, but I never noticed any visible effects. Our rolling simulation isn't too complex though, as simulation speed is more important to us here than accuracy. The worst of it is a simple rolling friction approximation done by applying an impulse opposite the direction of the roll, taking into account friction values for the sphere and triangle, and that's good enough for us.

- Alex

[RobW]

Well the penetration depth * penetration normal should bring the contact points into touching contact. Since you modify the penetration normal, this will no longer be correct. It could manifest itself as a 'hop' as the sphere rolls over the triangle edge, or it could sink in a little. Much of the time the error might not be big enough to notice, but it depends on the size of your objects and their speed.

If you take, say, the Convex demo from Bullet, and flatten out the mesh and turn the boxes into spheres, you can try rolling them around and see if any artifacts are visible from crossing the edges. I couldn't see any. But the objects are large and when you make them smaller, the problem starts to emerge. I would guess that as your objects get smaller, the artifacts from modifying the normal only would get worse.

It isn't an issue of object size, constants, numerical accuracy or anything like that. Its just that gravity more deeply embeds a small object in one timestep than a larger one, and the resolution is more likely to be undesirable.

[pico]

Hi,

if you check out the google code link i posted above then you can download a demo from the mentioned forum topic
that shows the effect.