Creating colliders can be a tedious job without the right tools. During my time as a Lead Artist, I spent hours explaining how to make the process shorter and understandable. Add more time to send work back because of missing collision objects and you have the typical day of a regular Art Manager.
Personally, I enjoy this part of the process, it’s like a puzzle. How can I make this work with the least amount of collision objects?
Before we can answer that question, let’s delve into what collisions are there for, how they work, and why some are cheaper than others. All the following statements are based on my experience, as well as the research I did over the years, reading articles, etc.
In the comments section, you will be able to correct me, and we can add an edit to this post with your name and what your contribution was.
Every game engine manages collisions in a different way, but they all use them for the same purpose.
If I had to be concise about their uses I would separate them into three basic ones. Ray hits, player navigation, and physics.
Ray hits occur when a ray (A line drawn between point A and point B) finds a collider in the way.
Player navigation takes the collision information from the player and uses it to limit its movement. An example of this would be a player trying to go through a wall, which is avoided with a collider.
Physics are the most interesting ones. They use colliders to determine the limits of a physics-based movement. A cloth simulated without colliders would intersect with other geometries, often causing a buggy look.
For all these three, collisions are calculated as follows:
- Object A is calculating its own collision. If nothing happens, no triggers are activated.
- When Object A detects an object with a collider in it within its collision’s bounds, it reads that there’s been a collision.
- The collision gets filtered by tags, layers, etc. The name depends on the engine. What these do is tell an object if it should trigger something or not depending on if it’s asked to collide with objects grouped under that tag or layer. Some games don’t want their enemies to be colliding with each other when there are many of them on-screen at the same time, for example.
- If the filter turns true, we have a trigger, which will either define the block that we can’t go through or launch a series of actions, like for example, an explosion if a grenade’s collider enters another object.
Collisions are calculated every frame, so an object going too fast might miss the frame that the collision was being calculated, and go through it.
Now we roughly know what collisions do. Let’s take a look at what types of collisions we have, when they should be used, and why.
Let’s start with the most expensive one. Mesh Colliders.
A Mesh Collider uses the information of a mesh to generate a collision object using its vertices.
How these are calculated:
- The engine takes every single face of a mesh and reads if something is intersecting with it.
- The colliding object needs to check for collisions on potentially every face of the object. 3.5k triangles mesh collider means 3.5k checks. (I could be wrong, but reading about this in many forums, it seems like that’s the reason.)
- Added to this, the collision is not pre-calculated, so you are basically having double the triangles for every mesh using this.
- As you might have guessed, a high poly mesh means a very costly collider under this method.
- My verdict: EXPENSIVE.
Following up, the second most expensive way to work with these beautiful objects. Convex Hulls.
These colliders are simple to understand. Taking the protuberant areas of the object, we generate a simplified mesh that roughly encapsulates our asset. There’s one limitation with this one, and that is concavity. You simply can’t. It’s an Nvidia PhysX limitation.
As you can see, this is much cheaper than the previous example, but having a mesh do collider’s work is still quite expensive.
How these are calculated:
- The engine takes every single face of the convex hull mesh and reads if something is intersecting with it.
- These are still not pre-calculated, so you are adding more geometry to your model.
- The colliding object still needs to check for collisions on potentially every face of the object. The way colliders work, the calculation of a simple math-based shape is much cheaper than having to calculate the position, direction, and rotations of faces.
- My verdict: MODERATELY EXPENSIVE.
The previous methods we described are generating custom math that the engine has to solve. If we are calculating many points in many faces, the process of checking for collisions becomes expensive, and that’s why we have simple shape collisions.
Up next, are simple-shaped collisions, like spheres, boxes, and capsules.
Everything comes with a cost. In this example, we can see how having a sphere will mean that areas like the top will collide with objects that aren’t really touching the mesh inside it. It’s always a balance.
How these are calculated:
- The engine generates a sphere with very simple math. For Boxes and Capsules, the same rule applies.
- These spheres and boxes aren’t adding to the vertices of the mesh, as it’s not a real sphere or box, it is a representation of one.
- The collider needs to check, on the sphere’s example, if another object is within the radius of that sphere, not the position of many faces. On the box, it needs to check for bounds.
- My verdict: CHEAP.
A sphere is generated with fewer input data than a mesh, a box needs more information, but still can’t be compared with the hundreds of vertices a custom collider can have. Capsules are apparently cheaper as well, as there are relatively fast to process formulas to generate them.
When it comes to detecting collisions, the fewer instructions the engine has to make in order to detect an object getting into another, the better.
When simplifying a mesh’s colliders, we can run across problems like the object colliding when it’s not touching a part of the mesh, etc.
To solve these types of issues, we can combine multiple box colliders which will be cheaper than having custom ones, like so:
This article might have been a bit heavy, so here’s a brief summary of what we’ve just seen, in case you missed something, quickly scrolled, or just didn’t feel like reading it.
In order for a collision to be detected there has to be one of the following things happening:
- Another collider touches it.
- A ray is cast towards the collision and hits the face of the collider.
- An object’s movement and behavior are calculated through physics.
Why can they become more expensive if they are UCX rather than UBX?
- UCX is a mesh. It doesn’t matter if it’s optimized. The way engines detect this is generally by calculating the hit points of a particular shape that can’t be calculated in a simple form. It needs to convert that mesh into custom maths and information that work for the engine to detect collisions.
- UBX is a precalculated bounding box. The collision needs to detect if the other collider or ray hits the bounds of a precalculated shape. The only information we introduce into the calculations here is the size of the box.
- UCP (Capsule colliders) and USP (Sphere colliders) Are the same stories. They are precalculated so that’s why they are cheaper.
What can we do to simplify collisions?
- Reduce the number of triangles in mesh or convex hulls.
- Use Box, Sphere, or Capsule Colliders whenever possible, completely replacing mesh and custom convex hull colliders if possible.
If you wish to read a more in-depth article about collisions in games, give this article a read:
As always, hearing your feedback is one of the most valuable things to me. Let me know what you think about this in the comments, be critical!