OpenGL Rendering and Drawing
Pages: 1, 2

Notes, and bug!

Figure 3

Figure 3. A ha! Transparent objects must be drawn depth sorted, or errors may occur.

Readers should be aware that for optimization reasons, objects are now usually defined all at once by way of something called Vertex Arrays. This is used instead of what we're doing in this demonstration program, which is passing vertex attribute data one function-call at a time.

Even though they're now a rather universal extension to OpenGL, vertex arrays are beyond the scope of this article. The concepts covered here are still applicable, and discrete function-call methods are still common during prototyping.

I must also point out an intentional "bug" that's living in our sample program, which sharp-eyed readers may have already noticed. It has to do with transparent objects and how they must be rendered in descending distance from the camera (back to front) in order for them to appear correctly.

This isn't a problem when the objects aren't transparent, as the z-buffer is used to eliminate hidden surfaces (by OpenGL simply refusing to draw anything farther from the camera than what's already drawn). But in the case of transparency, each object contributes to the final image. Thus, the order in which the objects are rendered matter. To see this, turn on blending (which turns off z-buffering), and then rotate the cube so the red, green and blue faces are closest to you. These are drawn first, and so it will be clear something's not quite right when the faces "behind" these are next drawn on top of them.

Figure 4

Figure 4. Or you can cheat, and use an exclusively additive blend function.

There are several solutions to this problem, all of which are compromises. (Welcome to computer science). You can:

  • Do nothing, and hope your users don't notice. This is an option if your objects are very transparent and don't overlap often or only very briefly.
  • Depth-sort all your transparent polygons, breaking apart any that intersect, and render them in order after all opaque objects have been drawn. This is the "correct" method, and for a spinning cube is trivial. But for many arbitrarily moving objects, this can quickly become a lot of work for both programmer and processor.
  • Use a hack. Rather than defining the glBlendFunc() parameters as being GL_SRC_ALPHA and GL_ONE_MINUS_SRC_ALPHA, the parameters are instead set to GL_SRC_ALPHA and GL_ONE. What this does is, instead of first removing what's already rendered behind a polygon in the frame buffer based on the polygon's alpha setting before painting, it simply adds the polygon's color values to the frame buffer immediately. This means it doesn't matter what order the transparent polygons are rendered in, but it does result in a strange brightening.
    In some cases your users might not notice the effects of this trick, and in others it might even be favorable. For example, volumetric fire can be simulated in a reasonable fashion in this mode by using a series of textures containing a digitized fire animation and rendering two or more flat polygons layered and/or at right-angles to each other.
  • Decide not to use transparent objects. Without transparency, the z-buffer can always be used to handle hidden-surface removal without need for depth-sorting.

Final thoughts

OpenGL is the lowest-level, cross-platform, common hardware accelerated 3D API available. The demo program we've provided here should compile and run with only minor tweaking under any Unix with OpenGL or a clone installed. It should also work without much effort in a Windows- or Mac-based development environment, although we haven't tried that.

We've done our best to explore some of the more interesting and useful aspects of OpenGL with these articles and demo program, but in truth we've only scratched the surface of what can be done with the library. Interested readers are encouraged to visit the site to learn more. The "OpenGL Programming Guide," published by Addison-Wesley, and the "OpenGL SuperBible," published by the Waite Group, are both excellent reference books as well.

XFree86 4.0 will soon be included in major Linux distributions, and when that happens it will deliver off-the-CD access to Linux users' 3D accelerated hardware. With such hardware becoming commonplace in even the least expensive machines, I look forward to an explosion in 3D applications under Linux in the near future. Could your software project use a 3D interface?

Chris Halsall is the Managing Director of Ideas 4 Lease (Barbados). Chris is a specialist... at automating information gathering and presentation systems.

Discuss this article in the O'Reilly Network Forum.

Return to the O'Reilly Network Hub.