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
It increases what you have to process
It’s easier math to average out your latency and add in desynch to do max travel distance to see if you collide with something rather than tracking every square inch of internal stuff then do a collision check . You still have to do the first calculation to identify point of impact.
In older games like Mario 64 they didnt do sweep tests. They did per frame checks. They assumed you couldn’t get enough speed to move fast enough in a single frame to move through a surface. Insert the backwards stairs jumping trick and you gain enough velocity to go through walls. Modern games will parameterize the collision check by time (t0 and t1) and detect when/if the collision happened.
You’re thinking about the ground wrong.
You’re thinking about the surface of the ground as its volume, but those aren’t the same thing. The ground in games is not necessarily thin, it’s often quite thick – sometimes infinitely thick (ignoring technical details like integer limits).
What does it mean for something to be thick? Think of the thickness defined by two flat surfaces, and the volume between them is considered the “interior”, and the thickness is the distance between them. Any point between the coordinates of those surfaces is inside the object, otherwise it’s outside.
Now look at the ground in a video game. Sometimes it really is thin, even infinitely thin, so if a given volume does clip past it, you don’t trigger any code to deal with clipping inside something, and instead you just “fall” until something else happens (you hit a kill plane, an integer overflows, etc.). This isn’t necessarily a huge problem so long as you consider the collision detection and the size and speed of the objects that might collide with the ground.
But often *all* points below the surface of the ground are considered inside the ground, and that thin “origami” isn’t the geometry of the ground, it’s the geometry of just one surface of the ground, and the ground is in fact so thick that *any* point below it is considered to be within it. If the whole world has a defined floor surface, you might simply clamp the vertical position of everything according to that surface instead of even checking for collision, which is functionally equivalent to doing collision detection checks with an infinitely thick ground.
The thing that is tricking you is that, because we model things as rigid colliders, unless you’re doing something like destructible terrain, we usually don’t bother specifying what things look like on the “inside”. If collision is rigid, and the camera is subject to collision, only the outside should ever be visible. So if you do manage to clip the camera into the ground (because the collision simulation fails), you discover that, unlike real-life solid objects, only the surface is visible, and often only one side of it. You could also just assume that inside of things, all light is blocked, so the screen should just be black, and occasionally games will do this, but that’s useless to the player who accidentally clips inside something (and makes it harder for them to get the camera back out), and makes debugging potentially harder.
So visually it looks kind of like the ground is thin, but *geometrically* the ground may actually be very thick.
There really isn’t such a thing as thickness per se in 3D models. Every object in any game you have ever played is simply an empty shell, and this shell is infinitely thin. Even accurate physics simulations with millions of particles are limited by the fact the particles can only be so small before it becomes impossible to process by any system that currently exists.
Solid objects in the world have “thickness” because they are composed by trillions and trillions (and so on) of atoms, and you simply cannot make something anywhere close to a real solid object in digital.
There are ways to get better collisions though, but I am nowhere smart or qualified enough to tell you how that’s done.
In short, “because it’s expensive”. I’ve written some software that needed to do it “right”, and it’s a lot slower.
The correct way to avoid clipping is an algorithm that looks like this:
– Draw a line from my position last frame, to my position now
– For every triangle of every surface, calculate if the line crosses the triangle. (Note: this is surprisingly inexpensive if you do out the linear algebra. Still costs a few dozen mathematical operations though).
– If no triangles were hit, you’re fine. If one triangle was hit, collide with it. If more than one triangle was hit, choose whichever one was hit *first*, and collide with that one.
– Depending on your collision algorithm (i.e. if you bounce off and still are moving), do the whole thing again based on your new start-point and velocity.
Now, the problem is that this is insanely expensive for decently complex terrain. So, to make something functional, game engine designers need to cut some corners. The biggest one is to limit the area in which we look for triangles. The more triangles we can ignore, and the more efficiently we can ignore them, the faster it will be. The problem, of course, is that if we should have collided with something we ignored, we clip.
The second thing we can do is cut down on how much math is involved. Instead of calculating the intersection between our previous and current position with the triangle, we just check if we’re near (and on the wrong side of) the triangle. It’s a lot faster, but can (in some cases) cause somewhat weird artifacts.
You will note that both of these methods include tunable parameters: the designers need to pick the correct balance between better game performance, and the edge-case of clipping. Usually this is set so that in normal gaming, you don’t have clipping problems; those only come up when a player does something extremely weird.
You can only be above or below terrain. you can’t clip through it because if the physics detects that an object is below the terrain it moves it above it. As others have said it makes terrain appear infinitely thick.
I remember reading some developer speak about this.
People kept saying like “oh it’s wild that the developers still let you do that.”
and they responded with, “I’m not your dad. If you can find a way to run through a wall then fucking go for it.”
I can’t remember who it was but my best guess was it was an indie game developer on twitter iirc.
Being “filled” or not is only different to you because you are thinking of reality. In the computer there would still be physics issues if you pass through a wall between physics updates. The solutions require processing power, which is the lifesource of a game. When resources are spreading thin, you get fringe anomalies like this.
Short answer is that basically, you cannot. In games, everything is made of various surfaces. Even in 3D modelling, if you make a “solid” part, it’s only shown as solid (e.g. it shows another surface in cross sections), but aa pc can only display a “surface”.
Normally, you can’t see or move under the surface, but glitches happen…
In the PlayStation game “Days Gone”, I’ll be driving the motorcycle and all of a sudden I’ll just fall through the floor. Also as I’m driving, the game isn’t able to load as I’m driving. I have to stop the bike in order for the game to load in textures. It’s like it’s lagging. Is that kind of the same deal as he’s asking?
Latest Answers