Extra Tasks of Geometry Processing
One measure of how fast a graphics card can do geometry processing is the amount of vertices / triangles / polygons it can process per second. The higher the number, the more objects we can have on screen, but we can also have them more detailed. As faster and more powerful hardware become available on the market, the level of detail and the amount of polygon we're seeing in games have been steadily rising. Back in the days of NVIDIA's TNT and 3dfx Voodoo2, the game Quake III Arena uses a model with 750 polygons, quite detailed for that time. Compared that to Doom 3, which uses 5000 polygons per character in average. Of course, you need to consider the polygons of all the objects and the whole 'map' or 'level' itself – this can reach around 40.000 to 60.000 polygons. Even the fastest processors today will slow to crawl with a model that size if all geometry processing is done in software by the processor.
However, geometry processing is not just about transformation and matrix operations. One of the possibilities made possible by faster hardware are curves. Rather than using lots of edges to approximate a curve, we can actually send the mathematical equation of a curve to the geometry units in the graphics hardware. Not only can we use this to draw perfect curves (or splines), but also polygons using curves as its edges – usually called N-patches (or higher order surfaces). With this method, we don't have to use as many vertices and polygons which means less memory usage for our 3D model. Remember, each vertex are defined with at least three 32 bit value (at least 12 bytes of data per vertex). The more we use vertices, the more memory we have to set aside for that model. Take for example our average Doom 3 model: assuming a polygon has 4 vertices, the memory usage for one model will be around 5000 polygons x 4 vertices x 12 bytes = 235 KBytes! (the actual figure can be lower, since polygons share at least two vertex with another). Think that's small? Not if you have to set aside that much memory for every frame per animation, which can range to 50 to 150 frames for all range of movement the model has!
Even if the graphics hardware prefer to natively work with straight edges and triangles, they can implement a dynamic level of detail for approximating curves: using more detail when the object is near the camera and less detail when its away. As you can see, curves does require significant calculation. Instead of just two vectors or vertices, we need four (the additional two to control the angle of the curve). An interpolation of the two additional vectors is needed for each part of the curve. Higher order surfaces is not widely used today because of the performance penalty and most graphics card in the market doesn't have the necessary processing power, but with faster hardware this will definitely improve in the future.
Another use of geometry processing power in graphics hardware today is lighting. Remember what we talked about in part 1, about lighting, shading and vertex shaders? Newer graphics hardware can provide very acceptable per pixel shading with very fast frame rates. The actual per color per pixel calculation will be done in the rasterization stage, but the much needed ground work such as cross product calculation, which provide us with the normals of a triangle or polygon and dot product calculation, which provides the light intensity for each pixel by calculating the incidence of light and normals at every pixel, can now be done in hardware. Of course, with very detailed world and models, we still need very fast hardware since we need to do this with every light in the scene, for every model.
As a reminder, here is the mathematical expression for computing both diffuse and specular reflection. Where the diffuse model is stated as Light Intensity * Proportion of Diffuse Light Reflected * (Light vector * Normal Vector). the specular model is defined as 2 (Normal Vector * Light Vector) ( Normal Vector * Viewer Vector) - (Viewer Vector . Light Vector). The two can be combined to get the complete reflection model which will be stated as Intensity (on surface) = Light Intensity * Proportion of Light Reflected + [Diffuse Model + Specular Model^g]. The dot product is defined as A * B = (Xa.Xb + Ya.Yb + Za.Zb). As for the cross product, its defined as A * B = C.
In general, graphics programmers still relies on a combination of both dynamic lighting and offline pre-rendered lights in their game engines. If you played Doom 3 without shadows, you'll notice that while moving objects don't cast realistic shadows anymore, much of the shadows cast from lights that don't change (the lights can't be turned on / off or they don't move) on every other objects are still present. These are essentially 'free' since they're 'built' into the textures.
All of this are done by the geometry processing unit of the chip. Since the resources and the performance are not infinite, graphics programmers must balance them all. For example, if a game doesn't use lots of dynamic lights, it will be more appropriate to use the geometry power for models and levels with more polygons and details. Bigger levels with low detail models might also be a possibility, using detailed shaders to 'hide' the lack of details. So, with newer games relying more and more on both pixel and vertex shaders, the number of vertices and pixels per second that can be processed by graphics hardware becomes less of a concern. Its a matter of how flexible and how capable they are.
Geometry Performance Considerations
Just like your processor, your ordinary graphics chips uses geometry or vertex units in the graphics chip for geometry processing. The amount of units of course determines how many vertices can be processed per cycle. Remember, these units must operate on at least four 32 bit floating point values, since we use 32 bit values for each axis to define the vertex's position. Some of you might notice something strange here – since we're only using three axis, what's the deal with the fourth value? Well, you're right, we only need three values as coordinates. But remember, we're drawing a 3D scene into a 2D screen, this means we need an additional variable (look back at the matrix definitions).
With a single geometry (or vertex) unit, we can process a vertex per cycle. The smallest unit in any 3D model is a polygon with four vertices or triangle with three vertices (a polygon can be thought of as two triangles sharing two vertices), it makes sense to use at least three geometry units. With four geometry units, we can process four vertices or two triangles or one polygon. Let's go back to the GeForce 6800 – it has six vertex units. This means we get six vertices or four triangles per cycle (assuming some of the triangles share vertices). Since the GeForce 6800 runs at 400 MHz this should give us about 2,4 billion vertices per second. If you read the official specs, you'll notice that NVIDIA only admits 600 million vertices per second. Is something wrong here? Well, that's 600 million 'lit' vertices per second, since it factors in the additional computation for lighting. With the same formula, we could see that the GeForce 6600 has only three vertex units (3 vertex units x 500 MHz / 4). This means the GeForce 6600 has less geometry processing power than the GeForce 6800, but it really doesn't matter much anyway. It's been a known fact that consumer 3D graphics hardware is more focused at pixel processing that vertex processing. Games will most likely not reach that high amount of polygons in a single level. For one, developers made their software so that it can ran well on a typical computer, which uses off the shelf consumer 3D graphics hardware (and not professional graphics hardware that emphasizes geometry processing). Second, the levels of geometry processing varies quite a lot between one card and another. Some users will have the best, high end hardware (like the GeForce 6800) while most will likely use more affordable, mainstream solutions (like the GeForce 6600). And again, the lack of detail from less polygon can be hidden by a good shader. Take a look at Doom 3, you'll probably see some blockiness on the models, although they're pretty detailed. This is because they're not using higher order surfaces or lots of polygons to approximate a curve.
[Previous Page]
[Go to top]
[Next Page]