I recently was out for a walk around my neighborhood a couple weeks ago, and as the critical thinker that I am, I began contemplating the universe. I was thinking about how video games are incredibly powerful because of the virtual worlds that game developers could literally "build and destroy" with their own imagination and the right tools. I then started to think about how games could be made more realistic and more enjoyable with destructible environments and material physics! After seeing the Crackdown 3 gameplay trailer a few years back, I became interested in applying realism to gaming. As a side note, These topics can also be applied to different forms of engineering, real-world simulation testing, and even VR as well!
For today, I'm going to briefly discuss some background information on 3D models and how that connects to Destruction in video games.
For starters, a Mesh is a collection of vertices, edges, and faces that structure and shape a 3D game object. Think of a mesh as a lattice-structure of these vertices and edges that represents the geometry of that 3D game object.
Most of the time, 3D game development tends to follow this process:
Game development always starts with thinking about ideas for every aspect of the game, which includes things like the story, characters, gameplay mechanics, theme, style, etc. Once these have been formally laid out, the developers decide which ideas will most likely be implemented in the actual game. Then the concept artists are put to work to create generalized sketches, or even technical sketches with dimensions and multiple perspectives, of the game objects and game environment. The concept art helps the 3D modeling artists to begin constructing virtual 3D meshes that depict the game objects. After a 3D model has been created, it has to be UV-mapped. UV-Mapping is the process of taking the complex geometry of a mesh (i.e. its triangles, polygons, and n-gons) and projecting that geometry onto a flat 2D grid to prepare for texturing. They use the term "UV Unwrapping" to describe this process. The UV part refers to the coordinate axes. The axes are labeled (u,v) instead of the classic (x,y) in Cartesian coordinates. Once you have these UVs laid out properly, you can layer an image onto the surface of the 3D model. This image to be wrapped around the surface of the 3D model is called a Texture. Textures are what make game objects seem more realistic and they make these objects have a "look" and "feel" to them. Then the game object is ready to be exported and used in a game engine! Yet, it's easier said than done of course! :)
Now, here is the part on how 3D models relate to destruction.
There are a few limitations to mesh deformation in video games. Here's why: A while back, game developers traditionally meant for 3D models to be "static" in the game world, meaning the mesh (i.e. its geometry) and textures weren't meant to be changed at all when the game was running. Sure, these 3D game objects could be moved (translated), rotated, or even scaled at runtime, but that never changed the virtual geometry of the mesh. Due to the massive computational load on many computers, 3D models are usually intended to be static entities. Yet nowadays, changes to a game object are often desired by game developers. By "changes", I mean object deformation and destructibility, whether that be through colliding with another object, the player physically applying force to an object, etc.
Since computers have gotten more and more powerful over the last few years, a lot of game companies are trying to uncover new techniques to make these "changes" possible at runtime.
For example, suppose you are driving your favorite car extremely fast in a game. You suddenly lose control and smash into a concrete barrier with the front of your car! Oh no! Normally, the player would expect the front end of the car to take damage and have massive deformation, such as the hood now being dented, the paint scraped off, the bumper hanging on by a thread, or whatever. In this example, one problem developers face is calculating the area of impact, the amount of damage the car took, and what parts of the car should deform in a seemingly realistic sort of way. Another major problem would be the car's UV mapping and texturing. The UVs and the textures of that object would need to be recalculated and updated after every single collision (given that deformation occurs). If developers don't update the UV maps (or if they don't recalculate the UVs correctly) then the textures wouldn't map correctly to the mesh and the game object would look TERRIBLY unrealistic in the game!
One work-around for this limitation would be for developers to create other separate 3D models of the same object, each of which represents a varying amount of destructive damage on that object. The good news is that each one of these meshes of varying amounts of damage only have to be UV mapped and textured ONCE, and thus requires no updating when the game is running. Then, when that object receives a certain amount damage in the game world, that object is removed from the scene altogether and replaced by the more damaged 3D model of the same object. This switch in meshes happens in-between update frames, so the player (almost always) cannot tell this has happened! The limitation of this approach is that the developers would have to create a TON of different 3D models that are all UV mapped and textured in order to make the game feel very realistic. It also would be super hard to accurately control which mesh to replace. What do I mean by this? Consider the car example again. Let's say you only have four levels of destructive damage to your car (that is, four different 3D models of the same car with different amounts of damage). If your car gets side-swiped by another car in the game, the player would expect some scratches or dents on that specific side of the car. It would seem very inaccurate if your car was replaced with the mesh that had the hood dented upward and the bumper breaking, since there was no collision even close to that area! This leads to the limitation of this approach. Developers using this work-around would have to spend LOTS of time creating LOTS of separate meshes, UVs, and Textures for the game object to act realistically. Developers would also have to worry about the specified area of impact to make the mesh replacement more realistic and physically correct! Not only that, but the same 3D models that represent the destruction of the car would become repetitive over time, unless you created a large number of them!
Thus the limitations of the approach to creating separate 3D models with varying amounts of damage would be:
Time-consuming to create meshes
Need to create lots of 3D meshes for different amounts of destruction, with UVs and Textures
Managing the Transition between different meshes accurately upon collisions or deformation
Unrealistic and Repetitive - if there aren't that many 3D models to replace the mesh with
That's a lot of information for today! Hope that was all clear!