Multiple draw buffers are typically useful when generating an image and auxiliary data, multiple versions of an image, or multiple computed results from a fragment program being used for general-purpose computation.

Normally, a fragment program will generate a single output color, result.color, which is written to the color buffer defined by glDrawBuffer(). When a fragment program specifies the option “ATI_draw_buffers”, an implementation-dependent number of output colors, named result.color[n], may be generated, where n ranges from 0 up to the number of draw buffers minus one. The number of draw buffers supported is implementation-dependent, and may be queried by calling glGetIntegerv() with the parameter GL_MAX_DRAW_BUFFERS_ATI. Typically, at least four draw buffers are supported by this extension.

To define the color buffers to which multiple output colors are written, make the following call:

void glDrawBuffersATI(GLsizei n, const GLenum *bufs);

The parameter n specifies the number of buffers in bufs and bufs is a pointer to an array of symbolic constants specifying the buffer to which each output color is written. The constants may be one of the following:

The draw buffers being defined correspond in order to the respective output colors. The draw buffer for output colors beyond n is set to GL_NONE.

The constants GL_FRONT, GL_BACK, GL_LEFT, GL_RIGHT, and GL_FRONT_AND_BACK, which may refer to multiple color buffers, are not valid elements of bufs, and their use will generate a GL_INVALID_OPERATION error.

If the “ATI_draw_buffers” fragment program option is not used by a fragment program or if fixed-function fragment processing is being used, then glDrawBuffersATI() specifies a set of draw buffers for the writing of the output color 0 or the output color from fixed-function fragment processing.

The draw buffer corresponding to output color i may be queried by calling glGetIntegerv() with the parameter GL_DRAW_BUFFERi_ATI.

The ATI_draw_buffers extension introduces the function glDrawBuffersATI().

When performing stencil buffer computations which differ for fragments generated by front-facing and back-facing primitives, applications typically must render geometry twice. They use face culling to discard front-facing primitives with one pass and back-facing primitives on the second and change stencil buffer settings prior to each pass. A common example is stencil shadow volumes, where the stencil buffer is to be incremented for front-facing fragments and decremented for back-facing fragments.

By using independent stencil tests and operations depending on fragment orientation, such computations can be performed in a single pass, which may significantly increase performance for geometry-limited applications.

To set the stencil function separately for front-facing and back-facing fragments, make the following call:

void glStencilFuncSeparateATI(GLenum frontfunc, GLenum backfunc, GLint ref,
                              GLuint mask);

The parameters frontfunc and backfunc respectively specify the stencil test function used for front-facing and back-facing fragments. The values accepted are the same as for glStencilFunc(), and the initial value of each function is GL_ALWAYS.

The parmater ref specifies the reference value used for both front-facing and back-facing fragments. It is clamped to the range [0, pow(2,s) – 1], where s is the number of bits in the stencil buffer.

The s least significant bits of the mask value are bitwise ANDed with ref and then with the stored stencil value, and the resulting masked value is used in the comparison controlled by {\em func}.

To set the stencil operation separately for front-facing and back-facing fragments, make the following call:

void glStencilOpSeparateATI(GLenum face, GLenum fail, GLenum zfail,
                            GLenum   zpass);

The parameter face specifies the orientation for the stencil operation and must be GL_FRONT, GL_BACK, or GL_FRONT_AND_BACK to set both stencil operations to the same values.

The parameters fail, zfail, and zpass respectively specify the operations to perform when the stencil test fails, stencil test passes but depth test fails, and stencil and depth tests both pass. The values accepted are the same as for glStencilOp().

Use the core OpenGL tokens to query for the front-facing stencil state. To query for the back-facing stencil state, call glGetIntegerv() with the following tokens:

The ATI_separate_stencil extension introduces the following functions:

When rendering effects such as particle systems, applications often want to draw a small texture (such as a shaded sphere) to represent each particle rather than the set of uniformly shaded fragments normally generated by a GL_POINTS primitive. This can easily be done by rendering a GL_QUADS primitive for each point but at the cost of quadrupling the amount of geometry transferred to the graphics pipeline for each point and of performing additional work to compute the location of each vertex of the quad. Since particle systems typically involves thousands or tens of thousands of particles, this can translate to a large geometry load.

Point sprites allow producing these effects using point primitives instead of quads. Each texture unit can be modified to replace the single S and T texture coordinate for each fragment generated by a point with S and T point sprite coordinates, which are interpolated across the fragments generated by a point. Finally, a global parameter controls the R texture coordinate for point sprites to allow applications to animate slices of a single 3D texture during the lifetime of a point. For example, it allows an application to represent a particle that glows and then fades.

Point sprites are enabled by calling glEnable(GL_POINT_SPRITE_NV). When point sprites are enabled, the state of point antialiasing is ignored so that fragments are generated for the entire viewport square occupied by the point instead of just fragments in a circle filling that viewport square.

When point sprites are enabled, each texture unit may independently determine whether or not the single point texture coordinate is replaced by point sprite texture coordinates by making the following call:

glTexEnvi(GL_POINT_SPRITE_NV, GL_COORD_REPLACE_NV, flag);

The active texture unit will generate point sprite coordinates if flag is GL_TRUE or will use the point texture coordinate if flag is GL_FALSE.

The point sprite texture coordinates generated for fragments by a point will be the following:

s = 1/2 + ((xf - xw + 1/2) / size)
t = 1/2 + ((yf - yw + 1/2) / size)

The variable items are defined as follows:

When 3D texturing is enabled, the R value generated for point sprite coordinates is determined by making the following call:

glPointParameteriNV(GL_POINT_SPRITE_R_MODE_NV, GLint param);

The following are possible values of param:

Occlusion queries are primarily used to help applications avoid rendering objects that are completely occluded (blocked from visibility) by other objects closer to the viewer. This can result in a significantly reduced geometry load.

Typically, this test consists of the following steps:

If the number of pixels that passed the depth test is zero, then the objects represented by this bounding box are completely occluded and do not need to be drawn. Otherwise, at least some of the objects within the bounding box may be visible and can either be drawn or finer-detailed occlusion queries can be performed on smaller components of the objects. In addition, if the number of pixels is small relative to the size of the bounding box, it may be possible to represent the objects with lower-detailed models.

Some other possible uses for occlusion queries include depth peeling techniques like as order-independent transparency, where an application can stop rendering when further layers will be invisible, and as a replacement for glReadPixels() when performing operations like reading the depth buffer to determine fractional visibility of a light source for lens flare or halo effects.

Use occlusion queries with care, however. Naive use of a query may stall the graphics pipeline and CPU while waiting for query results. To avoid this problem, NV_occlusion_query supports a simple test for the availability of query results. If the query results are not available, the application can do other drawing or compute tasks while waiting for the results to become available.

In addition, the expense of rendering bounding boxes for an occlusion test, while typically small compared to the expense of rendering the objects themselves, can become significant if done too finely (for example, rendering bounding boxes for small objects) or if done frequently when it is unlikely that the bounding boxes will actually be occluded.

Occlusion queries depend on occlusion query objects. As shown in the following code, these objects are represented by object names (of type GLuint), which are managed in exactly the same fashion as texture and display list names—that is, with routines for allocating unused query names, deleting query names, and testing if a name is a valid occlusion query:

void glGenOcclusionQueriesNV(GLsizei n, GLuint *ids);
void glDeleteOcclusionQueriesNV(GLsizei n, const GLuint *ids);
GLboolean glIsOcclusionQueryNV(GLuint id);

Occlusion query objects contain a pixel counter, which is initially set to zero. The size (in bits) of this counter is the same for all queries and may be determined by calling glGetIntegerv() with parameter GL_PIXEL_COUNTER_BITS_NV. An occlusion query counter is guaranteed to contain at least 24 bits, supporting pixels counts of at least 16777215, but it may be larger.

To perform occlusion queries, first acquire an unused query name using glGenOcclusionQueriesNV(). Begin the query by making the following call:

void glBeginOcclusionQueryNV(GLuint id);

The parameter id specifies the name of the query to be created. Then render the geometry to be queried. Whenever a fragment being rendered passes the depth test while an occlusion query is being performed, the pixel counter is incremented by one. In a multisampling situation, the pixel counter is incremented once for each sample whose coverage bit in the fragment is set.

Typically, when rendering bounding boxes for an occlusion test, the color and depth masks are set to GL_FALSE so that the bounding boxes themselves are not drawn to the framebuffer.

To end an occlusion query, make the following call:

void glEndOcclusionQueryNV(void);

To retrieve the count of pixels that passed the occlusion query, make the following call:

void glGetOcclusionQueryuivNV(GLuint id, GLenum pname, GLuint *params);

Set the parameter pname to GL_PIXEL_COUNT_NV. The count is returned in the variable pointed to by params. However, as noted earlier, calling glGetOcclusionQueryNV() immediately after ending a query may cause the graphics pipeline to stall.

To avoid stalling, first determine whether the query count is available by calling glGetOcclusionQueryuiNV() with a pname of GL_PIXEL_COUNT_AVAILABLE_NV. If the value returned in params is GL_TRUE, then the count is available, and a query of GL_PIXEL_COUNT_NV may be performed without stalling. Otherwise, the application may perform additional work unrelated to the occlusion query and test periodically for the result. Note that the first call to determine GL_PIXEL_COUNT_AVAILABLE_NV for a query should be preceded by glFlush() to ensure that the glEndOcclusionQueryNV() operation for that query has reached the graphics pipeline. Otherwise, it is possible to spin indefinitely on the query.

Example 9-1 shows a simple use of NV_occlusion_query.

GLuint occlusionQuery[numQuery]; /* names for each query to perform */

glGenOcclusionQueriesNV(numQuery, occlusionQuery);

/* Prior to this point, first render the foreground occluders */
/* Disable color and depth mask writes while rendering bounding boxes */
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);
glDepthMask(GL_FALSE);
/* Also disable texturing, fragment shaders, and any other
 * unneccessary functionality, since nothing will actually be
 * written to the screen.
 */

/* Now loop over numQuery objects, performing an occlusion query for each */
for (i = 0; i < numQuery; i++) {
    glBeginOcclusionQueryNV(occlusionQuery[i]);
    /* Render bounding box for object i */
    glEndOcclusionQueryNV();
}

/* Enable color and depth mask writes, and any other state disabled
 * above prior to the occlusion queries
 */
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
glDepthMask(GL_TRUE);

/* If possible, perform other computations or rendering at this
 * point, while waiting for occlusion results to become available.
 */

/* Now obtain pixel counts for each query, and draw objects based
 * on those counts.
 */
for (i = 0; i < numQuery; i++) {
    GLuint pixelCount;

    glGetOcclusionQueryuivNV(occlusionQuery[i], GL_PIXEL_COUNT_NV,
                             &pixelCount);

    if (pixelCount > 0) {
        /* Render geometry for object i here */
    }

The NV_occlusion_query extension introduces the following functions:

The standard blending feature allows you to blend source and destination pixels. The constant color blending extension, EXT_blend_color, enhances this capability by defining a constant color that you can include in blending equations.

Constant color blending allows you to specify input source with constant alpha that is not 1 without actually specifying the alpha for each pixel. Alternatively, when working with visuals that have no alpha, you can use the blend color for constant alpha. This also allows you to modify a whole incoming source by blending with a constant color (which is faster than clearing to that color). In effect, the image looks as if it were viewed through colored glasses.

glBlendFunc(GL_ONE_MINUS_CONSTANT_COLOR_EXT, GL_CONSTANT_COLOR_EXT);
for (alpha = 0.0; alpha <= 1.0; alpha += 1.0/16.0) {
    glClear(GL_COLOR_BUFFER_BIT);
    glDrawPixels(width, height, GL_RGB, GL_UNSIGNED_BYTE, image0);
    glEnable(GL_BLEND);
    glBlendColorEXT(alpha, alpha, alpha, alpha);
    glDrawPixels(width, height, GL_RGB, GL_UNSIGNED_BYTE, image1);
    glDisable(GL_BLEND);
    glXSwapBuffers(display, window);
}

The minmax blending extension, EXT_blend_minmax, extends blending capability by introducing two new equations that produce the minimum or maximum color components of the source and destination colors. Taking the maximum is useful for applications such as maximum intensity projection (MIP) in medical imaging.

This extension also introduces a mechanism for defining alternate blend equations. Note that even if the minmax blending extension is not supported on a given system, that system may still support the logical operation blending extension or the subtract blending extension. When these extensions are supported, the glBlendEquationEXT() function is also supported.

void glBlendEquationEXT(GLenum mode)

The blend subtract extension, EXT_blend_subtract, provides two additional blending equations that can be used by glBlendEquationEXT(). These equations are similar to the default blending equation but produce the difference of its left- and right-hand sides, rather than the sum. See the man page for glBlendEquationEXT() for a detailed description.

Image differences are useful in many image-processing applications; for example, comparing two pictures that may have changed over time.

The following simple example program for the fog function extension can be executed well only on those platforms where the extension is supported (VPro and InfiniteReality systems).

#include <stdio.h>
#include <stdlib.h>
#include <GL/gl.h>
#include <GL/glut.h>

/* Simple demo program for fog-function. Will work only on machines
 * where SGIS_fog_func is supported.
 *
 * Press `f' key to toggle between fog and no fog
 * Pres ESC to quit
 *
 * cc fogfunc.c -o fogfunc -lglut -lGLU -lGL -lXmu -lX11
 */

#define ESC 27

GLint width = 512, height = 512;
GLint dofog = 1;		                          /* fog enabled by default */
GLfloat fogfunc[] = {		                     /* fog-function profile */
  6.0, 1.0,			/* (distance, blend-factor) pairs */
  8.0, 0.5,
  10.0, 0.1,
  12.0, 0.0,
};

void init(void)
{
  GLUquadric *q = gluNewQuadric();
  GLfloat ambient[] = {0.3, 0.3, 0.2, 1.0};
  GLfloat diffuse[] = {0.8, 0.7, 0.8, 1.0};
  GLfloat specular[] = {0.5, 0.7, 0.8, 1.0};
  GLfloat lpos[] = {0.0, 10.0, -20.0, 0.0}; /* infinite light */
  GLfloat diff_mat[] = {0.1, 0.2, 0.5, 1.0};
  GLfloat amb_mat[] = {0.1, 0.2, 0.5, 1.0};
  GLfloat spec_mat[] = {0.9, 0.9, 0.9, 1.0};
  GLfloat shininess_mat[] = {0.8, 0.0};
  GLfloat amb_scene[] = {0.2, 0.2, 0.2, 1.0};
  GLfloat fog_color[] = {0.0, 0.0, 0.0, 1.0};

  glClearColor(0.0, 0.0, 0.0, 1.0);
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();
  glFrustum(-4.0, 4.0, -4.0, 4.0, 4.0, 30.0);

  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity();

  /* Setup lighting */

  glLightfv(GL_LIGHT0, GL_AMBIENT, ambient);
  glLightfv(GL_LIGHT0, GL_SPECULAR, specular);
  glLightfv(GL_LIGHT0, GL_DIFFUSE, diffuse);
  glLightfv(GL_LIGHT0, GL_POSITION, lpos);
  glLightModelfv(GL_LIGHT_MODEL_AMBIENT, amb_scene);
  
  glMaterialfv(GL_FRONT, GL_DIFFUSE, diff_mat);
  glMaterialfv(GL_FRONT, GL_AMBIENT, amb_mat);
  glMaterialfv(GL_FRONT, GL_SPECULAR, spec_mat);
  glMaterialfv(GL_FRONT, GL_SHININESS, shininess_mat);
			    
  glEnable(GL_LIGHT0);
  glEnable(GL_LIGHTING);
  
  /* Setup fog function */
  
  glFogfv(GL_FOG_COLOR, fog_color);
  glFogf(GL_FOG_MODE, GL_FOG_FUNC_SGIS);
  glFogFuncSGIS(4, fogfunc);
  glEnable(GL_FOG);
  
  /* Setup scene */

  glTranslatef(0.0, 0.0, -6.0);
  glRotatef(60.0, 1.0, 0.0, 0.0);

  glNewList(1, GL_COMPILE);
  glPushMatrix();
  glTranslatef(2.0, 0.0, 0.0);
  glColor3f(1.0, 1.0, 1.0);
  gluSphere(q, 1.0, 40, 40);
  glTranslatef(-4.0, 0.0, 0.0);
  gluSphere(q, 1.0, 40, 40);
  glTranslatef(0.0, 0.0, -4.0);
  gluSphere(q, 1.0, 40, 40);
  glTranslatef(4.0, 0.0, 0.0);
  gluSphere(q, 1.0, 40, 40);
  glTranslatef(0.0, 0.0, -4.0);
  gluSphere(q, 1.0, 40, 40);
  glTranslatef(-4.0, 0.0, 0.0);
  gluSphere(q, 1.0, 40, 40);
  glPopMatrix();
  glEndList();
}

void display(void)
{
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
  (dofog) ? glEnable(GL_FOG) : glDisable(GL_FOG);
  glCallList(1);
  glutSwapBuffers();
}

void kbd(unsigned char key, int x, int y)
{
  switch (key) {
  case `f':			                                     /* toggle fog enable */
    dofog = 1 - dofog;
    glutPostRedisplay();
    break;

  case ESC:			/* quit!! */
    exit(0);
  }
}

main(int argc, char *argv[])
{
  glutInit(&argc, argv);
  glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);
  glutInitWindowSize(width, height);
  glutCreateWindow(“Fog Function”);
  glutKeyboardFunc(kbd);
  glutDisplayFunc(display);

  init();
  glutMainLoop();
}

The SGIS_fog_function extension introduces the function glFogFuncSGIS().

Multisampling works by sampling all primitives multiple times at different locations within each pixel; in effect, multisampling collects subpixel information. The result is an image that has fewer aliasing artifacts.

Because each sample includes depth and stencil information, the depth and stencil functions perform equivalently in the single-sample mode. A single pixel can have 4, 8, 16, or even more subsamples, depending on the platform.

When you use multisampling and read back color, you get the resolved color value (that is, the average of the samples). When you read back stencil or depth, you typically get back a single sample value rather than the average. This sample value is typically the one closest to the center of the pixel.

To use multisampling in your application, select a multisampling-capable visual by calling glXChooseVisual() with the following items in attr_list:

Multisampling is enabled by default. To query whether multisampling is enabled, make the following call:

glIsEnabled(MULTISAMPLE_SGIS)

To turn off multisampling, make the following call:

glDisable(MULTISAMPLE_SGIS) 

Advanced multisampling options provide additional rendering capabilities. This section describes the following features:

The following steps, illustrated in Figure 9-1, shows how the subsamples in one pixel are turned on and off.

The two processes—using a multisample mask created by glSampleMaskSGIS() and using the alpha value of the fragment as a mask—can both be used for different effects.

When GL_SAMPLE_ALPHA_TO_MASK_SGIS is enabled, it is usually appropriate to enable GL_SAMPLE_ALPHA_TO_ONE_SGIS to convert the alpha values to 1 before blending. Without this option, the effect would be colors that are twice as transparent.

---

Note: When you use multisampling, blending reduces performance. Therefore, when possible, disable blending and instead use GL_SAMPLE_MASK_SGIS or GL_ALPHA_TO_MASK.

---

void glSampleMaskSGIS (GLclampf value, boolean invert)

This section briefly describes multisampled points, lines, polygons, pixels, and bitmaps.

Multisampled Points

If you are using multisampling, the value of the smoothing hint (GL_POINT_SMOOTH_HINT or GL_LINE_SMOOTH_HINT) is ignored. Because the quality of multisampled points may not be as good as that of antialiased points, remember that you can turn multisampling on and off as needed to achieve multisampled polygons and antialiased points.

---

Note: On InfiniteReality systems, you achieve higher-quality multisampled points by setting GL_POINT_SMOOTH_HINT to GL_NICEST (though this mode is slower and should be used with care).

---

glHint(GL_POINT_SMOOTH_HINT, GL_NICEST)

The result is round points. Points may disappear or flicker if you use them without this hint. See the next section for caveats on using multisampling with smooth points and lines.

Multisampled Lines

Lines are sampled into the multisample buffer as rectangles centered on the exact zero-area segment. Rectangle width is equal to the current line width. Rectangle length is exactly equal to the length of the segment. Rectangles of colinear, abutting line segments abut exactly so that no subsamples are missed or drawn twice near the shared vertex.

Just like points, lines on InfiniteReality systems look better when drawn “smooth” than they do with multisampling.

---

Note: If you want to draw smooth lines and points by enabling GL_LINE_SMOOTH_HINT or GL_POINT_SMOOTH_HINT, you need to disable multisampling and then draw the lines and points. The trick is that you need to do this after you have finished doing all of the multisampled drawing. If you try to re-enable multisampling and draw more polygons, those polygons will not necessarily be antialiased correctly if they intersect any of the lines or points.

---

The SGIS_multisample extension introduces the following functions:

To use the point parameter extension, call glPointParameter*SGIS() with the following arguments:

pname		GL_POINT_SIZE_MIN_SGIS, GL_POINT_SIZE_MAX_SGIS, or GL_POINT_FADE_THRESHOLD_SIZE_SGIS (multisample points only) GL_DISTANCE_ATTENUATION_SGIS (In the ARB version of this extension, use GL_POINT_DISTANCE_ATTENUATION_ARB.)
param		When pname is GL_POINT_SIZE_MIN_SGIS, GL_POINT_SIZE_MAX_SGIS, or GL_POINT_FADE_THRESHOLD_SIZE_SGIS, param is respectively set to the single numeric value you want to set for the minimum size, maximum size, or threshold size of the point. When pname is GL_DISTANCE_ATTENUATION_SGIS, param is a pointer to an array of three coefficients in order: a, b, and c, defining the distance attention coefficients for point size. The distance attenuation equation is described in section “Point Parameters Background Information”. Note: If you are using the extension in multisample mode, you must use smooth points to achieve the desired improvements, as shown in the following: glHint(GL_POINT_SMOOTH_HINT, GL_NICEST)

A point parameters example program is available as part of the developer toolbox. It allows you to change the following attributes directly:

The following code fragment illustrates how to change the fade threshold.

GLvoid
decFadeSize( GLvoid )
{
#ifdef  GL_SGIS_point_parameters
    if (pointParameterSupported) {
        if ( fadeSize > 0 ) fadeSize -= 0.1; 
        printf( "fadeSize = %4.2f\n", fadeSize );
        glPointParameterfSGIS( GL_POINT_FADE_THRESHOLD_SIZE_SGIS, fadeSize );
        glutPostRedisplay();
    } else {
        fprintf( stderr,
                   "GL_SGIS_point_parameters not supported 
                    on this machine\n");
    }
#else
    fprintf( stderr,
               "GL_SGIS_point_parameters not supported 
                on this machine\n");
#endif

Minimum and maximum point size and other elements can also be changed; see the complete example program in the Developer Toolbox.

The raster brightness of a point is a function of the point area, point color, and point transparency, and the response of the display's electron gun and phosphor. The point area and the point transparency are derived from the point size, currently provided with the size parameter of glPointSize().

This extension defines a derived point size to be closely related to point brightness. The brightness of a point is given by the following equation:

dist_atten(d) = 1 / (a + b * d + c * d^2)
brightness(Pe) = Brightness * dist_atten(|Pe|)

Pe is the point in eye coordinates, and Brightness is some initial value proportional to the square of the size provided with glPointSize(). The raster brightness is simplified to be a function of the rasterized point area and point transparency:

area(Pe) = brightness (Pe) if brightness(Pe) >= Threshold_Area
area(Pe) = Theshold_Area   otherwise
 
factor(Pe) = brightness(Pe)/Threshold_Area

alpha(Pe) = Alpha * factor(Pe)

Alpha comes with the point color (possibly modified by lighting). Threshold_Area is in area units. Thus, it is proportional to the square of the threshold you provide through this extension.

---

Note: For more background information, see the specification of the point parameters extension.

---

The SGIS_point_parameters extension introduces the following functions:

The ARB_point_parameters extension introduces the following functions:

Having such an auto-generated z coordinate is useful in situations where the application is dealing with a stack of primitives. For example, assume a runway for an airplane is represented by the following:

All three layers are coplanar, yet it is important to stack them in the right order. Without a reference plane, the bottom layers may show through due to precision errors in the normal depth rasterization algorithm.

If you know in advance that a set of graphic objects will be in the same plane, follow these steps:

The SGIX_reference_plane extension introduces the function glReferencePlaneSGIX().

The basic assumption used by the shadow extension is that an object is in shadow when something else is closer to the light source than that object is.

Using the shadow extensions to create shadows in an OpenGL scene consists of several conceptual steps:

To create the shadow map, the application renders the scene with the light position as the viewpoint and saves the depth map into a texture image, as illustrated in the following code fragment:

static void 
generate_shadow_map(void)
{
  int x, y;
  GLfloat log2 = log(2.0);

  x = 1 << ((int) (log((float) width) / log2));
  y = 1 << ((int) (log((float) height) / log2));
  glViewport(0, 0, x, y);
  render_light_view();

  /* Read in frame-buffer into a depth texture map */
glCopyTexImage2DEXT(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16_SGIX,
      0, 0, x, y, 0);

glViewport(0, 0, width, height);
}

After generating the texture map, the application renders the scene from the normal viewpoint but with the purpose of generating comparison data. That is, use glTexgen() to generate texture coordinates that are identical to vertex coordinates. The texture matrix then transforms all pixel coordinates back to light coordinates. The depth value is now available in the r texture coordinate.

Figure 9-2 and Figure 9-3 contrast rendering from the normal viewpoint and the light source viewpoint.

Figure 9-2. Rendering From the Light Source Point of View

Figure 9-3. Rendering From Normal Viewpoint

During the second rendering pass, the r coordinate is interpolated over the primitive to give the distance from the light for every fragment. Then the texture hardware compares r for the fragment with the value from the texture. Based on this test, a value of 0 or 1 is sent to the texture filter. The application can render shadows as black, or use the shadow ambient extension described in the next section, to use a different luminance value.

The shadow ambient extension allows applications to use reduced luminance instead of the color black for shadows. To achieve this, the extension makes it possible to return a value other than 0.0 by the SGIX_shadow operation in the case when the shadow test passes. With this extension any floating-point value in the range [0.0, 1.0] can be returned. This allows the (untextured) ambient lighting and direct shadowed lighting from a single light source to be computed in a single pass.

To use the extension, call glTexParameter*() with the following parameter specifications:

After the parameter is set, each pixel that extension is determined to be in shadow by the shadow extension has a luminance specified by this extension instead of a luminance of 0.0.

Depending on the sprite mode, primitives are transformed by a rotation, as described in the following:

The axis of rotation or alignment, GL_SPRITE_AXIS_SGIX, can be in an arbitrary direction to support geocentric coordinate frames in which “up” is not along x, y, or z.

Figure 9-4. Sprites Viewed with Axial Sprite Mode

Figure 9-5. Sprites Viewed With Object Aligned Mode

Figure 9-6. Sprites Viewed With Eye Aligned Mode

---

Note: The sprite extension specification describes in more detail how the sprite transformation is computed. See “Extension Specifications” in Chapter 5 for more information.

---

To render sprite geometry, an application applies a transformation to primitives before applying the current modelview matrix. The transformation is based on the current modelview matrix, the sprite rendering mode, and the constraints on sprite motion.

To use the sprite extension, follow these steps:

The following code fragment is from the sprite.c program in the OpenGL course “From the EXTensions to the SOLutions,” which is available through the Developer Toolbox.

GLvoid
drawScene( GLvoid )
{
    int i,  slices = 8;
    
    glClear( GL_COLOR_BUFFER_BIT );
    
    drawObject();

    glEnable(GL_SPRITE_SGIX);
    glSpriteParameteriSGIX(GL_SPRITE_MODE_SGIX, GL_SPRITE_AXIAL_SGIX);

/* axial mode (clipped geometry) */
    glPushMatrix();
    glTranslatef(.15, .0, .0);

    spriteAxis[0] = .2; spriteAxis[1] = .2; spriteAxis[2] = 1.0;
    glSpriteParameterfvSGIX(GL_SPRITE_AXIS_SGIX, spriteAxis);

    spriteTrans[0] = .2; spriteTrans[1] = .0; spriteTrans[2] = .0;
    glSpriteParameterfvSGIX(GL_SPRITE_TRANSLATION_SGIX, spriteTrans);
    drawObject();
    glPopMatrix();

/* axial mode (non-clipped geometry) */
    glPushMatrix();
    glTranslatef(.3, .1, .0);

    spriteAxis[0] = .2; spriteAxis[1] = .2; spriteAxis[2] = 0.5;
    glSpriteParameterfvSGIX(GL_SPRITE_AXIS_SGIX, spriteAxis);

    spriteTrans[0] = .2; spriteTrans[1] = .2; spriteTrans[2] = .0;
    glSpriteParameterfvSGIX(GL_SPRITE_TRANSLATION_SGIX, spriteTrans);

    drawObject();
    glPopMatrix();

/* object mode */
    glSpriteParameteriSGIX(GL_SPRITE_MODE_SGIX, GL_SPRITE_OBJECT_ALIGNED_SGIX);

    glPushMatrix();
    glTranslatef(.0, .12, .0);

    spriteAxis[0] = .8; spriteAxis[1] = .5; spriteAxis[2] = 1.0;
    glSpriteParameterfvSGIX(GL_SPRITE_AXIS_SGIX, spriteAxis);

    spriteTrans[0] = .0; spriteTrans[1] = .3; spriteTrans[2] = .0;
    glSpriteParameterfvSGIX(GL_SPRITE_TRANSLATION_SGIX, spriteTrans);

    drawObject();
    glPopMatrix();


/* eye mode */
    glSpriteParameteriSGIX(GL_SPRITE_MODE_SGIX, GL_SPRITE_EYE_ALIGNED_SGIX);
    glPushMatrix();
    glTranslatef(.15, .25, .0);
    spriteAxis[0] = .0; spriteAxis[1] = 1.0; spriteAxis[2] = 1.0;
    glSpriteParameterfvSGIX(GL_SPRITE_AXIS_SGIX, spriteAxis);

    spriteTrans[0] = .2; spriteTrans[1] = .2; spriteTrans[2] = .0;
    glSpriteParameterfvSGIX(GL_SPRITE_TRANSLATION_SGIX, spriteTrans);

    drawObject();
    glPopMatrix();

    glDisable(GL_SPRITE_SGIX);

    glutSwapBuffers();
    checkError("drawScene");
}

The program uses the different sprite modes depending on user input.

Sprite geometry is modeled in a standard frame: +Z is the up vector. -Y is the front vector, which is rotated to point towards the eye.

The SGIX_sprite extension introduces the function glSpriteParameterSGIX().