are essential to a useful game engine. Traditionally, these have been done with sprites,but when we set out 1.0 build Quake, we knew that it was time to move on to polygonbased<strong>models</strong>. (In the case of Quake, the <strong>models</strong> are composed of <strong>triangle</strong>s.) Wedidn’t know exactly how we were going to make the drawing of these <strong>models</strong> fastenough, though, <strong>and</strong> went through quite a bit of experimentation <strong>and</strong> learning inthe process of doing so. For the rest of this chapter 1’11 discuss some interestingaspects of our <strong>triangle</strong>-model architecture, <strong>and</strong> present code for useful one approachfor the rapid drawing of <strong>triangle</strong> <strong>models</strong>.Drawing Triangle Models fastWe would have liked one rendering model, <strong>and</strong> hence one graphics pipeline, for alldrawing in Quake; this would have simplified the code <strong>and</strong> tools, <strong>and</strong> would havemade it much easier to focus our optimization efforts. However, when we tried addingpolygon <strong>models</strong> to Quake’s global edge table, edge processing slowed down unacceptably.This isn’t that surprising, because the edge table was designed to h<strong>and</strong>le 200 to 300large polygons, not the 2,000 to 3,000 tiny <strong>triangle</strong>s that a dozen <strong>triangle</strong> <strong>models</strong> ina scene can add. Restructuring the edge list to use trees rather than linked lists wouldhave helped with the larger data sets, but the basic problem is that the edge tablerequires a considerable amount of overhead per edge per scan line, <strong>and</strong> <strong>triangle</strong><strong>models</strong> have too few pixels per edge to justify that overhead. Also, the much largeredge table generated by adding <strong>triangle</strong> <strong>models</strong> doesn’t fit well in the CPU cache.Consequently, we implemented a separate drawing pipeline for <strong>triangle</strong> <strong>models</strong>, asshown in Figure 69.1. Unlike the world pipeline, the <strong>triangle</strong>-model pipeline is inmost respects a traditional one, with a few exceptions, noted below. The entire worldis drawn first, <strong>and</strong> then the <strong>triangle</strong> <strong>models</strong> are drawn, using z-buffering for propervisibility. For each <strong>triangle</strong> model, all vertices are transformed <strong>and</strong> projected first,<strong>and</strong> then each <strong>triangle</strong> is drawn separately.Triangle <strong>models</strong> are stored quite differently from the world itself. Each model consistsof front <strong>and</strong> back skins stretched around a <strong>triangle</strong> mesh, <strong>and</strong> contains a full setof vertex coordinates for each animation frame, so animation is performed by simplyusing the correct set of coordinates for the desired frame. No interpolation,morphing, or other runtime vertex calculations are performed.Early on, we decided to allow lower drawing quality for <strong>triangle</strong> <strong>models</strong> than for theworld, in the interests of speed. For example, the <strong>triangle</strong>s in the <strong>models</strong> are small,<strong>and</strong> usually distant-<strong>and</strong> generally part of a quickly moving monster that’s trying itsbest to do you in-so the quality benefits of perspective texture mapping would addlittle value. Consequently, we chose to draw the <strong>triangle</strong>s with affine texture mapping,avoiding the work required for perspective. Mind you, the <strong>models</strong> areperspective-correct at the vertices; it’s just the pixels between the vertices that sufferslight warping.Surface Caching <strong>and</strong> Quake’s Triangle Models 1263
Quake 5 <strong>triangle</strong>-modelFigure 69.1drawing pipeline.1264 Chapter 69