Sphere-box corner collision (edge)

[harrysjoerd]

Hi,

I'm working on a breakout-like game and use bullet callback functions and a single ManifoldPoint per collision to handle it. I expected that the ball would only collide with the faces of my cube and i would only get collisions with normals (1, 0, 0) or (0, 0, 1) and those negated. However, if the ball hits the cube on a corner I get a different normal and my ball bounces unexpectedly.
I think this is caused, because the collision is not with the face, but with an edge of the cube. Is this true? How can I check whether a collision is with an edge; in which case I would ignore it, or transform the normal.

Hope someone can help. Much appreciated.

[Flix]

However, if the ball hits the cube on a corner I get a different normal and my ball bounces unexpectedly.
I think this is caused, because the collision is not with the face, but with an edge of the cube. Is this true? How can I check whether a collision is with an edge; in which case I would ignore it, or transform the normal.

AFAIK it can be caused by the collision margin of the cube shape.
You can watch the video RBD kindly posted some time ago here: http://www.bulletphysics.org/Bullet/php ... &hilit=RBD (I suggest you start watching it at minute 4.40 or so, even if all the content is very valuable and useful), and see if this is what it's happening in your scenario or not.

If this is the case, you can solve it by shrinking the box shape collision margin (dafault value should be 0.04, you can try boxShape->setMargin(0.01), or even zero if you like). Another approach can be using bigger shapes for both the box and the sphere, since the collision margin is constant and does not grow with the shape size.

[harrysjoerd]

Thanks for your reply. Your answer made sense, however it seems like my collisions are independent of the margin. I changed it to 0 and even to 1, but no change in behaviour. If I query the margin of the box at a collision, it indeed returns 0, or 1 and 0,04 if I leavet unaltered. It seems like the margin doesn't influence my simulation.

Back to the original question. Is there a conceptual difference between colliding with a face or with an edge (or even a vertex)? Could that cause my problem? Can I detect it?

Thanks.

[Flix]

Thanks for your reply. Your answer made sense, however it seems like my collisions are independent of the margin. I changed it to 0 and even to 1, but no change in behaviour. If I query the margin of the box at a collision, it indeed returns 0, or 1 and 0,04 if I leavet unaltered. It seems like the margin doesn't influence my simulation.

Well, according to the Bullet manual, collisions between box and spheres are handled by a special box-sphere algorithm: maybe that algorithm doesn't use the collision margin at all. You may try replacing the box with a btConvexHullShape and see if the collision margin starts playing some role. Alternatively, you can try replacing the sphere with a btMultiSphereShape (made by a single sphere) and see if this works. In both cases, I suggest you use the local inertia calculated by the 'proper' collision shape (i.e. box or sphere). Alternatively you can see if there's some way to override the default Bullet collision algorithms, so that collisions between box and spheres are handled by another algorithm (gjk?): I can't help you here, because I never needed to do this myself.

Back to the original question. Is there a conceptual difference between colliding with a face or with an edge (or even a vertex)? Could that cause my problem? Can I detect it?

I don't know the Bullet internals enough, to answer this question (I think this might depend on the collision algorithm Bullet uses, the boxsphere algorithm in your case: maybe you can see its code...). I don't think you can detect it, but, somebody more familiar than me with the Bullet internals should answer this

P.S. If your issue is not caused by the collision algorithm feel free to ignore this post completely...

[rtrius]

The btSphereBoxCollisionAlgorithm projects the sphere center onto the box, and
then defines the normal as pointing towards the sphere center from that projected
point. As a result, the normal would not coincide with the box's face normals if the
sphere is colliding with a vertex or edge. Using GJK would produce a similar result.

It would probably be best to use the btSphereBoxCollisionAlgorithm as a starting point
and modify it to your needs; there is no built in feature to check whether the collision
is at a face, vertex, or edge.

[harrysjoerd]

Handling the collision with custom code such that the normals are always perpendicular to the collided face solved it. Thanks.