Bounce with multiple collisions

Question

Here's the problem: I'm writing an Arkanoid-like game in Unity 5.3. I'm using 3D physics and simply ignoring z-axis in computations. No gravity, 0 drag and velocity reset every bounce by script. My ball has sphere collider and rigidbody with continuous dynamic collision detection on it, and bricks have box colliders with continuous detection. They are set like tiles, one by one, without gaps.

The problem occurs when a ball collides with two bricks at once, which causes a wrong bounce angle. Smaller sphere colliders makes this situation occur less often, but causes the ball to ignore collisions sometimes and phase through a single brick.

I know the probable reason for this bug, I think a collision with two objects affects ball physics twice. The question is: how to avoid it?

Answer 1

When you have a bunch of adjacent box-colliders and expect that they behave like a continuous wall, then unfortunately they won't. As of version 5.3.4, this is an edge-case the Unity physics engine does not handle correctly.

When a rigidbody collides with the edge between two box-colliders, Unity will register it as a collision with the edge of one collider and give you a bounce-angle which you would not expect.

How could you work around this problem?

Either you ditch the Rigidbody on the ball, turn all the colliders into trigger-colliders, and implement the ball-physics yourself. If you want to make an authentic Arcanoid clone, all the more complex nuances of the physics engine would be switched off anyway and all that's left to do is moving the ball by a constant velocity vector and changing that velocity vector on collisions.

If you want to use the Unity physics engine (maybe adding some more detailed physics might give an interesting new spin on the old Arcanoid concept), then you will have to work around that quirk in the physics engine by building your own colliders. When you have two or more adjacent blocks, you will need to merge them into one object with one collider. That would likely be a MeshCollider (when you use 3d physics) or a PolygonCollider2D (when you use 2d physics). You will have to generate the Mesh / Path yourself using a script. Also, you will have to write an own script to check which blocks are affected when the ball collides with the collider.

Answer 2

If you want to avoid writing your own physics, or you want to stick with Unity's physics, you can use some averaging with your collision data.

You collect each collision's data in OnCollisionEnter and average their position and direction to a final one.This will give you a very sloppy&unstable approximation of what you should expect.

I think there is another way to get over this. You said your bricks have box colliders, I assume you don't have jagged edges on your bricks. If these assumptions are correct then we will start by considering all the bricks are lines and compute the reflected direction of the ball by using the transform.right property of your bricks.

The transform.right property of your bricks will determine the virtual domain of the box collider. For example, if your ball falling 90 degrees downwards and your brick's transform.right is Vector3(1,0,0), then your ball will go upwards the exact way it came. If the transform.right property is Vector3(1,1,0) then your ball will go 45 degrees to the left.

And again it's a sloppy approximation and probably you will end up using your boxcollider bounds and maybe transform.up as well in order to achieve perfect collisions.