Want to verify my assumptions about ContactAddedCallback

[emeyex]

I've altered the ConcaveDemo to create a new btCompoundShape* per entity to act as the parent of all the "real" shapes (i.e., the mesh of the ground, the box of the rigid bodies). To my delight and surprise, they actually pointed to the "real" shapes (triangle, box, etc). My question is: is this reliable? Will I always receive the actual colliding shape in the ContactAddedCallback when I use btCompoundShape in my entities? I poked around in the src and found a place where it temporarily sets the shape pointer on the btCollisionObject to the leaf shape, but wanted to be sure there weren't other places I might be missing.

On a related note, can anyone see any reason why it would be bad to add "User Data" (i.e., int m_userData0, void* m_userData1) to the base btCollisionShape class? I've tried it and everything seems to work fine, but again, I want to make sure I'm not going down a treacherous path.

One last assumption to verify... Will ContactAddedCallback get called at least once every frame that a rigid body is colliding with something (I know about the multiple calls and all that...) I want to make sure I don't need to handle the "Removed" case myself. I.e., if two objects are colliding in a given frame, ContactAddedCallback will get called; otherwise, it won't.

Thanks for any replies!
-Max

[Erwin Coumans]

It is best to avoid disclosing proprietary physics engine information here (I adjusted your posting)

Will I always receive the actual colliding shape in the ContactAddedCallback when I use btCompoundShape in my entities? I poked around in the src and found a place where it temporarily sets the shape pointer on the btCollisionObject to the leaf shape, but wanted to be sure there weren't other places I might be missing.

Yes, the callback will always be pointing to a (temporarily) child shape. Make sure not to keep a pointer to this temporary shape, it might not exist after the callback.

On a related note, can anyone see any reason why it would be bad to add "User Data" (i.e., int m_userData0, void* m_userData1) to the base btCollisionShape class? I've tried it and everything seems to work fine, but again, I want to make sure I'm not going down a treacherous path.

This week we added such user info to all collision shapes, so it will be in Bullet 2.67.

One last assumption to verify... Will ContactAddedCallback get called at least once every frame that a rigid body is colliding with something (I know about the multiple calls and all that...) I want to make sure I don't need to handle the "Removed" case myself. I.e., if two objects are colliding in a given frame, ContactAddedCallback will get called; otherwise, it won't.

• The ContactAddedCallback is only called for new/replaced contact points. Contacts are cached over frames, and there is no ContactAddedCallback again for existing points, unless they happen to be replaced by another one.
• ContactRemovedCallback exists, and is called when a contact point is removed. However, currently this callback is internally used. So if you want to use it, you need to call the original callback. We will probably remove this internal use of the removed callback.
• The ContactProcessedCallback doesn't exist. Do you have a suggestion how we should implement such 'processed' callback (without referring to proprietary engines).
• We could also add a ContactRefreshedCallback. This would be called for contacts that carry over from one frame to the other. This is probably very similar to ContactProcessedCallback, but it might not contain the contacts added this frame, unless we reorder the calls to manifold->refreshContacts().

It is not possible to provide child-shapes for such ContactRefreshedCallback or ContactProcessedCallback.

Thanks for the feedback,
Erwin

[emeyex]

Apologies about any proprietary references, I assumed I was being sufficiently general, but I'll avoid it in the future.

Glad to hear about the user data being added to collision shapes.

As far as a ContactProcessed or Refreshed callbacks... if I didn't have access to the child-shape, then it wouldn't be so helpful to me, but off-hand it doesn't seem like I'd need them, especially if there were a ContactRemoved where I did have access to the child-shape. I guess the question is, given a body moving along the ground let's say, will it continually receive ContactAdded callbacks as long as it's moving and not deactivated? If yes, then that's all I really need.

Thanks for the swift reply,
Max

[emeyex]

Regarding the CollisionShape user data, I should mention that I did a quick modification in the source to copy the UserData pointer from the Mesh shape to the temporary Triangle shape before it's passed into the ContactAdded callback; that way, in my callback, the triangle carries the same user data on it that my mesh parent had; does this seem too hacky to make it into a bullet release? Or else if there were some other way to do a similar thing (i.e., get the Mesh shape from the triangle or something). Just a thought...

[Erwin Coumans]

to copy the UserData pointer from the Mesh shape to the temporary Triangle shape before it's passed into the ContactAdded callback;

Good idea, it has been added in the Bullet repository, so it will be available in 2.67. Also there is a new ContactProcessedCallback.

Please check out the beta version we upload this week, we probably need some discussion on how to use this. There is no 'childshape' available in the ContactProcessedCallback or ContactRemovedCallback. However, you can add your user-info to each contact point during the ContactAddedCallback (so you could add info for the triangle indices, or compound child shape pointer etc).

Thanks a lot for the feedback,
Erwin

[emeyex]

However, you can add your user-info to each contact point during the ContactAddedCallback (so you could add info for the triangle indices, or compound child shape pointer etc).

This sounds like a perfectly reasonable solution, and should provide adequate access to whatever I'd need in the Processed and Removed callbacks.

Good idea, it has been added in the Bullet repository, so it will be available in 2.67. Also there is a new ContactProcessedCallback.
Please check out the beta version we upload this week, we probably need some discussion on how to use this.

Excellent! I will indeed be on the lookout for the beta and will try to provide feedback.
Thanks so much!

[emeyex]

So I decided to investigate the ray-casting and see if the results would be consistent. I found that in the AddSingleResult virtual method RayResultCallback I received the btCompoundShape* instead of the leaf shape. However, it was pretty trivial to do a similar temporary swap of the btCollisionObject's "real" (in this case btCompoundShape) shape pointer for the current leaf shape pointer. Everything seemed to work fine, the AddSingleResult method now had the actual sub-shape, and all the raycasts still seemed to work fine. The only funny business is that I had to const-cast to set the child shape while its iterating over the child shapes (in btCollisionWorld.cpp, approx line 380-ish). I.e., before the call to rayCastSingle, I added:

collisionObject->setCollisionShape( ( btCollisionShape* )childCollisionShape );

and after the for loop iterating over all child shapes, I reset the original shape:
collisionObject->setCollisionShape( ( btCollisionShape* )compoundShape );

Thoughts?

[emeyex]

Just thought I'd give this last post about the ray-casting issue a little bump. I don't mind making these modifications to my own version of the code, but it seems like it could be beneficial in the main branch. The other thought was that you could add a member to the LocalShapeInfo for the sub-shape pointer and pass it in that way, if there were concern over changing the existing behavior. Anyway, it just seemed like this sort of a change would go with the other btCollisionShape stuff.