This article originally appeared in Dev.Mag Issue 2, released in April 2006.
Wondering why your PC doesn’t play games so well anymore? Trying to decode the latest marketing-speak on the back of a game box? This series is designed to give you the knowledge you need to understand the tweaks and trade-offs you can make to improve your gaming experience. We’ll go through the concepts behind the gibberish on the options menu, without going into all that math!
The basics
The first thing anyone needs to understand about 3D games is that it’s all fake. Everything you see on your screen is some kind of trick. Even the newest ultra-realistic computer generated effects in your favorite movie are based on tricks. Very clever little tricks, but tricks all the same. An ideal graphics system would simulate light interacting with the atoms that make up objects and then hitting the back of your eye. Good luck writing a perfect 3D world, unless you’re Einstein or Stephen Hawking.
But even if our favourite quantum geniuses wrote a 3D engine, it’d be incredibly slow. Because that’s what we all care about in the end, the speed our games run at. We need the image on the screen to change between 30 and 60 times a second to fool our brains into seeing smooth animation. (Unless you’re a pro-gamer, gifted with super-human eyes and reflexes) Most games are perfectly playable if they achieve around 35 frames per second (or FPS for our twitchy, light-sensitive friends) dip too far below 30 FPS and we lose our suspension of disbelief and the game turns frustrating.
The 3D engine
We’ve all heard of the term “3D engine”, they’re the arcane lumps of code responsible for giving us our graphics fast enough. In the days before 3D accelerator cards, unwashed programmers tamed strange beasts like the S-buffer, active edge lists and BSP trees to perform their mathematical magic on underpowered CPUs. Nowadays we simply throw data at DirectX or OpenGL (both are API‘s, Application Program Interfaces, that sit between programmers and your 3D hardware) which do most of the magic on a graphics card to produce modern visuals. All a 3D engine has to do now is figure out which objects need to be displayed when and then tell your 3D hardware how it should display them, there’s a little bit of setup involved, but we’ll get to that later.
So what gets displayed?
Vertices and triangles
Remember that everything in 3D is some kind of trick. So, to display something that looks like it has volume and shape on a 2D screen, we need an approximation that’ll work. Enter the humble triangle. A triangle is the least amount of information you need to define a flat surface: Three corners, which we call vertices (singular = vertex), define a plane in space; One corner is simply a point, two define a line and four don’t always lie on the same plane; five is right out! To a 3D card, the order in which the corners are sent matters (it’s used to calculate which direction the surface is facing) but logically the corners can be specified in any order and you still get a triangle.
So, we now have a way to define a flat surface that can have any orientation, great. If we put enough of these surfaces together, we can approximate pretty much any shape we can think of. Stick a whole bunch of vertices describing triangles together, lob them at your 3D card and *POOF* you have a mesh. Meshes display everything in a 3D game, some are generated on the fly, like the terrain in FarCry, others are animated (which means their individual vertices move around relative to each other) and still others are responsible for displaying effects such as shadows.
Wireframe, untextured and final versions of a mesh.
Wireframe, untextured and final versions of a mesh.
So, what have we learned?
- It’s all a lie.
- 35 or more FPS = suspension of disbelief.
- Modern 3D engines rely on clever APIs (DirectX or OpenGL) and hardware.
- Anyone who writes software 3D engines is crazy or Carmack.
- Graphics = Mesh data = Triangles = Vertices.
So graphics relies on the idea of a vertex, which we’ll cover in the next issue.