Bullet discrete contact testing #425
Conversation
facebook-github-bot
added
the
CLA Signed
Codecov Report
@@ Coverage Diff @@
## master #425 +/- ##
==========================================
- Coverage 57.68% 56.27% -1.42%
==========================================
Files 176 156 -20
Lines 8225 6804 -1421
Branches 84 84
==========================================
- Hits 4745 3829 -916
+ Misses 3480 2975 -505
Continue to review full report at Codecov.
|
| @@ -346,6 +346,13 @@ Magnum::Quaternion Simulator::getRotation(const int objectID, | |||
| return Magnum::Quaternion(); | |||
| } | |||
|
|
|||
| bool Simulator::contactTest(const int objectID, const int sceneID) { | |||
There was a problem hiding this comment.
Should we expose the physics manager instead of forwarding? It would simplify Simulator and avoid having to add forwarding code every time a new API is added.
There was a problem hiding this comment.
We've talked about this in the past. At that time the motivation was:
- make C++ the primary API (implement functions in Simulator class in C++)
- make physics functions callable from sim.function() instead of needing sim.physicsManager.function() for ease of use.
There was a problem hiding this comment.
For 2. you could grab a physicsManager reference and just call physicsManager.function(). But sounds reasonable to have everything go through Simulator.
Non-blocking: it would be nice to not have all the forwarding logic in Simulator.cpp. Maybe via multiple inheritance or an include.
| @@ -285,6 +285,9 @@ def apply_force(self, force, relative_position, object_id, scene_id=0): | |||
| def apply_torque(self, torque, object_id, scene_id=0): | |||
| self._sim.apply_torque(torque, object_id, scene_id) | |||
|
|
|||
| def contact_test(self, object_id, scene_id=0): | |||
There was a problem hiding this comment.
If it is an internal test, I am wondering why we need to expose it on the python side?
I took a look at the other bindings above it, e.g., apply_torque, get_rotation, add_object. They are reasonable and very necessary to be exposed here. But this one is different. I would like to hear from you first.
There was a problem hiding this comment.
Good question. This function name may be misleading. It is not a unit test, but a discrete collision check. I'm happy to rename it if that is a problem.
There are actually a couple of applications for this functionality on the python side.
Examples include:
- 3D step filter function (check if agent collides with env after moving)
- Scene generation and 3D Agent placement (rejection sampling for contact free placement)
| @@ -346,6 +346,13 @@ Magnum::Quaternion Simulator::getRotation(const int objectID, | |||
| return Magnum::Quaternion(); | |||
| } | |||
|
|
|||
| bool Simulator::contactTest(const int objectID, const int sceneID) { | |||
There was a problem hiding this comment.
For 2. you could grab a physicsManager reference and just call physicsManager.function(). But sounds reasonable to have everything go through Simulator.
Non-blocking: it would be nice to not have all the forwarding logic in Simulator.cpp. Maybe via multiple inheritance or an include.
* Introduced basic contact results callback struct * Add discrete contact testing for rigid bodies and a C++ test * Add contact testing functionality to Simulator.cpp and python bindings for simulator.py
Motivation and Context
Discrete contact testing is useful for a variety of tasks including agent/object placement and collision filter functions. This PR introduces the first step: binary contact testing for a specific object with the collision world.
Includes Simulator.cpp wrapper and python bindings for simulator.py.
This infra can later be extended to include a configurable contact distance threshold and collection of contact points, normals, friction directions, contact distances, and colliding object pair identifiers.
How Has This Been Tested
C++ CI test for object/object and object/scene contact results.
Types of changes
Checklist