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
Everything is a trade off. Cut a corner here, a little more detail there. Design and optimization is a balance to get the best overall quality.
One important thing to note is that surfaces don’t have thickness, it’s a bunch of triangles stringed together. This makes it that if your character intersects with one of those triangles the physics engine starts calculating if and how it should push you away.
So in short, it’s actually a bunch of 2d surfaces spanned in a 3d world
Disclaimer: The following could potentially be wrong:
As far as I know, all 3D Models are created in such a way that they don’t have thickness.
Basically all you model are the things visible to the player and only the outermost layer. The surface of the model is divided into smaller so called faces. These faces have an orientation (normals) which basically determines the direction it has to be viewed. This is especially true when used in videogames, since they only render the side you should look at, making the model see-through from the other direction.
However, unless anything went wrong, you should never see this. To model in a way, that accounts for mistakes made elsewhere is a bad Idea in my book, not to mention the extra work needed to make it and for the game to render it.
tl,dr: Models are paper thin because you only model what you can see and to save ressources.
Ps: To prevent such glitches you should work on the update-order (check beforehand if a transform is possible) and make the colliders big enough. Modeling with density wouldn’t prevent the issue and would probably lead to a black screen (within material there is little light).
Terrain is technically just a picture that is shaped and textured. If computers had the processing power to handle an engine that could also handle rendered terrain being made in layers to provide that ‘thickness’ it would be more commonplace. It’s cheaper and a lot less consuming both on time and power to place an invisible wall where the terrain and objects begin than to render that many things just to avoid some clipping. All comes down to the programming as to how often it does or does not happen
Processing power simply put. Moving one image can be easy, but moving millions that are supposed to interact with each other(dent in a wall), requires too much effort and not enough reward for that process.
Usually, collisions are handled between the surfaces of objects. This is relatively simple and boils down to answering the question “Do these two shapes intersect at this time?” Time, however, has finite precison and is considered in finite steps (e.g. you might be checking 60 times per second). Any collision that occurs between those 1/60 second intervals wouldnt be detected until the next 1/60th of a second. If the game is not designed properly, you could have an object that moves from one side of a wall to the other side of the wall in 1/60th of a second and never actually intersects with the wall.
The solution is to either use a smaller time step (which requires much more work to simulate the same amount of time) or to make a more complicated comparison like “do these two shapes intersect at any time between the last time step and this time step?” (which also requires more work). For example, bullets in first person shooters are often treated as lines that instantly go from the barrel of the gun to the bullet’s impact point and that entire line is then compared against the world’s geometry. However, this gets much more difficult when you’re dealing with complicated objects and is too costly to be used for everything by default.
Well-designed games are able to use the appropriate collision methods in the right situations and should not allow situations where objects have properties that can break the simulation.
Clipping is caused by high velocity. If velocity was not abnormal there would be no clipping, so efforts are focused on preventing abnormal velocity as it avoids both problems. If you fix the clipping you still have the abnormal velocity problem so the gameplay is still broken. Kind of like how a plane breaks apart when it crashes. Making the plane stronger to survive the crash is pointless as the plane shouldn’t crash in the first place.
So game engines already do this or they would never work at all.
The collision engine checks “which side of this triangle am I on?” But if you build one of these engines you quickly find that a hard check clips all the damn time.
So you add what’s called an “epsilon” to the check. Essentially as you say your wall “thickness” – if something jumped past the wall in my calculation of where it was “supposed” to be, but not by that much, treat it as still outside/touching the wall and move it back outside. Some games do this by just moving things back immediately, some essentially put little “springs” on the object to “pull” it back outside.
You can technically make that epsilon as big as you want! But then – you can’t make any feature thinner than it. Like, if you want to walk on the roof and in the attic – too thick and it keeps kicking you up to the roof.
Also the springs solution (which is otherwise generally simpler/more general) can have weird effects when you’re too far from the surface – stuff that clips too far immediately gets *launched* back in the other direction. Sort of like the difference between walking and jumping on a trampoline.
You can try to track things more granularly but it all comes down to tradeoffs in performance vs dev time vs accuracy. And there’s always some situation the designers didn’t think of – like a tire that shoots off at mach 4 when you place it in a whole pile of grenades. In the end, computer physics is limited by its sample rate. If you’re doing physics at 30 fps, that tire moved *~~11~~ 45 meters* since your last update. You can sample faster, but then you’re making the game slower.
FWIW, some games have special logic for “terrain” that treats it as “infinitely thick” – but then your terrain and your building floors work differently, and caves and overhangs become problematic.
Source: software dev, wrote several game-style physics/collision systems in college.
There are many solutions, My go to is to make sure that altitude to ground is mapped with a ray trace, then clip it so it can only be 0+ and not a minus figure.
I make the game check for this if it detects the physics throughput is under 100%
all 3d modeling is based off of planes. everything ever rendered or gamesd on a pc is based off of polygons and triangles. they have a normal direction, that which points outwards and if you turn on a collider for that mesh it will detect the collission nebtween two colliders and prevent passage through, you can set up volumes (basically colliders you can pass through) that tell the collider that is moving that its not allowed to be in that area but fdundamentally there is no way to add thickness to a video game polygon
Latest Answers