Calculating Colour

Once an imaginary world has been described, and the renderer has determined which elements are currently visible, it must then decide how to display these visible elements - what colours to apply and where. To understand how BRender handles colour, let's start by briefly considering how monitors display colour.

Colour and the CRT

The inside of the glass screen on a colour monitor is covered with closely packed groups of red, green and blue phosphor dots. These phosphor dots emit red, green and blue light, respectively. Each group of dots is so small that light emanating from them is perceived by the viewer as a single colour.

Figure 19 CRT screen

Three electron guns rapidly scan the screen from top to bottom, one line at a time. As each pixel is addressed, the intensities of the electron beams fired from the red, green and blue electron guns are varied to reflect the amount of red, green and blue light in that pixel's colour. In this way a picture is drawn on the screen. The entire screen is scanned many (typically 60 or more) times a second - too fast for the human eye to detect any movement. The viewer sees a constant unflickering picture (the same principle is at work in the cinema, where movie frames projected at 24 frames per second are blended together into a smooth sequence inside the viewer's brain).

The electron guns get their colour information, via a video signal, from a screen buffer. The screen buffer, also known as the frame buffer, is an area of memory mapped directly to the screen.

Figure 20 Screen buffer mapped to screen

Dedicated circuitry, known as the Video Controller, interprets the contents of the screen buffer, pixel by pixel, and automatically updates the screen. The renderer is responsible for updating the screen buffer. These operations are transparent to the programmer, who writes an application describing a scene and expects an accurate representation of this scene to be displayed on the screen.

The screen buffer `depth' (or the number of bitplanes - a bitplane contains one bit of data for each pixel) determines how many colours can be displayed. In a 3bit screen buffer, for example, a single bit is available for each of the r, g and b (red, green and blue) components. Each is either fully ON or OFF. A total of eight colours are available to choose from (000 to 111).

Figure 21 A 3-bit screen buffer contains three bit-planes

The number of colours that can be displayed may be changed by using a colour lookup table (or CLUT). The values stored in the frame buffer no longer generate colours directly, but are used to point to, or index, locations in the CLUT. A typical CLUT may store each colour as a 15-bit number, 5 bits for each r,g,b component.

Figure 22 3-bit indexed mode

Note that the number of colours available at any one time does not change. In the 3-bit system depicted in Figure 22, there are still only 8 colours to choose from at any one time. However, the CLUT may contain any 8 colours from a total of 215 (or 32,768). A selection of colours, or a colour palette, must be loaded into the CLUT before rendering begins. In indexed colour mode, one or more colours in a given image can be changed simply by loading a different colour palette. This is a potentially powerful feature. Colour manipulation and animation effects can be implemented using a fraction of the computational power that would be needed to achieve the same results by updating the stored image.

BRender colour modes include 8-bit indexed colour, and 15- and 24-bit non-indexed or true colour.

Figure 23 8-bit indexed mode

A total of 256 (28 ) colours are available at any one time in 8-bit indexed mode. In 15-bit true-colour mode, there are 32,768 (215) colours to choose from. In 24-bit mode 224 (@16.7 million) different colours are available.

Figure 24 (a) 15-bit true colour

Figure 24 (b) 24-bit true colour

Indexed colour is more complex to work with than true colour. A colour palette must be set up and loaded before rendering begins. It must be sufficiently general to be useful, yet satisfy light intensity requirements. Faces on a model should appear lighter or darker according to their orientation with respect to the light source/s. In order to simulate realistic lighting conditions, various shades (from light to dark) of each colour in a scene should be available from the colour palette. In practice, the palette may be divided into a number of strips, or ramps. Each strip consists of a variety of shades of a single colour, ranging from very light to very dark. The palette must also be capable of displaying acceptable approximations of texture maps that may have been created using a completely different palette. For a more detailed discussion of indexed colour and texture mapping, see Chapters 6 to 8.

Video Modes

A variety of user-selectable video modes are usually available on a particular platform. Most systems support 8-bit indexed colour along with a variety of true-colour modes. The screen resolutions available will depend, in part, on the size of the video memory. By changing the video mode you can alter the screen resolution, as well as the number of colours available. Commonly used PC screen resolutions, for example, include the 320 200 and 640 480 VGA standards, 1024 768 and 1280 1024 SVGA standards and the intermediate 800 600. If you don't know which video modes are available to you, run the appropriate BRender hardware interrogation utility (if available on your platform - refer to your installation guide). For BRender x86, for instance, this is VESAQ.EXE, located in the Tools directory. VESAQ.EXE interrogates your video circuitry before displaying a list of the video modes supported by your system.

Note that the task of making BRender output visible to the user belongs to the application. BRender provides assistance whenever possible.

When you write a BRender program, you must select a video mode. This is discussed in detail in Chapter 2, where your first BRender program is introduced. In general, the lower the screen resolution, the faster your program will run (since there are fewer pixel values to calculate). Of course your images will lose sharpness at lower resolutions. In 3D computer graphics there is always a trade-off between speed and image quality. Since speed is a crucial factor in real time animation, you will probably want to work with low screen resolutions, certainly during the initial development stage (of course a higher, slower resolution may prove more useful for some applications). Most of the animations included on the Tutorial Programs disk are displayed using the lowest available screen resolution.

Double Buffering

As noted above, the Video Controller repeatedly scans the screen buffer, refreshing the screen as it does so. In effect, the contents of the screen buffer are permanently displayed.

Now consider what the viewer would see if scenes were rendered directly into the screen buffer. Since the screen buffer is mapped directly to the screen, the frame construction process would be visible and the viewer would be aware of discontinuities in rapidly changing scenes.

A simple solution is to use two buffers. The renderer constructs a scene in a back buffer while the screen, or front, buffer is being displayed. When the scene in the back buffer is complete and it is time to display it, the application `swaps' the buffers so that the back buffer becomes the screen buffer. The next frame is then constructed in the new back buffer (the old screen buffer).

Some systems come with two hardware screen buffers, so that back and front buffers are literally swapped as described above. Where only a single screen buffer exists in hardware, BRender sets up a back buffer in memory. When it is time to display a newly constructed scene, BRender copies the contents of the back buffer into the screen buffer.

How double buffering is implemented is transparent to the applications programmer, who simply calls BRender's double buffering function at the appropriate point in the program.

More about Hidden-Surface Removal

Figure 25 illustrates the importance of hidden surface removal. Figure 25(a) looks correct. But what about Figure 25(b). This is what would be displayed if the model nearest the viewer were rendered into the screen buffer first.

Figure 25 (a) Fence rendered first

Figure 25 (b) House rendered first

The Z-Buffer Renderer

The Z- or depth buffer is an effective hidden-surface removal algorithm. Remember that colour information for each pixel is initially written to the back buffer. A depth buffer with the same number of entries is used to store a z, or depth, value for each pixel. The depth buffer is initialised to a large number beyond the visible range (e.g. FFFF for a 16-bit buffer). You could think of this value as the z-position of the background.

Each potentially visible surface is rendered in turn, in an arbitrary order. The magnitude of the z-component of each visible point on a surface is compared with the relevant value in the Z-Buffer. If it is nearer or as near as the point whose colour and depth are currently in the buffers, then the new point's colour and depth replace the old values. At any time, the Z-Buffer and the back buffer will store the information associated with the lowest (in magnitude) z value encountered thus far. When the back buffer is subsequently swapped with the screen buffer, the colour displayed at any pixel is that of the surface closest to the view position.

Suppose Surface 1 in Figure 26 is rendered first. Since 10, the magnitude of its z-component, is less than the z-component of the background (assumed to be initialised to FFFF), the colour and depth information associated with Surface 1 are copied to the buffers.

Figure 26 Surface 1 rendered first - since |-10| < |FFFF|, pixel colour is red

If Surface 2 is then rendered, its associated depth and colour information will replace those of Surface 1, since it is closer to the view position (5<10).

Figure 27 Surface 2 rendered next - since |-5| < |-10|, final pixel colour is blue

For each pixel the z-value of the closest surface so far considered will be stored in the depth-buffer and the colour value for this surface stored in the back buffer.

The applications programmer is responsible for setting up and initialising the depth buffer (in addition to the screen and back buffers) using BRender functions.

The Z-Buffer is a fast, high quality renderer. However, it requires a considerable amount of memory.

The Z-Sort Renderer

The Z-Sort renderer attempts to achieve hidden surface removal by sorting surfaces according to their distance from the view position, and then drawing them from back to front.

The Z-Sort is a fast renderer that requires relatively little memory (particularly for simple scenes). Hidden Surface Removal schemes are discussed in greater detail in your technical reference manual.

Generated with CERN WebMaker