Marching cubes terrain with physics

Troubleshooting physics
1

I have a terrrain that consists of 3D voxels. Those voxels are separated into 32³ chunks with their meshes constructed with the Marching Cubes algorithm.

I constructed each chunk’s physics with a RigidBody of 0 mass and thus their collisions shapes are of MeshCollisionShape.

I have many questions and problems related to all that :

Untitled

  1. When the red “punching bag” (that’s what we call it) falls with enough speed, it will clip through the surface and then fall inside the chunk itself. We found out that this does not happen if it falls onto a triangle. However, if it falls onto an edge or a corner of a triangle, then it will fall inside the chunk. My solution to that was to increase the accuracy (actually the accuracy is inverted and thus it is decreased…) by setting it to 1 / 240. This is really expensive so I was wondering if there was a better solution?

  2. The player is actually the same as the punching bag model & physics and is moved with a BetterCharacterControl. Initializing the player and the chunks with the default friction makes the terrain unplayable, as movements will extremely often stops at an edge / corner of a triangle or will be like if something would slow non linearly the player’s movement. My solution to that was to set the player’s friction to 0, however this arises a new problem.

2.1) With a friction of 0, the player’s BetterCharacterControl slides in non-abrupt slopes… How can I fix both 2 and 2.1 problem?

  1. In the Advanced Physics page, it is that MeshCollisionShapes do not work with dynamic spatials. What does that mean? Are RigidBodies with a mass greater than 0 dynamic spatials?

  2. In the javadoc page of the PhysicsGhostObject class, it is said :

From Bullet manual:
GhostObject can keep track of all objects that are overlapping. By default, this overlap is based on the AABB. This is useful for creating a character controller, collision sensors/triggers, explosions etc.

So, to truly handle collisions with ghost objects that have CompoundCollisionShapes of HullCollisionShapes, what’s the best option? To filter the collision events to pick only those that are really colliding or to handle the collisions myself, eventually with an octree?

2

The RigidBodyControl has setters for ccdSweptSphereRadius and ccdMotionThreshold. There’s a rough description of the CCD feature here: http://www.bulletphysics.org/mediawiki-1.5.8/index.php?title=Anti_tunneling_by_Motion_Clamping

Try setting the falling object’s threshold to a very small positive value (like 1e-10) and the radius to about 10% of the object’s diameter.

1 Like
3

The capsule for the characters have a radius of 0.2f.

unitMovementControl.getRigidBody().setCcdSweptSphereRadius(0.02f);
unitMovementControl.getRigidBody().setCcdMotionThreshold(0.000000001f);

It really made no difference at all. By the way, the class UnitMovementControl extends BetterCharacterControl.

I have set a linear velocity on the rigid body just to be sure that I was getting the correct rigid body and I confirm that it is indeed correct.

Do I need to do something else?

4

Nothing else comes to mind.

5

Ok thank you very much, I’ll have to develop the game with high accuracy in mind.

6

Regarding question 3. above; I could be mistaken, but I believe mass is used inversely so a zero mass simply makes the object have infinite rest mass (meaning anything else less than infinite mass won’t move it, but still collides). This is not really related to dynamic vs. Static mesh hints. Even a static mesh can be translated and rotated (I guess kinematically with 0 mass?).
A dynamic mesh is just a hint that the vertex buffers may change, as opposed to getting the optimizations from marking a mesh as static (vertex buffers will not change). Since your chunks will change, and are therefore dynamic, you may want to/have to avoid MeshCollisionShapes. Also, when the mesh is changed, don’t forget to update the collision mesh and model bounds accordingly.

1 Like