When I detect the collision between two dynamic BulletTriangleMeshShape, I found they are considered to be collided even if they are visually separated. The attached figure shows an example. The two red points are the contact.getManifoldPoint().getPositionWorldOnA() and B() positions. Is it possible to make this more precise? My BulletTriangleMeshShape.getMargin is now 0.
This one is still unsolved. I looked up the bullet code and found bullet was using GIMPACT, I then changed to GIMPACT. I found GIMPACT also have some contact positions related to its algorithm details. But they are not the panda bullet offset. The following one is my contacts detected using GIMPACT.
The intersections of the two bunnys’ bounding boxes look satisfying.
The following shows another boxshape-boxshape triangle intersection. Some deviations appeared at the contacts, but I guess they are caused by the algorithmic implementations.
Dear All,
Here is my final report about the failure in collision detection.
- It seems GIMPACT has an internal problem for concave trimeshes. Panada3d Bullet is using GIMPACT, it is unclear if the problem is inherited or not.
- The Panda3d bullet has a weird offset. Its metric is in millimeter. It works more or less correct if you use mm, but the results look bad in meter. The weird offset may also be caused by point 1. I did not do in-depth investigation right now.
- I switched to Ode. It worked find for concave trimeshes. A few examples are below.
With GIMPACT, the result is as follows.
Using the Bullet contactTestPair, the result is as follows (only getPositionWorldOnB() is shown)
The following figure shows another result of Bullet contactTestPair. There should be no collision, but the algorithm found a contact point on the outer surface.
It would be great if you have any insightful comments.
Best,
Let me do a further update.
I scaled the model by multiplying 10000 to each vertex.
The result of bullet physics collision is as follows.
First, the collider reported no collision in the following case. It is correct.
Then, it reported a collision position as follows in a collided case. The getPositionWorldB function is probably trying to return the most shallow collision point (Hope someone could confirm it). It looks, uhmmm, at least not bad…
But when I use meters directly.
The result is wrong:
The getPositionWorldB function returned the red point shown in the picture.
My final conclusion is the bullet physics engine in panda3d is using millimeter scale with a 2-3mm margin. But I did not find a document for it. I would appreciate it if you show some clues.
The margin is not settable, and leads to problems when the metric is in meters.
This conclusion also partially answers my question posted in the community several weeks ago:
Btw, forget my words about the GIMPACT library. I guess I was using a buggy version.
Thanks!
Can I check something with you, please? You mention scaling, and using either millimetres or metres. Are you by any chance applying an actual scaling transform to your collision-objects? That is, do you have a call to the effect of “myNodePath.setScale(value)” somewhere?
Sorry I did not mention this clearly.
I was doing everything using np.array, and then packed them into a pandanodepath for collision checking, dynamics computation, and rendering.
Ah, fair enough. It seemed worth checking, as scaling transformations can interfere with collision and physics systems, as I recall.
Which operating system are you on?
I wonder if it has to do with the math options that Panda or Bullet is compiled with. We compile Panda with -ffast-math on Linux, for example, which may have incorrect handling for denormal floats, which would explain why the result might be different at different scales.
However, the fact that you are seeing slower behaviour at different scales do suggest that denormal handling is enabled, since processing denormal floats is significantly slower.
It is also possible that Bullet and Panda are compiled with different precision settings.
Thank you both for taking time to read my flooded posts.
I am using the prebuilt one from PYPI, and my platform is windows.
I will ask other people in our lab to try ubuntu or mac.
I gave up this thread three month ago and switched to ODE, but I am now trying to move back to Bullet for not only collision detection but also dynamic simulation. Thus, I did more investigation – This problem appears on all platforms. Is it possible that it is an internal collision detection tricks by Bullet? At least the library was not designed for collision detection.
The following figures show the detected collision points as the two objects get separated.
Here is another example when a cylinder gets larger and overlaps with a bunny:
No Collision, looks good
Overlapped, one contact point, looks good too
More overlapped, two contacts, weird
Expand more,
Further (gets back to a single contact point, looks correct)
Hmm… Another thought: Could it be that the reported contact-points are in the local space of one or both of the objects involved, and that you’re placing your visualisation in world-space, or vice versa? That could potentially produce some apparently-incorrect results.
Interesting, but the contact points are reported even when two objects are separated. I am wondering if this is related to the slow bullet detection reported at
It does not like a not normal problem.
Ah, fair point, indeed.
Hmm… That does prompt a thought: I seem to recall that Bullet has some sort of “tolerance” value for intersections. If your objects are so small that they’re of size similar to–or worse, noticeably less than–this “tolerance” value, then their collisions may always be “within tolerance”, and so apparently colliding.
Otherwise, have you asked after this in the Bullet community? Perhaps this is a known issue that they can advise on.
Thanks, I guess I will look for answers from Bullet community. As for the margin, I have set it to bulletshape.setMargin(1e-6).
Fair enough, on both counts!
I might suggest mentioning the value to which you set that margin when you do talk to them, as it seems possible that it’s relevant.
1 Like