Problem with collision detection of a fast moving ball with a racket controlled by mouse

SpeedBirdNine picture SpeedBirdNine · Sep 9, 2011 · Viewed 20.6k times · Source

In unity, i have a racket which is supposed to hit a ball, and the racket is controlled directly by the mouse, i.e the bat is being moved by the mouse using mouse axes and the using transform.translate() function to move the racket.

I expected that Unity3d's physics will not properly translate the racket's movement directly by mouse and impact the ball accordingly, and i would have to write something custom, and it turned out to be true.

But the ball's collision is not being detected properly when the racket is moving. When it is still, everything is fine, and the ball behaves as i like.

Now i went as far as writing a custom physics script (i use C# for scripting) in which i attached 4 raycasts of length 0.6F to the ball, and after doing some complex vector calculations, calculate the velocity of the ball after hitting the racket, and apply it directly to the velocity of the ball using rigidbody.velocity = calculateVelocity(). Now it is again working fine when the racket is not moving, but not when i move the racket. The exact (symptoms of the) problem is:

Using built-in Physics and collision detection: When the racket is moving, the ball sometimes pass straight through the racket, and sometimes, it slows down (to unbelievable levels).

Using my script to calculate velocity: The problem is the same, but it lets me identify what is wrong when i print the normal of the collider (the racket). It sometimes give the right normal, and sometime gives the negative of the normal vector, which means that it is going straight through the top surface and detecting the hit with the bottom side of the collider (racket).

The things i have tried:

  1. Increasing the size of the collider (it works with the wider box collider on the racket, but then obviously the ball moves from quite a distance away from the racket, and my own script works here, default physics give strange results when racket is moved), in short i don't get the reality that i want.

  2. Decreasing the fixed timestamp to 0.001, which significantly improved things, but still very very far away from the result i want, and the ball is again quite often picking the wrong side of the ball.

  3. Changing collision detection to continuous dynamic. Which didn't improve things either.

And in addition to the wrong side picked at collision, another problem i have observed is that after bouncing off the racket, the ball is moves but the racket is moved faster, it instead of moving in a complete arc or line, somehow appears in front of the ball, resulting in two hits. It is a conjecture based on what is visible.

Also it is clear that the "movement" aspect of the racket is not being read by Unity3d's built in physics, resulting in strange behavior when racket is moving using mouse hits the ball.

I am stuck, i have no idea where to move from here. Please tell me what is it that i am doing wrong.

Answer

Elideb picture Elideb · Sep 10, 2011

As others have pointed out, the problem is that the ball goes from being on a side of the pad in one frame to being on the other side in the next. Fast moving objects tend to do that if the barriers are too slim.

There are three very simple solutions for this problem:

  • Increase the size of the pad or the ball, which is what happened when you changed the collider size.
  • Establish a maximum speed for the ball, so that it can never move fast enough to go through the pads.
  • Increase the frequency with which Unity makes its physics calculations. It can be changed in Time Manager, reducing the value of Fixed Timestep. Beware of reducing this too much, or the physics engine will be unable to finish a call before the next round is supposed to start and it will never be able to catch up with the game.

Setting a maximum speed for moving objects is something that must always be done. You cannot risk having an important object skyrocket during the game and leave everything in an uncontrolled state.