Rasterization
Frame Buffer
When browsing through all those 3D graphics FAQ and articles, no doubt you will come across this term – frame buffer. Simply put, a frame buffer is a buffer or container that holds frame(s) or images, usually from a series of images (animation). These images may be pre-rendered as in the case of video or still images or processed in real time such as is the case with real time 3D graphics. Quite literally, think of the frame buffer as your PC's screen.The screen resolution and color depth you're using will determine how big the frame buffer is going to be. A resolution of 1024 x 768, 32 bit color takes about 3 MBs (1024 x 768 x 4 RGBA channels x 8 bits). Using larger resolutions will require more memory – a 1600 x 1200 resolution at 32 bit color requires around 7.2 MBs. Each pixel in the frame buffer is drawn one at a time, or more accurately per line (there are 768 lines in our example). To provide the illusion of moving images or seamless animation, the graphics hardware and your PC must produce a series of images, at least 25 or 30 of them each second. This series of images seem to blend together to our eyes at that rate. As you can see, this means lots of work – the computer must provide at least 47 million pixels every second for a 1024 x 768, 32 bit color, 30 fps animation.
Since we're talking about real time 3D graphics, we're talking about graphics we're seeing on the screen. And when we're talking about the screen, we also must consider the physical aspects of a monitor. If you recall, monitors refresh the screen several times per second - at least at a rate of 60 Hz, sometimes more. In 3D graphics, this means we're targeting 60 frames per second. There will be times our graphics hardware can draw faster or slower than 60 Hz or 60 fps. If we're rendering the images faster than the monitor can display them, sometimes it will draw the new image even if the old one isn't completely done. This produces an artifact called 'tearing'. To avoid it, you could either render slower (which we don't want) or use higher refresh rates – we want the refresh rate and the frame rate per second kept in sync. Vertical sync (v-sync) opts for the first option, telling your graphics hardware to discard images or not to render faster than the current refresh rate of your monitor. That's why when people turned off v-sync when conducting test and benchmarks. This assures the graphics card can render as fast as it can.
While v-sync may help maintain a much more smooth frame rate and avoid 'tearing', using vertical sync alone won't stop 'jerkiness' from happening due to fluctuations in frame rate. Just look at this example: the screen is being refreshed at 75 Hz and our graphics card and processor are rendering between 50 to 100 fps. There's at least a 25 fps difference between what we're seeing and what the computer 'sees'. If there's a sudden drop or rise in fps, we might still be seeing 'old' images that's in queue to the frame buffer although the computer is already rendering another scene. To catch up, the software may choose to 'skip' some images. Our eyes notice the absence of those frames and interprets the the not-so-smooth transition between frames as jerkiness. Then there's the problem of 'locking' the frame buffer. An application may told the graphics card that it has 'lock' the frame buffer to draw an image. When this happens, the graphics card must wait until the frame buffer is unlocked – that's a waste of processing power!
To fix this, graphics hardware use more than just one main frame buffer. By using a copy of the buffer with double and triple buffering, the graphics hardware can fill these buffer copies first, regardless of what's inside the actual frame buffer (the final image you see on the screen). The graphics card simply transfers the content from the buffer to the actual frame buffer. For triple buffering, the graphics hardware merely 'switch' between two copies instead of using just one. So, regardless of drastic fluctuations, the frame buffers will always be filled with a steady, constant supply of images.
Using double and triple buffering is not without a price – mainly memory, because the graphics hardware must set aside memory to hold these buffers. These memory can be used to hold other information we need. So, not surprisingly graphics cards only use double buffering by default.
Depth Buffer
One of most important buffers used in 3D graphics is the depth or Z buffer. If you recall part 1, we use Z value to store just how far a vertex or an object is to the camera. Each time the graphics hardware renders a pixel, it stores the Z value of that pixel in the depth buffer. If there's another object in front of the object being drawn, it will do a second pass on that pixel. The hardware will then compare the Z value of both objects to decide which one should be drawn – naturally the closest to the viewer. A closer or smaller Z value means that particular object is nearer or in front of the other one. Now, this is done for every pixel and the screen – that means we have to set aside memory for the depth buffer about the same size as the frame buffer. There will be a difference in the range of numbers we store for each pixel – we can either use 16 bit or 24 bit. Why choose a higher bit? Well, remember that we're representing depth (distance) here along with perspective correction. We have to be accurate, or else objects may render in the wrong place and all kinds of bad things can happen. 16 bit numbers takes less memory but 24 bit numbers are far, more accurate. Hardware nowadays feature Z compression, so even a 24 bit depth buffer don't take as much space as they use to.
While the depth buffer is very simple to implement, it has one major flaw: its not efficient in scenes with very high overdraw where there are lots of objects overlapping each other – we might be filling the same pixels over and over. That processing power for our overlapping pixel can and should be used where it counts, the pixels that don't overlap. Hardware manufacturers have implemented techniques to minimize overdraw such as hierarchical Z and of course, Z compression. While they won't give us 100 % efficiency, they're generally quite effective in minimizing overdraw (around 90 to 95 %). These features kept any performance loss from processing overlapping pixels to a minimum.
Texture Buffer
Since most PC games uses textures, all 3D consumer graphics hardware not only feature a frame and depth buffer, it also use a texture buffer (quite extensively). Just like the name implied, a texture buffer holds all texture data. Early graphics hardware with very limited memory only support 8 bit or indexed color textures, but now we're seeing 24 bit (RGB) and 32 bit (RGB with an alpha channel) texture as the norm.Most of the memory available in graphics card today are used as texture buffer. To save space and bandwidth, we could compress all of these textures. Indeed, texture compression is widely used now. There are several compression scheme and methods, with each providing us with different compression ratios, but they basically use the same technique – pack the data more efficiently and lose the bits most likely never seen by our eyes.
With texture compression, we can make textures take less space or we can choose to maintain space and go for a more detailed, higher resolution texture. Unlike ordinary image compression such as JPEG and GIF, texture compression can't be too liberal, otherwise we're going to notice compression artifacts in our textures. They still have to retain much of the data since they're also going to be filtered or blended with other textures. In most cases, a compression ration of 4:1 is good enough.
Stencil Buffer
Perhaps the easiest way to explain this feature is with an analogy. Think of the stencil buffer as a placeholder to do very specific things – a 'quick and dirty sketch' if you will. A graphics programmer can use the stencil buffer to do some additional processing for some effects. One such use will be rendering a shadow – its really nothing else but an outline of an object seen from the direction of the shadow casting light. The graphics programmer can tell the graphics card to render the scene from that vantage point into the stencil buffer, filling it with information that indicate which part of the scene is inside the outline (effectively what's inside the shadows). This information is then used to render the shadows from the viewer's perspective (transforming the light coordinates into camera coordinates) Shadows are generally not colored – they come in shades from fully dark to fully lit. Using an 8 bit stencil buffer is enough to provide 255 levels of shadow.[Previous Page]
[Go to top]
[Next Page]