This appendix contains a list of differences between OpenGL and IRIS GL in alphabetical order. The list is based, in part, on a document by Kurt Akeley (May 1992) that was updated by Mark Kilgard in May 1997. Each difference is given a simple concept name, based on an IRIS GL concept, followed by a description. To look up a difference, find the concept name in the alphabetical list and read the description.
accumulation from the z-buffer
Reading from and writing to the z-buffer from the accumulation buffer isn't supported in OpenGL
OpenGL accumulation buffer operation is not defined when component values exceed 1.0 or go below -1.0.
OpenGL stipples antialiased lines. IRIS GL does not.
OpenGL supports arcs in its utility library (GLU).
The attributes pushed by IRIS GL pushattributes() differ from any of the attribute sets that are pushed by OpenGL glPushAttrib() and glPushClientAttrib(). Because all OpenGL states can be read back, however, it is possible to implement any desired push/pop semantics using the OpenGL API.
automatic mipmap generation
The OpenGL texture interface does not support automatic mipmap generation. However, the utility library supports automatic generation of mipmap images for both 1D and 2D textures. See the gluBuild1DMipmaps and gluBuild2DMipmaps reference pages.
automatic texture scaling
The OpenGL texture interface does not support automatic scaling of images to power-of-two dimensions. However, scaling is supported by the OpenGL utility library. See the gluScaleImage reference page.
OpenGL does not support conditional execution of display lists.
Anything involving multiple buffers or windowing must be done in X or with GLUT.
OpenGL does not support callback from display lists. Note that IRIS GL also did not support this functionality when client and server were on different platforms.
OpenGL supports circles in the GLU. In OpenGL both circles and arcs (disks and partial disks) can have holes. Subdivision of the primitives can be changed in OpenGL and the primitives' surface normals are available for lighting.
OpenGL really clears buffers. It does not apply most currently specified pixel operations, such as blending and logicop, regardless of their modes, though there are some options that are applied. To clear using such features, you must render a window-size polygon.
OpenGL renders all single-width aliased lines such that abutting lines share no pixels. This means that the “last” pixel of an independent line is not drawn.
Changing the color map under OpenGL must be done using the X color map.
OpenGL lighting is explicitly enabled or disabled. When enabled, it is effective regardless of the order in which colors and normals are specified.
Lighting cannot be enabled or disabled between OpenGL glBegin() and glEnd() commands. If you need to disable lighting between glBegin() and glEnd(), you must do it by specifying zero ambient, diffuse, and specular material reflectance. Then set the material emission to the desired color.
OpenGL has no need for cpack(); you can use four-item vectors to specify colors instead.
color range with c3i()
The OpenGL glColor*() routines that appear to correspond directly to IRIS GL c3*() and c4*() routines are not actually equivalent. For instance, the IRIS GL c3i() function took arguments in the range [0, 255] for each color; but in OpenGL, glColor3i() allows signed arguments with values up to over two billion. Check the OpenGL Programming Guide for details on argument value ranges, and use glColor3ub() as a replacement for c3i().
The OpenGL API does not handle concave polygons, but the GLU library does provide support for decomposing concave, non-self-intersecting contours into triangles. These triangles can either be drawn immediately or returned. See the gluNewTess reference page.
current computed color
OpenGL has no notion of a current computed color. If you're using OpenGL as a lighting engine, you can use feedback to obtain colors generated by lighting calculations.
current graphics position
OpenGL does not maintain a current graphics position. IRIS GL commands that depended on current graphics position, such as relative lines and polygons, are not available in OpenGL.
OpenGL does not support IRIS GL curves. Use of NURBS curves is recommended.
OpenGL 1.0 does not have the concept of a material, light, or texture objects, only of material, light, and texture properties. OpenGL programmers can use display lists to create their own objects. In OpenGL 1.1, you can use texture objects, as discussed in the OpenGL Programming Guide.
OpenGL provides no direct support for depth cueing. However, its fog support is a more general capability that you can easily use to emulate IRIS GL depthcue().
display list editing
OpenGL display lists cannot be edited, only created and destroyed. Because display list names are specified by the programmer, however, it is possible to redefine individual display lists in a hierarchy.
OpenGL display lists are designed for data caching, not for database management. They are guaranteed to be stored on the server in client/server environments, so they are not limited by network bandwidth during execution.
OpenGL display lists can be called between glBegin() and glEnd() commands, so the display list hierarchy can be made fine enough that it can, in effect, be edited.
OpenGL checks for errors more carefully than IRIS GL. For example, all OpenGL commands that are not accepted between glBegin() and glEnd() are detected as errors, and have no other effect.
error return values
When an OpenGL command that returns a value detects an error, it always returns zero. OpenGL commands that return data through passed pointers make no change to the array contents if an error is detected.
error side effects
When an OpenGL command results in an error, its only side effect is to update the error flag to the appropriate value. No other state changes are made. (An exception is the OUT_OF_MEMORY error, which is fatal.)
Input and output that was done with such functions as getbutton(), qread(), and qdevice() in IRIS GL must be done using X calls with OpenGL, as must cursor-manipulation functions.
In OpenGL, feedback is standardized so that it doesn't change from machine to machine. “Porting Feedback Calls” explains how to port your IRIS GL feedback calls.
In OpenGL, you can't use depth-cueing and fog at the same time, because fog is used to emulate depth-cueing. IRIS GL allows more options to fog; some OpenGL implementations may compute fog per-vertex instead of per-fragment. Some new extension for fog functionality will be released as extensions to OpenGL 1.1.
fonts and strings
OpenGL expects character glyphs to be manipulated as individual display lists. It provides a display list calling function that accepts a list of display list names, each name represented as 1, 2, or 4 bytes. glCallLists() adds a separately specified offset to each display list name before the call, allowing lists of display list names to be treated as strings.
This mechanism provides all the functionality of IRIS GL fonts, and considerably more. For example, characters consisting of triangles can be easily manipulated.
OpenGL programs can use the OpenGL Character Renderer (GLC) library for accessing particular fonts. See the glcintro reference page.
IRIS GL had complex rules for defeating rendering to the front buffer in singlebuffer mode. OpenGL does as it is asked in this regard.
OpenGL does not support hollow polygons. However, you can use the OpenGL stencil capability to render hollow polygons.
Where possible, OpenGL treats color and stencil indexes as bitfields rather than numbers. Thus indexes are masked, rather than clamped, to the supported range of the framebuffer.
input and output
I/O in OpenGL is usually handled by X calls. See Chapter 4 for more information.
Signed integer color components (red, green, blue, or alpha) are linearly mapped to floating point such that the most negative integer maps to -1.0 and the most positive integer maps to 1.0. This mapping occurs when the color is specified, before it replaces the current color.
Unsigned integer color components are linearly mapped to floating point such that 0 maps to 0.0 and the largest representable integer maps to 1.0. This mapping occurs when the color is specified, before it replaces the current color.
Integer normal components are mapped just like signed color components, such that the most negative integer maps to -1.0, and the most positive integer maps to 1.0.
OpenGL guarantees certain invariances that IRIS GL does not. For example, OpenGL guarantees that identical code sequences sent to the same system, differing only in the blending function specified, will generate the same pixel fragments. (The fragments may be different if blending is enabled and disabled, however.)
The OpenGL lighting equation differs slightly from the IRIS GL equation. OpenGL supports separate attenuation for each light source, rather than a single attenuation for all the light sources as in IRIS GL, and OpenGL regularizes the equation so that ambient, diffuse, and specular lighting contributions are all attenuated. In addition, OpenGL lets you specify separate colors for the ambient, diffuse, and specular intensities of light sources, and for the ambient, diffuse, and specular reflectance of materials. All OpenGL light and material colors must include an alpha value, though only the diffuse material-color alpha value is actually used for lighting.
Setting the specular exponent to zero does not defeat specular lighting in OpenGL.
OpenGL supports local lights in color index mode. IRIS GL does not.
line stipple repeat
OpenGL line stipple repeat is clamped to [1, 256], while IRIS GL clamps this value to [1, 255].
OpenGL utilities don't directly support mapping between object and window coordinates. If you specify the right projection matrix and viewport, you may be able to achieve the same effect using gluProject().
In IRIS GL, you could call lmcolor() between a call to bgnprimitive() and the corresponding endprimitive() call. In OpenGL, you can't call glColorMaterial() between a glBegin() and its corresponding glEnd().
Material coloring in IRIS GL it was connected with lighting models. In OpenGL, it's part of the OpenGL state.
All OpenGL matrix operations operate on the current matrix, rather than on a particular matrix, as do the IRIS GL ortho(), ortho2(), perspective(), and window() commands. All OpenGL matrix operations except glLoadIdentity() and glLoadMatrix() multiply the current matrix rather than replacing it (as do ortho(), ortho2(), perspective(), and window() in IRIS GL).
mipmaps, automatic generation
The OpenGL texture interface does not support automatic generation of mipmap images. GLU does support automatic generation of mipmap images for both 1D and 2D textures; however, GLU mipmap generation isn't as flexible as that of IRIS GL. (For instance, GLU doesn't currently allow you to set weights for the texels when you average texels to generate a small mipmap from a larger one.)
For an extensive discussion of this topic, see Chapter 4, “OpenGL in the X Window System.” Note in particular that IRIS GL mixed-model routines had, in some cases, names confusingly similar to unrelated OpenGL routines; see “Function Naming Conventions” in Chapter 4 for details.
OpenGL supports only glBegin/glEnd style graphics, because it does not maintain a current graphics position. The scalar parameter specification of the old move/draw commands is accepted by OpenGL for all vertex related commands, however.
IRIS GL did not transform geometry by the modelview matrix while in projection matrix mode. OpenGL always transforms by both the modelview nad the projection matrix, regardless of matrix mode.
See the entry for “single matrix mode” in this appendix.
OpenGL renders to each color buffer individually, rather than computing a single new color value based on the contents of one color buffer and writing it to all the enabled color buffers, as IRIS GL did.
Multisampling is supported only in an extension to OpenGL. See the OpenGL on Silicon Graphics Systems document.
When OpenGL transforms normals, it uses the exact inverse of the modelview matrix. Thus, all scale commands, even scale commands with the same scale values for x, y, and z, affect the lengths of transformed normals. Avoid calling glScale() if you want the performance advantage of leaving GL_NORMALIZE disabled.
OpenGL supports NURBS with a combination of core capability (evaluators) and GLU support. GLU currently supports only Bernstein polynomials, not all splines; in the future, GLU may support changing the basis matrix to handle all splines. See the gluNewNurbsRenderer reference page.
old polygon mode
Aliased OpenGL polygons are always point sampled. The old polygon compatibility mode of the IRIS GL, where pixels outside the polygon perimeter were included in its rasterization, is not supported. If your code uses old polygon mode, it's probably for rectangles. Old polygon mode rectangles appear one pixel wider and higher.
packed color formats
OpenGL accepts colors as 8-bit components, but these components are treated as an array of bytes rather than as bytes packed into larger words. By encouraging array indexing rather than shifting, OpenGL promotes endian-invariant programming.
Just as IRIS GL accepted packed colors both for geometric and pixel rendering, OpenGL accepts arrays of color components for geometric and pixel rendering
OpenGL does not support IRIS GL patches. Use of evaluators is recommended.
per-bit color writemask
OpenGL writemasks for color components enable or disable changes to the entire component (red, green, blue, or alpha), not to individual bits of components. Note that per-bit writemasks are supported for both color indexes and stencil indexes, however.
per-bit depth writemask
OpenGL writemasks for depth components enable or disable changes to the entire component, not to individual bits of the depth component.
The performance of an OpenGL program depends in part on whether certain OpenGL features are used. A straightforward port of an IRIS GL program will probably require tuning to achieve maximum performance in OpenGL. For some tips on maximizing OpenGL performance, see “Performance”.
The OpenGL utility library includes support for generating a pick matrix. See the gluPickMatrix reference page.
OpenGL and IRIS GL agree that the origin of a window's coordinate system is at its lower left corner. OpenGL places the origin at the lower left corner of this pixel, however, while IRIS GL placed it at the center of the lower left pixel.
Note that the X Window System assumes an upper left corner for its origin.
Pixels drawn by glDrawPixels() or glCopyPixels() are always rasterized and converted to fragments. The resulting fragments are textured, fogged, depth buffered, blended, and so on, just as if they had been generated from geometric points. Fragment data that are not provided by the source pixels are augmented from the current raster position. For example, RGBA pixels take the raster position Z and texture coordinates. Depth pixels take the raster position color and texture coordinates.
OpenGL negative zoom factors reflect about the current graphics position. IRIS GL doesn't define the operation of negative zoom factors, and instead provides RIGHT_TO_LEFT and TOP_TO_BOTTOM reflection pixmodes. These reflection modes reflect in place, rather than about the current raster position. OpenGL doesn't define reflection modes. Also, OpenGL allows fractional zoom factors.
OpenGL pixel transfers operate on individual color components, rather than on packed groups of four 8-bit components as does IRIS GL. While OpenGL provides substantially more pixel capability than IRIS GL, it does not support packed color constructs, and it does not allow color components to be reassigned (red to green, red to blue, and so on) during pixel copy operations.
OpenGL provides no direct support for vertex lists other than display lists. Functions like polf() and poly() can easily be implemented using the OpenGL API, however.
OpenGL supports only filled, outlined, and dotted polygons. There is no hollow polygon mode as in IRIS GL. OpenGL polygon modes are specified separately for front and back facing polygons, while IRIS GL shares a single mode for all polygons.
polygon provoking vertex
Flat shaded IRIS GL polygons took the color of the last vertex specified, while OpenGL polygons take the color of the first vertex specified. (Note that this is true only for the GL_POLYGON primitive, not for triangles, triangle strips, and other primitive types, each of which take their colors from different vertices. See the reference page for glShadeModel for details.)
In IRIS GL the polygon stipple pattern is screen-relative. In OpenGL it is window-relative.
polygon vertex count
There is no limit to the number of vertexes between glBegin() and glEnd() in OpenGL, even for glBegin(POLYGON). In IRIS GL polygons are limited to no more than 255 vertexes.
Reading pixels outside window boundaries is properly a window system capability, rather than a renderer capability. Silicon Graphics supports an extension to X that replaces the IRIS GL readdisplay() command. See the XReadDisplay reference page.
RealityEngine graphics features
Many of the special RealityEngine graphics features of IRIS GL (including multisampling and some texture-mapping features) have been implemented as extensions to OpenGL.
OpenGL does not maintain a current graphics position, and therefore is unable to support relative vertex operations. The semantics of such operations can easily be emulated by using the matrix and glTranslate().
IRIS GL resetls() has not been supported for some time, and is not supported by OpenGL.
OpenGL 1.0 does not support logical operations on RGBA buffers. OpenGL 1.1 adds support for logical operations on RGBA buffers.
sbox() is an IRIS GL rectangle primitive that is well defined only if transformed without rotation, and is designed to be faster than standard rectangles. While OpenGL does not support such a primitive, it can be tuned to render rectangles very quickly when the matrixes and other modes are in states that simplify calculations.
All OpenGL commands that are accepted between glBegin() and glEnd() have entry points that accept scalar arguments. For example, glColor4f(red,green,blue,alpha).
OpenGL glScissor() does not track the viewport. The IRIS GL viewport() command automatically updates the scrmask.
OpenGL doesn't support bounding box computation.
OpenGL doesn't support explicit screen subdivision. scrsubdivide() was used in IRIS GL to handle perspective properly when interpolating colors and textures. Most Silicon Graphics platforms now handle texture interpolation correctly, but not all platforms do perspective-corrected color interpolation.
If you notice a perspective problem in interpolation, try specifying this hint:
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST)Under some circumstances, that may improve the interpolation. GL_NICEST specifies quality at the expense of speed, however, so if speed is a high priority you may be forced to settle for linear interpolation.
single matrix mode
OpenGL always maintains two matrices: the modelview matrix and the projection matrix. While an OpenGL implementation may consolidate these into a single matrix for performance reasons, it must always present the two–matrix model to the programmer. See “Porting MSINGLE Mode Code” in Chapter 3 for more information.
specular exponent, setting to zero
See the entry for “lighting equation” in this appendix.
When there is no depth buffer, or when the depth buffer is not enabled, the glStencilOp() argument zpass controls stencil operation when the stencil test passes. The IIS GL stencil operation is defined by its pass parameter (equivalent to OpenGL zfail) in this case.
Stereo rendering on RealityEngine graphics systems under OpenGL is accomplished by choosing an appropriate X visual.
All OpenGL rendering is subpixel positioned—subpixel mode is always on.
Anything involving multiple buffers or windowing must be done in X or with GLUT.
OpenGL does not support the swaptmesh() capability. It does offer two types of triangle meshes, however: one that corresponds to the default “strip” behavior of the IRIS GL, and another that corresponds to calling swaptmesh() prior to the third and all subsequent vertexes when using IRIS GL.
OpenGL textures are filtered with a border when they are clamped. IRIS GL does not use the border data in this case.
texture lookup tables
Texture lookup tables aren't supported in OpenGL 1.0 but are supported in OpenGL 1.1.
texture scaling, automatic
The OpenGL texture interface does not support automatic scaling of images to power-of-two dimensions. However, the GLU supports image scaling.
Three-dimensional texturing is provided as part of an extension to OpenGL.
If you use only unit-length normals in IRIS GL, and if the modelview matrix is the product only of rotations and uniform scales, you don't need to enable normalization of the normal vectors.
In OpenGL, however, uniform scaling does affect the length of normal vectors, even unit-length normals
All OpenGL commands that are accepted between glBegin() and glEnd() have entry points that accept vector arguments. For example, glColor4fv(v).
OpenGL includes no window system commands. It is always supported as an extension to a window or operating system that includes capability for device and window control. Each extension provides a system-specific mechanism for creating, destroying, and manipulating OpenGL rendering contexts. For example, the OpenGL extension to the X window system (GLX) includes roughly ten commands for this purpose.
IRIS GL commands such as gconfig() and drawmode() are not implemented by OpenGL.
In OpenGL, windows have static frame buffer configurations.
IRIS GL returned viewport and character position in screen, rather than window, coordinates. OpenGL always deals with window coordinates.
z-buffer, reading from
If you wanted to read from the z-buffer in IRIS GL, you specified that buffer with readsource() and then used lrectread() or rectread() to do the reading. If you want to read from the z-buffer in OpenGL, you simply specify that buffer as a parameter to glReadPixels().
Changing the depth of the z-buffer can be done by selecting an appropriate visual.
OpenGL does not support rendering colors to the depth buffer. It does allow for additional color buffers, which can be implemented using the same memory that is used for depth buffers in other window configurations—but these additional color buffers cannot share memory with the depth buffer in any single configuration.