Update (14 August 2020): Looking for an article on the Interpolate property on Unity Rigidbodies? We’ve put one together recently, so have a look here.
It isn’t particularly difficult to set up physics-based movement for objects in Unity — simply add a Rigidbody component onto an object that has a Collider component, and you’ll have yourself an object that moves and collides realistically with other objects.
If you start having fast-moving objects however, you might start to see these objects tunnel through obstacles.
The illusion of motion and tunnelling
Before we delve into why tunnelling occurs, it is important to understand this: the motion that we see in animated media is an illusion. Anything that appears to move on a screen does so because the screen is showing us a rapid sequence of images. This tricks our minds into thinking that there is motion, even though what we saw was a series of static images.
Similarly, the motion of the ball that we saw above was made of many individual images, each one showing the ball at different positions. How much a ball moves from one image to the next depends on how fast it is moving. Hence, a slower-moving ball moves very little from image to image, while a fast-moving ball can move a distance equal to several times its diameter from one image to another.
Because fast-moving objects cover so much distance from one frame to the next, it may skip over thinner objects (as pictured in the image above right) without registering a collision, since there is such a large gap between its positions in any two frames. This is what causes the tunnelling phenomenon you see.
The solution: Continuous collision
To address this problem, physics engines utilise a collision algorithm that projects a shape across an object’s path of travel. This shape is then used to check for any collisions from the object’s displacement between frames.
This method of detecting collisions is called continuous collision detection, whereas the one that doesn’t prevent tunnelling is called discrete collision detection.
Discrete vs. Continuous collision
Although continuous collision detection is clearly the better choice, game engines generally do not enable continuous collision detection for all objects in their physics engines. This is for a simple reason: continuous collision detection is significantly more expensive, so having too many objects using it can unnecessarily use up computing power! Since only fast-moving objects suffer from the tunnelling problem, developers often enable continuous collision detection only for these objects.
In Unity, the option to turn on continuous collision detection can be found on the Rigidbody2D and Rigidbody components, which are used in 2D and 3D games respectively to give objects physics-based movement. Again, the idea here is to set the collision detection mode to Continuous for fast-moving objects, and leave the rest of the objects at the default value of Discrete.
Article continues after the advertisement:
Continuous Dynamic vs. Speculative
If you look at the Rigidbody component, you will find that it has 2 additional values in Collision Detection compared to its Rigidbody2D counterpart: Continuous Dynamic and Continuous Speculative. These additional collision detection modes are further optimisations, unique to Unity’s 3D physics system, and in place because 3D collision detection can be potentially much more expensive than its 2D counterpart.
Rigidbody components that use the Continuous mode only use continuous collision detection on static objects (i.e. Collider components without a Rigidbody, which means the object does not move using Physics). This means that, in theory, tunnelling can still occur when you are colliding with any object using a Rigidbody component.
Objects using the Continuous Dynamic mode will not have these issues, as they will use continuous collision against all objects, except against Rigidbody objects using Discrete collision detection.
Continuous Speculative is even better. It collides against everything — static and dynamic objects in all modes of collision; is computationally faster than the other 2 modes of continuous collision; and detects certain kinds of collisions caused by spinning objects that are missed by other modes of continuous collision.
However, because it speculates (i.e. predicts) collisions based on objects’ current motions, collisions that are detected can sometimes be inaccurate.
Making sense of everything
All of this can be pretty confusing, isn’t it? Here are some good rule of thumbs to help you decide which modes to use:
- If there are no fast-moving objects in your game, you can safely use Discrete collision detection for all your objects. An object can be considered to be fast-moving if it can travels a distance larger than its width or height within a frame.
- If you don’t care about collision accuracy in your game, Continuous Speculative will be the way to go with your fast-moving objects. The rest of the objects in the game can use Discrete.
- For dynamic objects (i.e. objects with
Rigidbody) that don’t touch fast-moving objects at all, you can safely use Discrete collision. - For dynamic objects that are not fast-moving, use Continuous collision on them if you need them to always collide with fast-moving objects.
- For dynamic objects that are fast-moving, always use Continuous Dynamic collision.
As a summary to help make sense of all the information above, here is a table that outlines how each of the collision modes interact with one another:
| Collision Detection Mode | Static | Discrete | Continuous | Continuous Dynamic | Continuous Speculative |
|---|---|---|---|---|---|
| Continuous | ✔ | ||||
| Continuous Dynamic | ✔ | ✔ | ✔ | ||
| Continuous Speculative | ✔ | ✔ | ✔ | ✔ | ✔ |
Article continues after the advertisement:
More important are the Physics Project Settings (Edit>Project Settings>Physics).
Default Solver Iterations,Default Solver Velocity Iterations and Default Contact Offset.
Playing with this values it’s what stopped my very fast character with rigidbody from going through objects with mesh colliders.
Tried to play with the rigidbody collision detection (discrete,continuous…cont dynamic,cont spec) and nothing worked.
It was still going through.
Modified the Default Solver Iterations,Default Solver Velocity Iterations and Default Contact Offset to 1,1,1 and after that it didn’t matter that i had discrete or any of the continuous options at the rigidbody because any of the options would still stop my rigidbody from going through the object mesh collider.
Ofcourse I chose Discrete since it’s the least resource intensive.
Hello, I’m trying to use collider in my ACT project, but I found that though I choose ‘Continuous Speculative’, my melee attacks still have about 20% possibility to miss detection. Both my attacker’s weapon collider and my hurter’s body collider are set as continuous, but it seems to work not well. The animation length of the melee is about 0.1 second (or 5 fixedupdate), which means the weapon sweeps about 40° per fixedFrame on average. Is the speed too fast for the continuous detection?
Hey Reekin,
Continuous Dynamic is usually used for moving objects, and Continuous used for stationary objects that should not be tunnelled over. So if your weapon is animated, you can try setting it to Continuous Dynamic.
I would advise against using the weapon collider to detect attack damage though, as the collider animates together with the character, so collision detection for it is going to be much more expensive mathematically. Fighting games normally use basic shapes to form hitboxes and hurtboxes for attacks and characters respectively.
Here’s an article that goes through some of the key features of fighting games in general, including hitboxes and hurtboxes: https://paynegaming.wordpress.com/2018/03/23/game-development-week-8-hitboxes-hitstun-and-invincibility-frames-in-fighting-games/