Note: This article is based upon material originally published in the February 1998 issue of JavaWorld magazine (www.javaworld.com).

It has been a while since our last installment in this series on 3D graphics programming in Java. Here's a quick refresher on what we were last discussing and where we left off. In the previous two articles (see Resources), we explored Java 3D. We discussed static content and small scenes, then used larger scene graphs and built interactivity into some basic 3D worlds.

Now that you know a little bit about using Java 3D, it's time to compare and contrast the Java 3D approach to 3D graphics with the leading graphics API contender: OpenGL. Please note that this article was originally intended to be code-intensive, but the late-breaking decision by Arcane Technologies concerning the Magician binding (see below) necessitated the removal of the code examples. I hope this article's content can be adapted for a future release of Magician or a standard Java-OpenGL binding, as yet unavailable from the OpenGL Consortium.

In any event, I've endeavored to provide all the relevant and useful OpenGL-related references and URLs in the Resources at the end of this column. If you would like to dig further into Java-OpenGL, I strongly recommend that you review these references.

Java-OpenGL comparison with Java 3D
In previous installments on Java 3D, I provided a list of strengths and weaknesses of using Java 3D for graphics applications. Let's reprise that list, but do so by looking at the strengths and weaknesses of Java-OpenGL-based solutions instead of Java 3D-based solutions.

Strengths of using OpenGL (and, by extension where noted, Java-OpenGL bindings):

• OpenGL provides a procedural model of graphics
  This closely matches many of the algorithms and methods graphics programmers have used historically. The procedural model is at once intuitive and straightforward for many accomplished 3D graphics aficionados.
• OpenGL provides direct access to the rendering pipeline
  This is true with any of the various language bindings, including most Java bindings. OpenGL empowers programmers to directly specify how graphics should be rendered. One doesn't just hint and request as with Java 3D, one stipulates.
• OpenGL is optimized in every imaginable way
  OpenGL is optimized in hardware and software and targeted platforms ranging from the cheapest PCs and game consoles to the most high-end graphics supercomputers.
• Vendors of every kind of 3D graphics-related hardware support OpenGL
  OpenGL is the standard against which hardware vendors measure their graphics technology, bar none. As Microsoft has joined with SGI in the Fahrenheit initiative, it has become increasingly obvious to many that this is in effect Microsoft's indirect acknowledgment that OpenGL won the API wars for 2D and 3D graphics.

On the other hand, nothing is perfect. OpenGL, and certainly Java-OpenGL bindings, do have some significant shortcomings:

• The strengths of the procedural approach to graphics programming are simultaneously a weakness for many Java programmers
  For relatively new programmers, many of whom may have received their first formal programming instruction in Java using object-oriented methodologies, OpenGL's procedural method does not mesh well with an object-oriented approach and good engineering practice.
• Many vendors' OpenGL optimizations are meant to decrease hardware choice
  It is in each vendor's best interest to build proprietary extensions and make proprietary optimizations to sell more of its own hardware. As with all hardware optimizations, you must use accelerator-specific OpenGL optimizations with the understanding that each optimization for one platform diminishes portability and performance for several others. Java 3D's more general-purpose optimizations mostly aim to maximize the portability of Java 3D applications.
• While C interfaces to OpenGL are ubiquitous, Java interfaces aren't yet standardized and aren't widely available
  Arcane Technologies's Magician product had until recently been in the market to change this portability issue, but with its demise goes much of the cross-platform story for Java-OpenGL, at least at present. More on this below.
• OpenGL's exposure of the inner details of the rendering process can significantly complicate otherwise simple 3D graphics programs
  Power and flexibility come at the price of complexity. In the fast development cycles of today's technology world, complexity is in and of itself something to be avoided where possible. The old adage about bugs is true: the more lines of code, the more bugs (in general).

As you can see from the pros and cons for OpenGL-based approaches, Java-OpenGL is strong in many of the areas in which Java 3D is weak. OpenGL gives programmers the low-level access to the rendering process that Java 3D explicitly avoids, and OpenGL is currently available on far more platforms than Java 3D (Magician aside). But this flexibility comes with a potential price: programmers have a lot of room to optimize, which conversely means they have a lot of room to screw things up. Java 3D has more built-in optimization and an easier programming model that may prove particularly useful for programmers new to Java, 3D graphics work, or networked and distributed graphics programming.