I could see why you might not want to fill under the terrain in a game that features things like underground caves, but thin terrain seems to be present in a huge majority of 3D games (even those without underground features) and is not engine-specific. Why is terrain almost always a fragile piece of origami that’s so easily punctured?
In: Technology
Warning: Gross simplifications of physics engine. Explaining the full implementation wouldn’t fit into a reddit comment.
The reason that they’re paper-thin is basically because of performance. We can quite easily calculate whether one collider (which can be a few different shapes) overlaps with another collider.
Colliders usually consist of primitives, or meshes. Primitives includes basic shapes such as planes, cubes, spheres and capsules. These can all be represented mathematically rather easily, and are also quite easy to check for collisions.
A mesh is a bit more complex, but not by much. A mesh is basically the same as a 3D model (and the terms can be used interchangably). So when you have a mesh collider, the collider consists of triangles. Each triangle also has information about the direction it’s facing (the normal) to signify which direction is in and out of the mesh. With that you can check each triangle for overlapping as well. This calculation will almost always be more expensive than primitives. (I’ll get into why this is needed later)
So to recap so far, there are primitives and meshes, and both types of colliders are fairly easy to check whether they overlap with each other. Some types are also less taxing on the computer because of the way they’re constructed. Checking whether two spheres are colliding with each other is a simple distance check.
Checking whether a plane collides with something is also fairly easy, but still more complex. What can you make with 6 planes? A cube! So you would need 6 planes to make a cube, making the computation a lot more expensive. So often, devs put planes instead of cubes because it is simply more performant. Especially for larger surface areas.
This can, as you’ve noticed, result in objects clipping through. But there are tools that can fix that without computationally being much more expensive. Interpolation is the most common one. Let’s say you fire a bullet. In a single frame, it moves 10 units. So you just set the position of the bullet to it’s position+direction*10, right? Well, that’s where you run into the clipping issues. However if you instead make a line along the direction, you can check whether that line overlaps with any other collider. As we’ve already established, that’s quite easy to do. You can even get the exact point, so you get the perfect collision.
Except a bullet isn’t just a line or a single dot. Usually, a bullet has some volume. As I mentioned earlier, primitives are the least expensive to calculate. So let’s use a capsule to represent our bullet in our physics engine. This time, we also do the same thing with our line. But this time, instead of just checking a line, we essentially check in a sphere around the bullets path. We can do this, because putting a bunch of spheres next to each other in a line is just a capsule as well. Furthermore, checking a radius along a line is still quite simple computationally. With this, we can now interpolate between the current position, and the intended position for this frame, and see if there are any collisions, which should fix any object clipping.
This can be done with any collider, however things quickly get very expensive once you use mesh colliders. Different primitives will also give you different results. And not doing the interpolation is even more cheap, but will then result in clipping.
Latest Answers