Computer graphics display systems are commonly used for displaying graphical representations of objects on a two-dimensional video display screen. Current computer graphics display systems provide highly detailed representations and are used in a variety of applications. A computer graphics display system generally comprises a central processing unit (CPU), system memory, a graphics machine and a video display screen.
In typical computer graphics display systems, an object to be presented on the display screen is broken down into graphics primitives. Primitives are basic components of a graphics display and may include points, lines, vectors and polygons (e.g., triangles and quadrilaterals). Typically, a hardware/software scheme is implemented to render, or draw, the graphics primitives that represent a view of one or more objects being represented on the display screen.
Generally, the primitives of the three-dimensional object to be rendered are defined by the host CPU in terms of primitive data. For example, when the primitive is a triangle, the host computer defines the primitive in terms of the X, Y and Z coordinates of its vertices, the normals of the vertices, N.sub.x, N.sub.y and N.sub.z, and the red, green, blue and alpha (R, G, B and .alpha.) color values of each vertex. Alpha is a transparency value. Additional primitive data may be used in specific applications. Rendering hardware interpolates all of this data (hereinafter referred to as vertex data) to compute the display screen pixels that represent each primitive, and the R, G, B and .alpha. values for each pixel.
The graphics machine generally includes a geometry accelerator, a rasterizer, a frame buffer controller and a frame buffer. The graphics machine may also include texture mapping hardware (not shown). The geometry accelerator receives vertex data from the host CPU that defines the primitives that make up the view to be displayed. The geometry accelerator typically comprises a transform component which receives vertex data from the CPU, a clipping component, an illumination component, and a plane equations component. The transform component performs transformations on the vertex data received from the CPU, such as rotation and translation of the image space defined by vertex data. The clipping component clips the vertex data so that only vertex data relating to primitives that make up the portion of the view that will be seen by the user is kept for further processing. The illumination component calculates the final colors of the vertices of the primitives based on the vertex data and based on lighting conditions. The plane equations component generates floating point equations which define the image space within the vertices. The floating point equations are later converted into fixed point equations and the rasterizer and texture mapping hardware generate the final screen coordinate and color data for each pixel in each primitive.
The operations of the geometry accelerator are computationally very intense. One frame of a three-dimensional (3-D) graphics display may include on the order of hundreds of thousands of primitives. To achieve state-of-the-art performance, the geometry accelerator may be required to perform several hundred million floating point calculations per second. Furthermore, the volume of data transferred between the host computer and the graphics hardware is very large. The data for a single quadrilateral may be on the order of, for example, 56 words of 32 bits each. Additional data transmitted from the host computer to the geometry accelerator includes illumination parameters, clipping parameters and any other parameters needed to generate the graphics display.
One way of improving the throughput of the geometry accelerator is to minimize the overall amount of data that must be processed by it. One way to do this is to minimize redundancy in the data being sent to the geometry accelerator. The illumination component of the geometry accelerator receives red, green, blue and alpha (R, G, B and .alpha.) data, X, Y, and Z data, and N.sub.x, N.sub.y and N.sub.z, data for each primitive received by the geometry accelerator. The X, Y and Z coordinates define the locations of the vertices of the primitives on the display screen whereas the N.sub.x, N.sub.y and N.sub.z, data define the directions of the normals of the vertices of the primitives. The illumination component also receives light material parameters and light source parameters. The material parameters specify the material of which the model is comprised. The light source parameters specify the location of the light source in 3-D space with respect to the model and the direction of the light. The illumination component processes all this data and outputs new R, G and B data for each vertex.
Some computer graphics display systems are capable of supporting two-sided lighting. In order to support two-sided lighting of models being displayed, the illumination component in such a system receives two sets of material parameters, one for the front-facing primitives and one for the back-facing primitives. Generally, each set of material parameters includes parameters which describe how the material reflects ambient light, diffuse light and specular light, as well as how the material emits light. Currently, the architecture of computer graphics display systems is such that whenever the primitive being received by the illumination component is facing in a different direction from the previous primitive, a new set of material parameters is sent to the illumination component, along with the R, G, B and .alpha. data, the X, Y, and Z data, and the N.sub.x, N.sub.y and N.sub.z data defining the vertices of the primitive. Thus, the more often the direction in which the primitives are facing changes, the more often new sets of material parameters must be sent to the illumination component. This presents a substantial performance penalty which reduces throughput of the geometry accelerator and of the computer graphics display system as a whole.
In some systems which support two-sided lighting, the determination as to which direction the polygon is facing is made in the graphics hardware. This is generally the case in more recent computer graphics display systems. In other systems which support two-sided lighting this determination is made by the Application Program Interface (API) which is the software interface between the host CPU and the graphics hardware. This is generally the case with older systems. It is also known to allow the user to specify which direction the polygons are facing. With respect to systems which make the determination as to polygon direction in the graphics hardware, these systems generally do not support older APIs which make the determination as to polygon direction in the API software.
Accordingly, a need exists for a method and apparatus which maximizes the processing speed and efficiency of the geometry accelerator by reducing the amount of data being sent to it to provide a geometry accelerator with increased throughput while providing support for many different APIs.