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
I’m going to chime in as a 2D game developer, although similar principles apply to 3D games.
Imagine a bullet traveling at 600m/s being shot at a 5m thick wall. Assuming 60fps, the bullet will travel 10m every tick. So it you are just checking for point collisions every tick, then the bullet will be on one side of the wall one tick, and on the other side the next tick, completely bypassing it.
What you need to do is, instead of checking for point collisions (∆x^2 + ∆y^2 < r^2 ), you need to check for line-to-circle, or line-to-line collisions.
These aren’t actually all that expensive, but the cost does add up. So the common sense approach is to do this for high velocity objects like railgun bullets or hitscan weapons, and use point collisions for most other things.
Consider a shotgun that shoots 200 pellets per shot. You want to minimize the number of calculations you have for each of those projectiles. But if it is a sniper rifle that shoots once per second, you can go all in, and do precise collision checks all you want.
Also, I mentioned hitscan weapons above. Those are actually great from a performance point of vjew, as you just calculate them once, instead of having to do it every tick. But for a regular high-speed projectile, you need to do calculations every tick. However, against static objects like terrain or props, you can still just do the whole calculation once, and note when the projectile will collide with terrain. Then, on every tick, you just need to check the projectile against the moving entities like players, enemies, etc to see if you hit anything before you hit the terrain.
I know this doesn’t directly answer the question, but I hope it provides some useful insight at least.
In the 3D world there is no such thing as actual, solid thickness. Take a look at [this image](https://i.imgur.com/aX3YNKQ.png)
The first shape is a single flat plane. You can “thicken” it if you like (second shape), but in reality, if you actually looked inside it, you’ll see it is still hollow (third shape).
So if you try to thicken the terrain, you’ll only be adding another thin plane underneath it, not actually thickening it.
First of all I’d like to add a quick explanation as to *why* high velocity colliders clip through surfaces.
Consider this:
Bullet (usually a prime example): o
Wall: |
These are the colliders of these two objects. What you usually do is check if the circle overlaps the line (the surface). What might happen though is this:
Frame 23: o |
Frame 24: |o
In frame 24, we check for an intersection… but the bullet already went past the wall, so these simple (aka efficient) calculations couldn’t see that it went *through* it. So RIP collision.
There are of course solutions to this problem, a common one is to extend the collider: each frame, we make a big one that contains both the collider in frame 23 and the one in frame 24, like so:
Frame 23: o |
Frame 24: |o
Check: Ϲ═╪Ͻ < please pretend it’s a capsule
There we go, now we have an intersection, good job us. Of course this is overly simplified, but that’s the idea.
The real algorithm is slighly more complicated and this additional “complication” makes it fairly more expensive than our first strategy where we only check the single collider, so we can’t use it everywhere, we only use it for fast moving, small objects.
Since the player shouldn’t be either fast nor small enough to completely pass through the terrain in one frame, expecially since in most cases the player is taller than wider and… you know… you fall vertically of course… you avoid the more expensive strategy as it shouldn’t be necessary.
They aren’t paper thin. They’re *zero* thin. Why make the underside of the ground if no one’s going to see it? It works exactly the same if it’s thicker as long as there are no gaps and giving it thickness would cost resources.
big things need big memory. If you want to pack more things in then you need more memory, bigger things take longer to load and save. The limits in any software are speed and size.
This subreddit never actually explains like I’m 5. They explain like I have a master’s degree in the subject and it’s really kinda pointless
Lets simplify the issue and think in 2D, with two triangles that can be at any place and any rotation.
A triangle is made of 3 points (vertices). It’s actually quite computationally difficult to determine if a point is inside another polygon.
But a triangle is also made of 3 lines. Lines are much easier for computers to work with; they can tell if a pair of lines intersect quite quickly, so most collision systems are checking if lines intersect.
The issue is that if an object moves too fast it can be on one side of another object’s collision line on one frame and on the other side the next frame.
Because none of the lines are intersecting, the system doesn’t detect a collision.
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.
All 3D graphics surfaces are paper thin, because that’s how graphics cards work. The only way to add depth is by adding additional paper-thin layers. Adding more would not help, because if you clip through the first layer, now you’re on the next layer, which you could then clip through. No matter how many layers you add, you could still eventually clip through them all. Because of this, it’s better to use other methods to try to prevent clipping.
Video games use what is called “surface modeling”. There is no concept of thickness to the models at all.
You could increase *collider* thickness, but that’s not a fix. If your computer has a hitch for some reason you will still “bullet through paper” if using a naive physics solver.
When we would write physics solvers in school ~20 years ago we would project volumes for objects moving from A to B and test those against every other object’s trajectory, and then solve for the exact moment and point of collision. There was no bullet through paper problem.
Latest Answers