Infinite Light Sources

Infinite lights are the first of the two types of lights available for use with the lightingmodel.  These lights are assumed to be infinitely far away from the surface they are
illuminating; thus, light "rays" from these sources are assumed to arrive parallel to all
the surfaces affected.

Local Light Sources

Local light sources, on the other hand, are relatively close to the surface(s) they are
illuminating; thus, the angle between the light source and the normals of the various
affected surfaces can change dramatically from one surface to the next.  A total of eight
independent light sources may be used concurrently.

Since the angles from the Surface normals to the light source must be computed every
frame for each surface, local lights are far more computationally expensive than
infinite lights and should be used judiciously in real-time applications.

5.6.5 Transparency
In addition to the standard three color components, RGB, associated with each vertex
being rendered is an Alpha component.  Like the color components, Alpha may use
either 8- or 12-bit component values, but the choice of component size must correlate
to the same choice for the RGB values in such a way that the RGBA component blocks
can be treated as a set of 32 or 48 bits.

The Alpha value is used to compute coverage so that transparent objects of differing
transparency/translucency can be rendered in front of one another and allow one to
be seen through the other.  To insure that transparency is computed correctly and
predictably, it is best to sort transparent objects from front to back with respect to the
eyepoint of the scene being rendered, then draw these objects after all the non-
transparent objects have been rendered.

5.6.6 Hidden Surface Removal

As in all current Silicon Graphics systems across the product line, hidden surface
removal is accomplished with a Z-buffer technique.  The Z-buffer provides high-
quality hidden surface removal during rendering without the need to sort the
polygons being rendered.  This process can be performed with little or no necessary
programming considerations in the application software that traverses and renders
the database.

RealityEngine again sets a new standard by offering a 32-bit Z-buffer rather than the
previous Z-buffer standard of 24-bits.  The Z-buffer exists as dedicated memory in the
frame buffer associated with each pixel.  The first time a pixel is drawn, the Z-buffer
value for that pixel is set to the iterated Z value of the pixel being drawn.  Each time a
subsequent attempt is made to set the color of that pixel due to a new polygon
covering it, the system checks to see if the Z-buffer value for that pixel is farther or
closer than the Z value of the pixel being drawn.  If the new pixel is closer, its color
value replaces that of the previous value in the image buffer, and the Z-buffer is set to
the new depth.