Terrain mesh collision

[Anton Petrov]

Good day everybody!
I use btBvhTriangleMeshShape to represent collision shape of a terrain in my game. The vehicles are btRaycastVehicles with a collision shape of class btCompoundShape, in fact, this is a box slightly translated (just like in the vehicle demo).

The problem is vehicle falls through the terrain or gets stuck in it. Is it the inaccuracy of the bullet library or just a problem of parameters settings? What could you advise to me?

Thank you.

[Erwin Coumans]

The problem is vehicle falls through the terrain or gets stuck in it. Is it the inaccuracy of the bullet library or just a problem of parameters settings? What could you advise to me?

Thank you.

This is not normal behaviour, so there must be something unusual going on. Please check if spheres (1 unit/meter) under normal gravity from a short distance collide fine with the landscape. It sounds like the mesh collision shape is not setup properly. Can you pass a btTriangleMesh into the btBvhTriangleMeshShape , rather then using the more complicated striding mesh interface (just for debugging)?

Implement the btIDebugDrawer interface, so that you can see if the collision shapes show up properly.

Does the vehicle demo suffer from the same problems? Please try to compare and reproduce your setup in the demo.
Thanks,
Erwin

[Anton Petrov]

It sounds like the mesh collision shape is not setup properly. Can you pass a btTriangleMesh into the btBvhTriangleMeshShape , rather then using the more complicated striding mesh interface (just for debugging)?

I have tried btTriangleMesh, the vehicle falls through.

Ok, some words about conditions. In my game cars are small(approx. 0.4 units/meters lengthwise). Landscape is natural enough. Landscape mesh dimensions are 150x150x8 units/meters. As you can see there is no possibility to fall from abnormal heights. Gravity is -9.82.

The typical situation when a car falls through the terrain is when I drop it from a cliff which height is about 2-3 units.

Does the vehicle demo suffer from the same problems? Please try to compare and reproduce your setup in the demo.
Thanks,
Erwin

I guess the vehicle demo does not suffer because it uses very smooth wavy terrain mesh and there is no cliffs to fall from.

Erwin, how do you think, If I try collection of spheres for vehicle collision shape will it be more stable?

P.S. I think the bug is caused by inaccuracy in Box-TriangleMesh collision detection routine.

Thank you

[Proctoid]

The only time i have had things falling through a landscape is when the graphical mesh does not match the physics mesh... ie. i have set the wrong vertices or winding order in part of the mesh i have given to bullet.

As erwin suggested you should 'Implement the btIDebugDrawer interface, so that you can see if the collision shapes show up properly' This is a must - it is basically a callback from stepSimulation that you use to render all the meshes and aabb etc that bullet is using - this instantly shows mismatches between graphics and physics.

Also you should have implemented some sort of pick function so you can click your 3d scene and display the returned hit information or pick up objects and generally drag/drop/throw them around the scene.

If all that fails to find the problem then you simply run a debug version of your game and use breakpoints to determine where things are going wrong.

[Anton Petrov]

The only time i have had things falling through a landscape is when the graphical mesh does not match the physics mesh... ie. i have set the wrong vertices or winding order in part of the mesh i have given to bullet.

This is not a case. I am not speaking about "my wheels are sunken in the terrain". The whole vehicle falls through terrain (receiveing torque momentum while colliding with the terrain mesh) and continues falling to infinity while terrain goes up into the sky. This is not a visual artefact.

[AlexSilverman]

Anton,

I agree with Proctoid and Erwin that the btDebugDrawer interface is an absolute necessity for everyday testing. Short of that, or perhaps not, replacing the terrain mesh in the Vehicle Demo is a great step, as it gives you a visual representation of your collision mesh (which as we all know is not always exactly what we think it should be) and it also lets you test in something of a universally known quantity (the Bullet demo suite), in which anyone else can reproduce what you're seeing and work in exactly the same test case that you're working in.

- Alex

[Anton Petrov]

Anton,

I agree with Proctoid and Erwin that the btDebugDrawer interface is an absolute necessity for everyday testing. Short of that, or perhaps not, replacing the terrain mesh in the Vehicle Demo is a great step, as it gives you a visual representation of your collision mesh (which as we all know is not always exactly what we think it should be) and it also lets you test in something of a universally known quantity (the Bullet demo suite), in which anyone else can reproduce what you're seeing and work in exactly the same test case that you're working in.
- Alex

Ok, I will try to relace terrain in the VehicleDemo.

But, I have a new question. When box and triangle mesh of the terrain interpenetrate, where are contact point impulses facing? May be these are contact point forces which push a vehicle under the ground when significant interpenetration occurs?

[Erwin Coumans]

Yes, please implement debugging drawing through the btIDebugDrawer interface to make sure the triangle mesh is fine. That is why I asked to drop spheres on the triangle mesh, to verify all is setup fine and the collision detection works fine.

But, I have a new question. When box and triangle mesh of the terrain interpenetrate, where are contact point impulses facing? May be these are contact point forces which push a vehicle under the ground when significant interpenetration occurs?

It is likely a tunneling problem, small objects moving too fast with a too large timestep. Bullet uses a single algorithm for all convex interations, so there is no special box versus triangle.

You mentioned the chassis is 0.4 units? Which collision shape is it exactly? Does the problem also occur if you disable the vehicle constraint, and just drop the chassis on the mesh? Can you please try to reduce the timestep and see if that helps?
What arguments are you currently passing to 'stepSimulation'?

Code: Select all

btDynamicsWorld::stepSimulation(realDeltaTime,maxSubsteps,internalTimeStep);

Try passing maxSubsteps = 100 and internalTimeStep = 1./240.0 and see if that improves the situation.

Thanks,
Erwin

[Murphy]

I am a similar question to this in this thread: http://continuousphysics.com/Bullet/php ... =5225#5225

I have added a picture to that thread that might help visualize the problem.

[Anton Petrov]

It is likely a tunneling problem, small objects moving too fast with a too large timestep. Bullet uses a single algorithm for all convex interations, so there is no special box versus triangle.

You mentioned the chassis is 0.4 units? Which collision shape is it exactly? Does the problem also occur if you disable the vehicle constraint, and just drop the chassis on the mesh? Can you please try to reduce the timestep and see if that helps?
What arguments are you currently passing to 'stepSimulation'?

I was passing maxSubSteps=2 (this was just copied from the vehicle demo).

Yes, looks like setting maxSubSteps=100 really helps. By the moment I am writing this, I did not managed to drop the vehicle under the ground.

Thank you.

[projectileman]

Take a look to

http://continuousphysics.com/Bullet/php ... php?t=1439

The same problem, and a similar solution

[Erwin Coumans]

Take a look to

http://continuousphysics.com/Bullet/php ... php?t=1439

The same problem, and a similar solution

Not really: people can use btBvhTriangleMeshShape with quantization. It looks like a tunneling problem here, a small collision shape at high velocity with a big timestep.

So the usual questions are:

1- What is the vehicle collision shape exactly?
2- Have you tried btTriangleMesh instead of btStridingMeshInterface?
3- Did you already add debug rendering through btIDebugDrawer?
4- Are you using any scaling at all?
5- Does a smaller timestep help?

Code: Select all

dynaWorld->stepSimulation(deltaTime,100,1./240.0);

6- Can you provide a reproducable case in a Bullet demo?

Thanks,
Erwin