Continuous collisionA collision occurs when the physics engine detects that the colliders of two GameObjects make contact or overlap, when at least one has a Rigidbody component and is in motion. More info
See in Glossary detection (CCD) ensures that fast-moving bodies collide with objects instead of passing, or tunnelling, through those objects. Unity provides the following CCD methods:
To use sweep-based CCD, select a RigidBodyA component that allows a GameObject to be affected by simulated gravity and other forces. More info
See in Glossary in the InspectorA Unity window that displays information about the currently selected GameObject, asset or project settings, allowing you to inspect and edit the values. More info
See in Glossary window and set Collision DetectionAn automatic process performed by Unity which determines whether a moving GameObject with a Rigidbody and collider component has come into contact with any other colliders. More info
See in Glossary to Continuous or Continuous Dynamic. For speculative CCD, set Collision Detection to Continuous Speculative.
Sweep-based CCD uses a Time Of Impact (TOI) algorithm to compute potential collisions for an object by sweeping its forward trajectory using its current velocity. If there are contacts along the object’s moving direction, the algorithm computes the time of impact and moves the object until that time. The algorithm can perform sub steps from that time onwards, computing the velocity after TOI then re-sweep, at the expense of more CPU cycles.
However, because this method relies on linear sweep, it ignores the body’s angular motion, which can cause tunnelling effects when objects are rotating at speed. For example, the flipper in a pinball machine is fixed at one end and rotates around a fixed point. The flipper only has angular motion and no linear motion. Therefore, it can easily miss the collision with the pinball:
Another issue with this method is performance. If you have a large number of high-speed objects with CCD in close proximity, the CCD overhead increases quickly because of the extra sweeping, and the physics engineA system that simulates aspects of physical systems so that objects can accelerate correctly and be affected by collisions, gravity and other forces. More info
See in Glossary has to perform more CCD sub-steps.
Speculative CCD works by increasing an object’s broad-phase axis-aligned minimum bounding box (AABB), based on the object’s linear and angular motion. The algorithm is speculative because it picks all potential contacts during the next physics step. All contacts are then fed into the solver, which makes sure that all contact constraints are satisfied so that an object does not tunnel through any collision.
The following diagram shows how a sphere moving from t0 could have an expected position at t1 if there were no walls in its path. By inflating the AABB with its target pose, the speculative algorithm picks up two contacts with the n1 and n2 normals. The algorithm then tells the solver to respect those contacts so that the sphere doesn’t tunnel through the walls.
Inflated AABB based on current velocity helps detect all potential contacts along the moving trajectory, which enables the solver to prevent tunnelling.
Speculative CCD is generally cheaper than the sweep-based method because contacts are only computed during the collision detection phase, not during the solving and integrating phase. Also, because Speculative CCD expands the broad-phase AABB based on the object’s linear and angular motion, it finds the contacts that sweep-based CCD can miss.
However, speculative CCD can cause a ghost collision, where an object’s motion is affected by a speculative contact point when it shouldn’t be. This is because speculative CCD collects all potential contacts based on the closest point algorithm, so the contact normal is less accurate. This can often make high speed objects slide along tessellated collision features and jump up, even though they shouldn’t. For example, in the following diagram, a sphere starts at t0 and moves horizontally towards the right, with a predicted position at t1 after integration. An inflated AABB overlaps the boxes b0 and b1, and the CCD yields two speculative contacts at c0 and c1. Because speculative CCD generates contacts using the closest point algorithm, c0 has a very inclined normal, which appears to be a ramp to the solver.
Such a very inclined normal causes t1 to jump upward after integration, rather than moving straight forward:
Speculative CCD can also cause tunneling because speculative contacts are only computed during the collision detection phase. During contact solving, if an object gains too much energy from the solver, it may end up outside the initial inflated AABB after integration. If there are collisions just outside the AABB, the object will tunnel right though.
For example, the following diagram shows a sphere is moving left from t0 while a stick is rotating clockwise. If the sphere gains too much energy from the impact, it may end up exiting the inflated AABB (red dotted rectangle) at t1. If there are collisions just outside the AABB, as shown by the blue box below, the sphere may end up tunneling right through it. This is because the solver only computes contacts inside the inflated AABB, and collision detection isn’t performed during the solving and integrating phase.
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
More information
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising. Some 3rd party video providers do not allow video views without targeting cookies. If you are experiencing difficulty viewing a video, you will need to set your cookie preferences for targeting to yes if you wish to view videos from these providers. Unity does not control this.
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.