bullet-featherstone: Support convex decomposition for meshes

[iche033]

🎉 New feature

Replaces #603

Depends on

• Add mesh optimization attribute to <mesh> sdformat#1382
• Update max_convex_hulls description  sdformat#1386
• Adds new function in MeshManager for performing convex decomposition gz-common#585
• Add new function in MeshManager to merge all submeshes of a mesh into one gz-common#588

Summary

Supports convex decomposition on meshes. Bullet-featherstone implementation will parse the new mesh simplification optimization attribute introduced in gazebosim/sdformat#1380, decompses the mesh into convex meshes, and builds btConvexHullShape collision shapes.

Compared to btGImpactMeshes (which is currently used for all meshes), the convex hulls seems to be more stable, do not have gaps between meshes (collision margins can be set to 1mm instead of 1cm), and some manual testing shows potentially faster performance (dependent on the number of submeshes generated)

Added test to verify that convex decomposition flag is parsed and valid collisions are generated.

Other changes:

• the m_erp2 value is now only set when there are meshes in the scene. The param was reduced to improve stability in bullet-featherstone: Improve mesh collision stability #600. I think we do not need to do it globally when there are no meshes in the world as the instability seems to only come from meshes. The value is also bumped up a little too prevent to much penetration - This will likely need more tuning as we do more testing with bullet.

To Test

Run gz sim with bullet-featherstone plugin and a world that has a model (e.g. Cordless Drill Simplified) that uses mesh decomposition:

gz sim -v 4 your_test_world.sdf --physics-engine gz-physics-bullet-featherstone-plugin

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[codecov]

Codecov Report

Attention: Patch coverage is 98.52941% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 78.91%. Comparing base (492b124) to head (1f2aaa7).
Report is 15 commits behind head on main.

❗ Current head 1f2aaa7 differs from pull request most recent head fec9fad. Consider uploading reports for the commit fec9fad to get more accurate results

Files	Patch %	Lines
bullet-featherstone/src/SDFFeatures.cc	98.48%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #606      +/-   ##
==========================================
+ Coverage   78.32%   78.91%   +0.59%     
==========================================
  Files         140      140              
  Lines        8069     8173     +104     
==========================================
+ Hits         6320     6450     +130     
+ Misses       1749     1723      -26     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[scpeters]

I was tinkering with this by changing the //mesh/@optimization value in the test to both an empty string and convex_hull to for comparison's sake, and I realized from the console output that we are computing convex decompositions of all the submeshes and then adding them all to a btCompoundShape. For comparison, when using bullet collisions in dartsim (which stores mesh information with submeshes in an Assimp Scene), all the submeshes are merged together into a single mesh:

• https://github.com/dartsim/dart/blob/f33fd04448141554eab8f4de378e1d40c1d0d212/dart/collision/bullet/BulletCollisionDetector.cpp#L879-L911

I think convex_decomposition and convex_hull operations should apply to the fusion of all submeshes, unless only a single submesh is specified, in which case it would act only on that submesh. In the unoptimized case, we could also consider merging to a single mesh shape instead of using btCompoundShape (this can happen in separate pull requests)

[scpeters]

we may want to remove this, but it has been very helpful for testing

[iche033]

shortened the debug msg to one line. 1f2aaa7

I can also remove this msg completely if preferred.

[scpeters]

this currently uses btCompoundShape to join submeshes

[iche033]

Updated to merge all submeses before decomposition, which addresses the comment about fusing all submeshes first before doing optimization.

Note that the decomposed submeshes are then still joined together using btCompoundShape. Same for the unoptimized case. I can change this to using a single mesh in a follow-up PR.

[iche033]

I think convex_decomposition and convex_hull operations should apply to the fusion of all submeshes, unless only a single submesh is specified, in which case it would act only on that submesh. In the unoptimized case, we could also consider merging to a single mesh shape instead of using btCompoundShape (this can happen in separate pull requests)

hmm ok to make this happen, we'll need to:

• update sdf description - currently it explicitly states decomposition is for each submesh
• add a new function to merge multiple common::SubMeshes into one (before calling gz::common::ConvexDecomposition with that one combined submesh)

I'll work on these changes

[iche033]

hmm ok to make this happen, we'll need to:

• update sdf description - currently it explicitly states decomposition is for each submesh
• add a new function to merge multiple common::SubMeshes into one (before calling gz::common::ConvexDecomposition with that one combined submesh)

I'll work on these changes

gazebosim/sdformat#1386
gazebosim/gz-common#588

[azeey]

The code LGTM! but I did see a weird behavior while testing.

[azeey]

In general, I thought testing with a V or U shaped object would really show the difference in behavior between convex_hull and convex_decomposition, but
I'm getting some unexpected penetration with convex_decomposition. I've attached the .sdf files.

Maybe we can use this in the test?

test_conv_decomp.zip

[iche033]

I added an integration test for this. In the test I set <max_convex_hulls> to 64 which prevents this penetration. 2099054

The generated convex hulls looked fine with either 16 or 64 max_convex_hulls so something else is not right. This is something to look into next.

[iche033]

I'm getting some unexpected penetration with convex_decomposition. I've attached the .sdf files.

I found that by setting a small m_globalCfm value, it's able to prevent this penetration, e.g.

diff --git a/bullet-featherstone/src/Base.cc b/bullet-featherstone/src/Base.cc
index ac66f574..80a04ced 100644
--- a/bullet-featherstone/src/Base.cc
+++ b/bullet-featherstone/src/Base.cc
@@ -49,6 +49,7 @@ WorldInfo::WorldInfo(std::string name_)
   // the penentration impulse depends on the erp2 parameter so set to a small
   // value (default in bullet is 0.2).
   this->world->getSolverInfo().m_erp2 = btScalar(0.02);
+  this->world->getSolverInfo().m_globalCfm = btScalar(0.001);

by default m_globalCfm is 0