3D Models
3D Print Models
3D Scans
Animation & MoCap
Textures
Materials
Skin Textures
2D Game Assets
Sound Effects
Brushes & Tools
Reference Photos
Stock Images
HDR Images
3ds Max
Maya
Blender
Unreal Engine
Unity
ZBrush
Cinema 4D
LightWave
Marmoset
SketchUp
FBX
DAE
DXF
GLBCollision Detection and Why Invisible Walls Need Careful Handling
0Article by Yuri Ilyin
Collisions as physical events are a natural part of the vast majority of video games. Modern game engines go to great lengths to approximate them convincingly.
Set them up the right way, and you'll create a smooth and believable experience for players. Set them up incorrectly, and immersion is quickly broken - few things feel worse in a game than "glass walls" over obviously walkable or climbable slopes. Collision meshes are invisible to the end user, but from a development perspective, you don't want to get them wrong.
What are collision meshes, after all? In most cases, they are 3D objects that the physics engine uses to calculate where and how other objects will interact with them upon collision, and how these objects interact with the environment - such as floors, walls, ceilings, and random obstacles.
Think of a projectile hitting a specific point on a target, or what happens when a player or non-player character runs into a wall. In both cases, the collision mesh needs to roughly match the shape of the visible object, and the map geometry must be explicitly defined as solid surfaces.
In fact, a wide range of technical aspects depend heavily on the 3D engine being used.
For example, the original Quake used upright boxes for collision detection - that is, for determining when the player or NPC characters hit walls or other obstacles. This method was a fundamental part of how the game data was structured overall.
John Carmack, the original Doom and Quake engine programmer, implemented the Binary Space Partitioning method (BSP), which enabled the display of fairly complex 3D spaces in real time, even on average 1990s hardware.
It's worth mentioning that the original Quake I-III engines also utilized a concept called a "brush" - a somewhat odd name for a macro polyhedron from which most of the map geometry was constructed. Though seemingly obsolete, the concept is still used in modern engines for two purposes: blocking out levels and, later, constructing the map collision framework.
Up through Quake III Arena, using Axis-Aligned Bounding Boxes to encapsulate player and non-player models was the only method of collision detection and testing in BSP-based games.
Given that the BSP approach was inherited by the GoldSrc engine (which powered the original Half-Life), as well as Source (Half-Life 2) and the earliest versions of Unreal Engine, it's safe to assume that they employed more or less the same principles of collision detection.
This was a robust approach but limited in its capabilities. As technology progressed, so did the expectations for realistic real-time physics.
Newer games utilize more complex meshes, such as spheres and rounded capsules, along with simplified variants of the in-game objects.
Reference: Wallace Breen from Half-Life 2
Still simplified, since it enables approximation of physics-related computations economically (the simplified mesh is occasionally called "cheap"), yet with convincing results.
Physics, obviously, is computationally intensive, and the more realistic it becomes, the harder it is for a computing system to handle. So corners get cut - non-continuous and/or area-selective collision detection methods are employed, etc.
Unity, for example, supports Rigid Body physics with several continuous and discrete collision detection modes, along with physics materials that enable different behaviors.
Continuous modes use predictive algorithms to calculate collisions that happen between physics timesteps. This provides more accurate results, but comes at a higher computational cost than discrete collision detection algorithms, which check for collisions only on each physics timestep.
Continuous collision detection modes (CCD) may employ speculative and sweep-based approaches to predict possible collisions, but there is a big neon sign: "Handle with care." Excessive use of CCD may turn your game's FPS into a slideshow, even on a top-tier system.
There are also numerous supported collider shapes, including fairly complex and compound ones.
Unreal Engine, in turn, appears to utilize a fairly branched system: every object can have one or more collision response flags and can therefore be interpreted as static, dynamic, destructible, or specifically as a vehicle.
In general, Unity and Unreal Engine map geometry mostly consists of static meshes - models created in a 3D suite of choice, like Maya, 3ds Max, Blender, Cinema 4D, etc. - imported into the map editor. But, as mentioned earlier, brushes can still be used as well.
Collisions can also be used creatively for dramatic, storytelling, and technical purposes, such as directing player progress across the map or preventing them from going somewhere they're not supposed to be - yet or anymore.
This saves resources and ensures smooth gameplay.
However, sometimes things go very wrong. Fallout: New Vegas is a negative example of a seemingly open world filled with invisible walls in unexpected places, where nothing appears to justify them. For example, the player can crawl up a long slope nearly to the top of a mountain, only to find it's impossible to cross, even though the slope doesn't get any steeper.
Reference: Fallout: New Vegas (modded)
In fact, there were purely technical reasons, which also had a lot to do with Obsidian's lack of experience with the Bethesda-provided engine.
Josh Sawyer, FNV project director and lead designer, has previously said that the 'invisible walls' were one of the things he'd go about in a different way:
"I would also loosen up a bit on real-world map accuracy and insist that the world builders use as few invisible walls as possible -- only to prevent them from falling and getting stuck, never out of a concern about sight lines and LoDs, especially since I/we understand how LoDs work in the engine much better now."
Simply put, those nasty invisible walls were there to prevent players from seeing what they were not supposed to see. And the examples of proper use of invisible barriers? That would be every game where you need to try hard to actually notice them. Invisible is the best when it is, well, unnoticeable.
