You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 3, 2025. It is now read-only.
ODE has a nice feature to automatically disable bodies when they are not moving. This is great for performance. However there is one issue with this.
ODEPhysics skips disabled bodies in ODEPhysics::CollisionCallback which is called from ODEPhysics::UpdateCollision.
This affects computation of the contact points in the function ODEPhysics::Collide() which is then called later for all bodies not skipped in CollisionCallback. So in effect, no contact points are computed for links which are not moving and which are in contact with other non-moving links. This is certainly done for performance reasons.
The issue with this is: ODEPhysics::Collide() adds the contact information to the physics::ContactManager. But Collide() is only called for enabled bodies. Now if there is a subscriber to the contact points topic, they would not receive the contact points between the not moving links. But depending on the application, subscribers may also need the contact points between still objects. Example: the gzclient visualization doesn't show objects which are still. This can be tested by:
Starting gazebo in paused mode
Putting a sphere on the ground
Switching on Contacts visualization
Hit Play
Waiting until the object is still: The contact point will disappear.
Effectively this enforces the treatment of colliding objects if there are subscribers to the contact points (or if has been enforced for another reason).
However my only concern with this is that ODEPhysics::Collide() does not only fill in the contact point feedback, but also creates contact joints. I am not sure how they are used, and if this could badly impact performance while there are any contact point subscribers.
Any feedback on this would be appreciated so I can try to fix this up.
The text was updated successfully, but these errors were encountered:
Original report (archived issue) by Jennifer Buehler (Bitbucket: JenniferBuehler).
ODE has a nice feature to automatically disable bodies when they are not moving. This is great for performance. However there is one issue with this.
ODEPhysics skips disabled bodies in ODEPhysics::CollisionCallback which is called from ODEPhysics::UpdateCollision.
This affects computation of the contact points in the function ODEPhysics::Collide() which is then called later for all bodies not skipped in CollisionCallback. So in effect, no contact points are computed for links which are not moving and which are in contact with other non-moving links. This is certainly done for performance reasons.
The issue with this is: ODEPhysics::Collide() adds the contact information to the physics::ContactManager. But Collide() is only called for enabled bodies. Now if there is a subscriber to the contact points topic, they would not receive the contact points between the not moving links. But depending on the application, subscribers may also need the contact points between still objects. Example: the gzclient visualization doesn't show objects which are still. This can be tested by:
This doesn't happen with Bullet.
I found this can be solved by some changes to ContactPointManager in my branch contact_manager_enforcable_additions (see also pull request #2629) and changing following lines in ODEPhysics::CollisionCallback:
Effectively this enforces the treatment of colliding objects if there are subscribers to the contact points (or if has been enforced for another reason).
However my only concern with this is that ODEPhysics::Collide() does not only fill in the contact point feedback, but also creates contact joints. I am not sure how they are used, and if this could badly impact performance while there are any contact point subscribers.
Any feedback on this would be appreciated so I can try to fix this up.
The text was updated successfully, but these errors were encountered: