Terrain collision - what am I missing?

[consequence]

Hey, everyone. I started integrating Bullet into my project a few days ago, and I've come across a problem with my terrain. In short, it produces excessive tunneling.

My terrain is essentially a height field, and so I've tried using btBvhTriangleMeshShape, btHeightfieldTerrainShape, etc. to represent it. The thing that all the terrain-friendly shapes have in common, and the source of my problem, is that they are infinitely thin and two-sided. Thus, there is a relatively small window in which collisions are resolved properly.

It doesn't seem to matter how large I make my collision shapes; even at low velocities (relative to the size), they will reliably tunnel. As for other solutions, I've tried:
- CCD: This doesn't seem to work as expected with any of the shapes I've used for terrain. Behavior is the same as without it.
- Increased collision margins: Maybe I just don't know how to use them (I'm just calling setMargin()), but they don't help at all, even at ridiculous sizes.
- Debug drawing: There's nothing wrong with my terrain shapes. Large spheres can roll around perfectly on them.
- Decreased internal timestep: This one actually helps somewhat, of course, but I would really prefer not to rely on something that increases computations so greatly.

To give some perspective, here's an example scenario. I have flat terrain, and 100m above it, a .25m cube. The cube accelerates downward at 9.8m/ss, and goes straight through the terrain. Is that normal? How do I make collision information for my terrain that can reliably collide with objects at greater velocities?

Please remember, I've tried a variety of shapes here, and I'm aware of the problem - objects are penetrating the terrain too deeply, and are thus coming out the other side. So, I guess my real question is this:

What can be done to ensure that no collision involving terrain will be resolved such that the other object is pushed even deeper into the terrain?

I've looked through more posts on these forums than I care to remember, and yet the solution eludes me. I would love to just have a btHeightfieldTerrainShape with thickness. I've seen really old posts stating that such a shape might be implemented, but if it's there, I don't see it.

[zweifel]

Please consequence, if you find a solution to this let me know. I am facing the same problem.

I notice this was also happening in the Heightfield demo. Somebody knows a workaround?

[consequence]

I started using a workaround just so I could move on to other things for now, but I'd like to get a better fix if possible. Right now, all I'm doing is checking Bullet's AABB for each collision object vs. the terrain it should be on/over. If the center of the bounding box is below the terrain, I translate the object upward, leaving it just slightly submerged so as to guarantee that the collision gets resolved the way I want it to during the next iteration.

The results are pretty good, but I couldn't really find a clean way to integrate this check into Bullet's own routines, so it's more overhead than it could be. Anyway, it's easy to implement, so you might consider doing something similar. I'll be sure to post here if I solve the problem more elegantly.

[zweifel]

Thanks for the workaround, consequence.

I found a thread where they seem to have accomplished a good heightmap collision.

http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=5729

Maybe it helps. If I get any good results I will post here as well.

[reptor]

The PhysX engine has 'thickness' and 'vertical extent' parameters for a height field.

I think obviously the Bullet engine should have them too.

[zweifel]

ODE also has thickness in their heightfield geometry, but based on my code and on answers from the forum, their heightmap collision seem not to work well. Btw, is not the same algorithm used by both ODE and Bullet for heightmap collision?

[reptor]

I guess the community need to get together and implement this.

If someone could explain how it is likely implemented in PhysX or others which have it, people could start working on it for Bullet.

Perhaps the idea is clear but the time to implement it has not been there. So if someone knows, please explain what should be done to correctly implement this feature into Bullet.

[Wil McV]

I'd like to resurrect this thread because i'm experiencing this issue. It happens with all shapes but it seems that boxes are the worst. Also i'm using a btBvhTriangleMeshShape for my terrain. Is it better to use the Terrain Height field?

[lunkhound]

There is another thread on this issue http://bulletphysics.org/Bullet/phpBB3/ ... =9&t=10224 where I describe how I solved this problem.

1. Turn on CCD.
2. Use a contact-added callback to flip the normals if they are colliding with the back sides of triangles.

[Wil McV]

Thanks for the reply, CCD isn't an option for me unfortunately. Its too expensive.

I don't think my issue is to do with the objects travelling too fast. It could be, but they aren't travelling very fast at all so I suspect its the issue where they are colliding with the back side of the polygons.

I'll have a read of the forum post anyway.

Cheers