Skip to content

WIP: [Feature] Add GJK-EPA algorithm for rigid body collision detection #1213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

SonSang
Copy link

@SonSang SonSang commented May 29, 2025

Description

Adding GJK-EPA algorithm for rigid body collision detection.

Related Issue

Resolves Genesis-Embodied-AI/Genesis#

Motivation and Context

GJK-EPA could be an alternative to MPR in terms of stability or efficiency.

How Has This Been / Can This Be Tested?

Running unit tests in test_rigid_physics_gjk.py.

Screenshots (if appropriate):

Checklist:

  • I read the CONTRIBUTING document.
  • I followed the Submitting Code Changes section of CONTRIBUTING document.
  • I tagged the title correctly (including BUG FIX/FEATURE/MISC/BREAKING)
  • I updated the documentation accordingly or no change is needed.
  • I tested my changes and added instructions on how to test it for reviewers.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@@ -139,7 +139,7 @@ def _load_primitive(self, morph, surface):

elif isinstance(morph, gs.options.morphs.Cylinder):
tmesh = mu.create_cylinder(radius=morph.radius, height=morph.height)
geom_data = None
geom_data = np.array([morph.radius, morph.height])
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this PR is already big, I would recommend moving changes unrelated to GJK-EPA into another PR.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I'll do that.

@@ -25,6 +25,7 @@ def main():
viewer_options=viewer_options,
rigid_options=gs.options.RigidOptions(
dt=0.01,
use_gjk_collision=False,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this just a temporary patch?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it will be removed once the implementation is done.

@@ -38,6 +39,8 @@ def __init__(self, rigid_solver: "RigidSolver"):
self._init_verts_connectivity()
self._init_collision_fields()
self._mpr = MPR(rigid_solver)
self._gjk_epa = GJKEPA(rigid_solver)
self.use_gjk = self._solver._options.use_gjk_collision
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest following the same pattern than RigidSolver:

  • Add the attribute self._use_gjk = self._options.use_gjk_collision in RigidSolver.__init__
  • do not add any argument to self._func_narrow_phase but rather access the attribute (statically) within the method if ti.static(self._use_gjk):.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree. Now I used self._use_gjk as an argument to avoid recompilation every time I switch from MPR to GJK or vice versa. Will change it to static variable when the implementation is complete.

Copy link
Collaborator

@duburcqa duburcqa May 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I get it. But this does not prevent you to stick to the usual pattern (except for the ti.static part of course!). I would work the same as passing it has input argument I guess, am I wrong? Maybe it is still pre-compiled to some extend in this case?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you're correct. In fact the main reasoning behind this was for the unit tests. In the unit tests, I'm changing the use_gjk flag after compilation like this. So this choice is quite temporary for the unit test -- will change the unit test code to set the flag during compilation time and follow the usual pattern!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see! This is fine 👍

@@ -188,6 +188,8 @@ class RigidOptions(Options):
Acceleration threshold for hibernation. Defaults to 1e-2.
max_dynamic_constraints : int, optional
Maximum number of dynamic constraints (like suction cup). Defaults to 8.
use_gjk_collision: bool, optional
Whether to use GJK for collision detection. Defaults to False.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to add more information about the rationale behind this choice. Why someone would opt for GJK instead of MPR++ and if it is so great, why it is not the default? Why both options are still available?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I was thinking that it would be better to give both options to the users, so that they could opt from them for their use. How about discuss it when we finalized the implementation and get the test results?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, but for that you need to give a few pointer to the end-user to guide their choice :) But yes we can discuss this once you finalise the implementation!

@@ -0,0 +1,2139 @@
import math
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest not versioning stuffs you do not plan to include in the final PR. You can keep some commits locally on your machine. Just push what you want me to look at :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, sorry for pushing temporary commits together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants