3D Graphics Programming in Java, Part 3: OpenGL

Author: by Bill Day

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):

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

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.

Until very recently, the major choices for bindings for OpenGL programming in Java were:

Note: This list is borrowed from the OpenGL Consortium's Call for Proposals for a standard for Java bindings for OpenGL.

The OpenGL Java Bindings Working Group considered Magician, JSparrow, and GL4Java during its review process for a standard for Java-OpenGL bindings. Prior to its discontinuation, Magician was the unacknowledged front-runner for the majority of the binding discussions.

Magician had a diverse and vocal user group, albeit perhaps somewhat smaller than Arcane would have liked it to be. Arcane was readying a new release of Magician, 1.2.0, which was slated to include the following (in no particular order):

Unfortunately, Arcane Technologies recently announced the discontinuation of Magician due to poor sales.

Arcane made this announcement on March 12, 1999, with the stated intent of removing various links to related information from its Web site on March 19, 1999. Some of the Arcane Technologies and Magician links in the Resources section may cease to function at some point because of this, though all are still live as of the date of this publication.

It is unclear how Magician's termination by Arcane will affect future work on a standard Java-OpenGL binding, though the traffic on the Java-OpenGL Working Group's mailing list has fallen off somewhat since the announcement was made.

Whatever the case may be, this is bad news for those interested in using the leading Java-OpenGL binding. Though Arcane has offered to license the technology to other vendors, we will have to wait and see if anyone takes the offer and makes Magician available again in future releases. If not, one can only hope that Arcane might consider making the Magician code available to the OpenGL Consortium for use as the reference binding.

Many of the other Java-OpenGL bindings are available for Win32 platforms only, or at best for Win32 and Unix platforms. Magician, on the other hand, was available for many of the major development and deployment platforms targeted for PCs and workstations.

If Arcane can find some way to continue to make Magician available to the masses, the cross-platform portability of Java bindings to OpenGL will be greatly reinforced. Compared to the rather limited support from the other major bindings, Magician provided:

Platform

As a reminder from the last two columns, Java 3D is currently available from Sun for Solaris and Win32 platforms. If and when Magician (or some other OpenGL Consortium-endorsed Java binding of similar portability) lives on, a Java-OpenGL-based solution would be far more portable across platforms than a Java 3D-based solution. If no standard Java-OpenGL bindings (re)emerges, portability is similar across Java-OpenGL and Java 3D and the design and development decision-making process should weigh the other technical and business aspects appropriately.

And, finally, as we were finalizing this article, Jean-Christophe Taveau announced the 0.1 availability of jFree-D, a Jogl-based Java 3D implementation built using GNU tools for Linux and IRIX, among various other platforms. This announcement has the potential to increase the portability of Java 3D considerably. More on this breaking news at the end of the column.

In the meantime, what choices do developers have for a Java-OpenGL binding? As of the writing of this column, you can download implementations of the following bindings for the listed platforms:

Java-OpenGL binding

(See Resources for download information.)

As you can see, many of these implementations are supported for both Unix and Win32, and work with Mesa and/or licensed OpenGL implementations. What you will notice if you visit the individual implementations' Web sites, however, is that many of them haven't developed much further since they were introduced around 1997. The reason for this? Magician has taken the mindshare and expanded upon the capabilities of the other Java-OpenGL bindings, most of which are freeware or shareware efforts.

Given that these other bindings aren't undergoing active development, you should make your choice based at least in part on the availability of the source code and your ability to license and modify it. I would suggest verifying that you will have the capabilities you need before you start doing any significant coding: you wouldn't want to move from Magician to one of these other bindings only to find it removed from the Web and distribution, again locking you out of doing further work on your application.

Case Study: Why SynaPix chose Java-to-OpenGL

Magician's financial viability issues aside, there are some good technical reasons to at least consider using a Java-OpenGL binding in lieu of Java 3D. Java bindings have succeeded in some markets. Though Arcane may not have found enough customers to keep Magician afloat, the technology nonetheless has found some ardent supporters in the graphics development community.

Barry Ruff of SynaPix had the following to say of his company's choice to use Magician's Java-to-OpenGL bindings. (These comments were made before Arcane's announcement about Magician's termination.)

Magician itself may not become the Java-OpenGL binding standard, but it is still quite possible that one will be developed. And I suspect that many graphics applications could still benefit from Java-OpenGL bindings in similar ways to SynaPix and other Java-OpenGL users alike.

Breaking news: jFree-D 0.1 released, Magician may yet live on
Just as many developers were beginning to wonder if Java 3D would ever be available on any platforms besides Win32 and Solaris, along comes Jean-Christophe Taveau's freeware release of an unofficial Java 3D port called jFree-D (see Resources for more information).

jFree-D promises several key advances to Java 3D technology:

Interestingly, jFree-D is implemented on top of the Jogl Java-OpenGL binding discussed in the sections above. Or rather, on top of Jogl 0.7 with some minor modifications that are made available from the jFree-D Web site as Jogl 0.7a.

In any event, jFree-D's layering on top of a Java-OpenGL binding highlights the point I have made several times previously, that OpenGL (and Java-OpenGL bindings) are a low-level sort of graphics API, while Java 3D is a high-level API. In jFree-D's case, the latter is built on top of the former.

It is also interesting to note that jFree-D's use of Java on top of OpenGL gives it the potential to be more portable than Sun's Java 3D. Indeed, jFree-D's requirements give it the potential to be compiled for just about any Unix or Windows environment (and probably a great many others too).

jFree-D's current release requires:

More detailed instructions on downloading and configuring the various pieces required to make jFree-D work is available on the jFree-D Web site (see Resources).

Though jFree-D is currently in early release, the availability of its source code makes it worthwhile for many 3D developers to investigate further. It's worth a look. In addition to jFree-D news, Arcane Technologies has announced in early May 1999 that they do intend to ship a new version of Magician afterall. The release will be 2.0 (instead of 1.2.0), and will contain features listed above for 1.2.0 minus Swing integration. Arcane has also promised to make a freeware version of Magician 2.0 available for certain types of use. Watch the Magician web site (in Resources) below for more information on this release.

Conclusions

This column completes a three-part series on 3D graphics in Java. We've seen how to create and manipulate Java 3D scene graphs and discussed some of the factors driving the decision between using Java 3D or a Java-to-OpenGL binding for 3D graphics from within Java. Along the way, we've used a variety of ready-made 3D content with loaders and we have shown you how to wed Web 3D and VRML to your graphics applications.

As you encounter Java 3D and Java-OpenGL questions, please visit the new Media Programming FAQ on my newly relocated Web site: www.billday.com. I created this FAQ to archive interesting and frequently repeated questions pertaining to Java media programming. Most of these questions arise in response to my JavaWorld and Gamasutra articles, with a few thrown in from e-mail and elsewhere. I hope this FAQ will help developers leap some of the common Java media hurdles with a little more ease.

Don't be silent! This really is your forum to have your development issues addressed. Please let me know what you think, what your Java interests are, and how JavaWorld and I can help.

Bill Day is a technology evangelist for consumer and embedded technologies for Sun Microsystems. He is also an ACM Distinguished Lecturer. In addition to writing for JavaWorld, Bill plans to soon finish his book, Java Media Players, for O'Reilly & Associates. When Bill isn't evangelizing the Java cause, he loves to mountain bike, travel with his wife, and speak French. Java, c'est magnifique!

For Bill Day's previous Java 3D columns, see the JavaWorld Topical Index http://www.javaworld.com/javaworld
/topicalindex/ jw-ti-media.html

Java-OpenGL bindings and jFree-D

OpenGL tutorial resources

The OpenGL Consortium resources

The Red Book programming reference

Arcane's Magician resources (while available)

Other OpenGL, Java 3D, and graphics resources