Concave Mesh (concavemesh.obj) collision problem

[goksanisil23]

Hi,

Firstly thank you for creating such a clean physics engine and providing sample scenes as well.

I was experimenting with using the concavemesh.obj as a static mesh as a terrain. However, I realized that at certain regions of the mesh, other dynamic objects just pass through, and in some other regions, dynamic objects get half-stuck (partially penetrate into the ground).

You can find the phenomenon I'm talking about in the video below:

https://drive.google.com/file/d/1yAhydfGnBEB-pBhHdkzF8Zb9EZttM3YF/view?usp=sharing

I haven't seen this behavior with the city.obj concave mesh though.

Thanks in advance

[DanielChappuis]

Thanks a lot for your feedback.

I suspect that most of the issues might be because the velocities of the objects are quite large and ReactPhysics3D currently uses a discrete collision detection (not a continuous collision detection) and therefore what you observe might be a 'tunneling effect'. Try to reduce the simulation time step or make sure that the objects collide with the concave mesh with a lower velocity (by dropping them from a lower position for instance) and check if it is better.

[goksanisil23]

Hi,

Thank you for the insight.

I've tried with 0.005sec step instead of the default 0.0167 sec, as well as increasing the velocity and position solver iterations to 10x of their default values. Also, lowered the starting elevation of the falling objects.

I believe I'm still getting similar behavior, you can check out the video in the link:

https://drive.google.com/file/d/1GJVnr9OBNUXetJFIF5XuDmm-79PO2MVB/view?usp=sharing

[goksanisil23]

Similarly, I have applied the above suggestions (increasing solver resolution, decreasing impact velocity) on a different heightfield where I've also seen the tunneling effect. In that case, sufficiently increasing solver or decreasing velocity both helped with the mitigation of tunneling effect.

I believe this means that, it's a bit of tuning problem which is dependent on the static mesh characteristics.

[goksanisil23]

I wanted to give one more input.

I've generated a rectangular environment with walls in Blender and using it as a static concave mesh collider.

In the 1st video below, I'm using it without any scaling.
In the 2nd video below, I'm using it with 5x scaling on both mScalingMatrix and createConcaveMeshShape.

https://drive.google.com/file/d/1iEPgjgTFMaxUaRcCmkl0gmAoDvs1V0xa/view?usp=sharing
https://drive.google.com/file/d/1O6I-M_va25x7RdkJYG3xOzuih1bX7EBk/view?usp=sharing

And here's the code snipped where I handle the scaling (in ConcaveMesh.cpp):

`mScalingMatrix = openglframework::Matrix4(5.0, 0, 0, 0,0, 5.0, 0, 0,0, 0, 5.0, 0,0, 0, 0, 1);

mPhysicsTriangleMesh = mPhysicsCommon.createTriangleMesh();

// For each subpart of the mesh
for (unsigned int i=0; i<getNbParts(); i++) {

    // Vertex and Indices array for the triangle mesh (data in shared and not copied)
    rp3d::TriangleVertexArray* vertexArray =
            new rp3d::TriangleVertexArray(getNbVertices(), &(mVertices[0]), sizeof(openglframework::Vector3),
                                          getNbFaces(i), &(mIndices[i][0]), 3 * sizeof(int),
                                          rp3d::TriangleVertexArray::VertexDataType::VERTEX_FLOAT_TYPE,
                                          rp3d::TriangleVertexArray::IndexDataType::INDEX_INTEGER_TYPE);

    // Add the triangle vertex array of the subpart to the triangle mesh
    mPhysicsTriangleMesh->addSubpart(vertexArray);
}

// Create the collision shape for the rigid body (convex mesh shape) and
// do not forget to delete it at the end
// mConcaveShape = mPhysicsCommon.createConcaveMeshShape(mPhysicsTriangleMesh);
mConcaveShape = mPhysicsCommon.createConcaveMeshShape(mPhysicsTriangleMesh, rp3d::Vector3(5.0f, 5.0f, 5.0f));`

Interestingly, when I scale the original mesh down (scaling factor < 1.0), I don't see this collision problem where dynamic objects just pass through.

[DanielChappuis]

That's interesting. Thanks a lot for this test case.
I will try to investigate this when I have some time.

[dukeNashor]

I am in the same situation when playing with the testbed.
Loaded an OpenGL teapot mesh as a ConcaveMesh object, applied gravity, and the teapot just went through the terrain.

[DanielChappuis]

I am in the same situation when playing with the testbed.
Loaded an OpenGL teapot mesh as a ConcaveMesh object, applied gravity, and the teapot just went through the terrain.

Hello. This doesn't seem to be the same issue. Your are trying to collide a concave mesh (ConcaveMeshShape) against another concave mesh (HeightFieldShape). This is not supported by ReactPhysics3D (it would also be very expensive). Therefore, in your case it is expected that the two concave shapes do not collide.

[dukeNashor]

I am in the same situation when playing with the testbed.
Loaded an OpenGL teapot mesh as a ConcaveMesh object, applied gravity, and the teapot just went through the terrain.

Hello. This doesn't seem to be the same issue. Your are trying to collide a concave mesh (ConcaveMeshShape) against another concave mesh (HeightFieldShape). This is not supported by ReactPhysics3D (it would also be very expensive). Therefore, in your case it is expected that the two concave shapes do not collide.

Thanks for your reply.

[denisbogol]

@DanielChappuis, hi!

I have faced with the same issue while applying scaling to concave meshes. The problem is that the AABB for such shapes is created from the root node of DynamicAABB tree that does not account for scaling. I tried to fix in the following way:

RP3D_FORCE_INLINE void ConcaveMeshShape::getLocalBounds(Vector3& min, Vector3& max) const {

// Get the AABB of the whole tree
AABB treeAABB = mDynamicAABBTree.getRootAABB();

min = treeAABB.getMin() * mScale;
max = treeAABB.getMax() * mScale;

}

Not sure it fixes all the cases, but at least broad phase can work now (doesn't not miss overlapped shapes).

[DanielChappuis]

That's interesting. Thanks a lot for your feedback. I will take a look at this change and see if this change makes sense. If so, I will include this in the next release of the library.

[denisbogol]

Hi, @DanielChappuis !

There is probably a similar issue with convex mesh shape. mScale is not accounted in getFaceNormal method (while it is used in getVertexPosition, getCentroid, etc). In case of NUS (non-uniform scale) normal vectors of scaled mesh are not the same as original ones, and we have to recompute them, e.g.:

// Return the normal vector of a given face of the polyhedron
RP3D_FORCE_INLINE Vector3 ConvexMeshShape::getFaceNormal(uint32 faceIndex) const {
assert(faceIndex < getNbFaces());
Vector3 normal = mPolyhedronMesh->getFaceNormal(faceIndex);

normal.x *= 1.f / mScale.x;
normal.y *= 1.f / mScale.y;
normal.z *= 1.f / mScale.z;

normal.normalize();

return normal;

}

[DanielChappuis]

This is now fixed in version v0.10.0 of the library.