Overlap when a ball collider rolls off of another.

[dimforge]

Overlap when a ball collider rolls off of another.

[sebcrozet]

Hi! Sorry for the late response.

I believe there may be a mismatch with the way sprites are rendered. Where is the local origin of sprites? If it is not at the center of the sprite, then it won't match what Rapier assumes (the center of the ball in its local-space is its local origin).

[jakerr]

I'm not at a computer where I can check right now, but I find it a bit hard to imagine this being a problem of the origins not being aligned. I'm saying this just looking at that motion where the top ball kind of hangs at about the half y position overlapping the lower one after falling a bit, and even pops back up briefly.

Another hint that this may be a bug was when I ran the same simulation with more sprites many of them seem to behave correctly while only a few exhibit this strange behavior. I reduced it to just the two before making this bug report to try to get the minimal reproduction.

[sebcrozet]

You are right. I thought that perhaps the sprite center was on the top-left corner, which would cause this kind of weird behavior because a small rotation would make them appear as if there are penetrating. But if I run your code locally, I can see that when the ball rolls on the ground, it rotates properly wrt. the sprite center.

So, yes, this is a bug. However if I try your code with my local version of Rapier (the one I'm actively working on for #79), the bug appears to be gone. So chances are that this won't be a problem in the next release of Rapier.

By the way, I think you got your PIXEL_PER_METER thing reversed. If you intend to consider that 1 meter is, say, 60 pixels, then this means that when you have 1 unit in the physics world, you get 60 units in the graphics world. So you should not scale all the physics quantities by PIXEL_PER_METER, it is the graphics that needs to be scaled wrt. the physics. Otherwise you end up with huge objects in the physics engine (because everything is expressed in pixels) which is more prone to numerical errors.
To make this a bit easier to work with, you can set RapierConfiguration::scale to PIXEL_PER_METER. That way, the Rapier plugin will automatically multiply the rigid-body positions by PIXEL_PER_METER whenever it writes their position back to the Bevy Transform.