Dynamic TriangleMesh with SDF falls into kinematic TriangleMesh

[AgentCodeBanks]

Hello,

For a project I need to simulate non-convex 3D objects. I use TriangleMeshes with SDF (Signed Distance Field) to represent the object as accurately as possible. But now I have the problem that the SDF TriangleMesh object does not interact correctly with the TriangleMeshes without SDF. The SDF TriangleMeshes either fall into the other meshes or completely fall through.

See image:

In Cooking, I have the following settings:

Spacing: 0.0001
SubGridSize: 32
NarrowBandThicknessRelativeToSDFBoundsDiagonal: 0.001
NumThreadForSdfConstruction: 16

Unfortunately, I have only a rough idea how the SDF works. I am therefore not sure whether the values are plausible.

Does anyone have experience how to set the parameters so that the meshes do not fall into each other?

[preist-nvidia]

Hi @AgentCodeBanks - are you cooking the tri-mesh with GPU support? Since SDF collision is GPU only the other colliders need GPU support.

https://nvidia-omniverse.github.io/PhysX/physx/5.1.3/docs/GPURigidBodies.html?highlight=triangle%20meshes#what-is-gpu-accelerated

[AgentCodeBanks]

Yes, GPU is supported.
I have another project where I also collide SDF triangle meshes with triangle meshes without SDF and there it works. But with the same parameters it does not work in this case.

I went through these points but it still falls through the mesh.

https://nvidia-omniverse.github.io/PhysX/physx/5.1.3/docs/RigidBodyCollision.html#:~:text=If-,SDF%20collisions,-don%E2%80%99t%20produce%20satisfactory

[nvtw]

Hello, it is difficult to say why it does not work. Maybe it is worth to check a couple of things

• The triangle meshes that don't have an SDF must be either kinematic rigid bodies or static colliders. Dynamic triangle meshes must have an SDF.
• Make sure that your spacing leads to a reasonable SDF resolution. Usually a resolution of 200 to 400 is good. You can compute the spacing by dividing the length of the diagonal of your bounding box (bounding box of the object that gets an SDF collider) by the resolution you would like to have.
• subgridSize of 6 leads to much better compression than 32
• Your value of the NarrowBandThicknessRelativeToSDFBoundsDiagonal is a bit low, try 0.01
• For very detailed information about how SDFs work under the hood, you can check the following reference https://mmacklin.com/sdfcontact.pdf
  If it still does not work while all above points are implemented, then please share more information. Maybe a compact code snippet that shows how you set up your scene. In case we really do have a bug such a snippet would be very helpful for us to fix it.

[AgentCodeBanks]

Hallo nvtw,

the triangle mesh is a kinematic rigid body.
I adjusted the parameters as you suggested and logged out the SFDDesc parameter values.
I let the SDF object collide with other Triangle Meshe objects and even there the SDF object overshoots.

SDF Dimension X: 0 Y 0 Z: 0
SDF Lower Bound <0. 0. 0>
SDF Bound Min <8,507059E+37. 8,507059E+37. 8,507059E+37>
SDF Bound Max <-8,507059E+37. -8,507059E+37. -8,507059E+37>
SDF spacing: 0,0002388122
SDF subgridSize: 6
SDF subgridsMinSdfValue: 0
SDF subgridsMaxSdfValue: 0
SDF narrowBandThicknessRelativeToSdfBoundsDiagonal: 0,01
SDF numThreadsForSdfConstruction: 16
Mesh Dimension X: 66 Y: 342 Z: 216
Mesh SDFValue 0,03877983

I recorded the current behavior of the SDF Mesh in the Visual Debugger.

2023-06-20.12-24-18.mp4

Here is my code how i initialize the PhysXEngine and how i cook the meshes

PhysXInit_Snippet.txt

CreateMeshSnippet.txt

[nvtw]

The txt snippets you shared look fine. Since your mesh is a bit complex, a higher resolution might be a worth a try. Also the rest offset of the objects with colliders could be set to 0. I don't know if the objects that jitters gets stuck in the gap because it might be thicker than the gap. Increasing the number of position iterations could also be tried. To help better with debugging, would it be possible to share the meshes? Ideally a working snippet for the PhysX SDK that I could try out (there is already an SDF sample snippet shipped with the SDK). Alternatively you could also download omniverse (https://www.nvidia.com/en-us/omniverse/download/) which uses PhysX and model your scene there. The scene could be saved as a flattened usd file that can be shared here for debugging.

[AgentCodeBanks]

I have another question regarding the calculation of the surface area for the SDF. Is the normal vector of the triangle used for the definition of the positive area ? It can happen that when importing the CAD some surfaces are twisted (outer surfaces point inwards). Then the normalvector of the triangle would point into the negative area of the mesh. Could this influence the signed distance field?

[nvtw]

Ideally the SDF is generated using a mesh with normals that point outwards. The SDF generation code tries to fix problems that it detects on input meshes, so it should also work with inverted faces. The PhysX SDK contains a debug visualization function called visualizeSDF in NpDebugViz.cpp that can be used to verify if the SDF looks as expected.

[AgentCodeBanks]

I have recreated my case using the Omniverse Create.
But if I now cook the static rotation plate also with SDF then the behavior is much better.

SDFMeshCollision.zip

[nvtw]

Unfortunately the usd references a file called file:/C:/Users/scm/Documents/SDFMesh_144525/sdfmesh/v_neu_20230614_pr90221_000_000_advance_eurostars_654_ffg_42803920__892356.usd which is not in the zip. Could you save the file using "Save Flattened as"? Then all external file references should be converted to references inside a single file.

[AgentCodeBanks]

I have saved the project as flattered.
Since I created the rotation plate as SDF, I can no longer create the original state as it is in my project?
SDFMeshCollision.zip

[nvtw]

I tried the scene. It's indeed a tricky case. The only way I managed to get it working satisfactory is by doing the following

• Make the static triangle mesh a static SDF mesh with a quite high resolution (600)
• Increase the simulation frequency to 240 (in omniverse this setting is on the PhysicsScene, in the SDK, choose 1.0f/240 as timestep for scene->simulate(dt))
• Adjust the sleep threshold of dynamic objects such that the object does not jitter when coming to rest. A too big sleep threshold will put the object to sleep too early when it is still slowly moving.

Here is the file with my changes.
SDFMeshCollisionTuned.zip
We are still working on making the SDF collisions as good as possible. But as you noticed there are corner cases where very precise collision response is required. Sometimes the SDFs don't capture collisions well if the contact surface is quite small and objects get stacked onto each other. Usually it helps to make the timestep smaller but this comes at a cost of some performance.

[AgentCodeBanks]

I have adjusted the values in my program and the behaviour is much better. Curiously, the object is pressed to the right in my case.

Would an increase of the model size improve the situation?

[nvtw]

Increasing the size might help. Sometimes it also helps to tune mass and damping values. Specifically for SDFs, you could also try to subdivide your triangle meshes to get more triangles. They will then still have the same shape but more contact points will get generated. Subdividing a mesh can be done e. g. in MeshLab.
About the small offset: We had an offset bug with SDFs. It should be fixed in the next release of the PhysX SDK which should come out soon. The offset error should get smaller if you increase the SDF resolution. But that's only a work around since it comes at the cost of more memory consumption.

[AgentCodeBanks]

All right, I will try that, for the first result is quite okay. Thanks a lot for your help