3D graphics programming in Java, Part 3: OpenGL

It has been a while since our last installment in this series on 3D graphics programming in Java (more on that at the end of this column). Here’s a quick refresher on what we were last discussing and where we left off.

In the previous two columns (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 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 and 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.

Magician: Great but gone

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

• Magician
• GL4Java
• JSparrow
• OpenGL4Java and several of its derivatives (Jogl, Palevich Java/OpenGL bindings, Tree)

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

• Swing and JFC 1.1 integration via a lightweight OpenGL-aware component

• Offscreen rendering support to work with Magician’s standard heavyweight and new lightweight components

• Enhanced capabilities support, including the ability to enumerate available capabilities (or visuals, in X Windows terminology)

• Overlay support

• Runtime OpenGL version checking

• Some performance enhancements

• OpenGL 1.2 compliance

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.

Availability of OpenGL for Java

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:

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:

(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.)

SynaPix is developing a visual effects workstation product called SynaFlex. SynaFlex analyzes film and video footage and creates 3D representations of a given scene. The scene is then combined with synthetic objects in a single 3D space where a variety of techniques can be used to merge 2D and 3D elements. The SynaFlex system is about 90 percent written in Java. In a large part that is due to the Magician API.

SynaFlex was originally going to use OpenGL and a higher level scene graph representation like Optimizer or Performer and then use Java for its UI. But after some initial benchmarking of Magician’s performance, it became clear that there was no downside to coding OpenGL components directly in Java. And clearly there was a big upside to moving to a more Java-centric system. So, we proceeded to develop our own scene graph making heavy use of Magician for our OpenGL interactive display and picking.

At the time, Java 3D was in its infancy and we needed a more substantial scene graph to deal with the complexity of the 3D products we would exchange data with, such as Softimage and Alias|Wavefront Maya. Technically, Magician has been a rock. OpenGL is a fairly complicated API and our developers come from many years of 3D workstation hackery. We push the envelope of what OpenGL can do and the performance level of the graphics we use. Magician has stood up to the heat admirably.

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 — Java 3D built on OpenGL

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:

• Free availability of source code, allowing more developers to innovate around and within Java 3D

• Runs under Java 1.1 development kits and runtimes. In contrast, Sun’s Java 3D requires a Java 2 (JDK 1.2) implementation

• Available on two of the most important development and graphics platforms not supported by Sun’s Java 3D implementation: Linux and IRIX

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:

• JDK 1.1.x
• OpenGL implementation
• C compiler
• GNU make (available for all Unix flavors as well as Win32)

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.

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.

Next month, we’ll shift our attention to a topic near and dear to my heart: streaming audio and video with the Java Media Framework (JMF). Please start sending in your JMF questions now so I can be sure to address them.

And speaking of 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 Media Programming columns, 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.

Finally, I would like to apologize for the interruption in Media Programming columns and to provide a short explanation.

The interruption in columns stems from a related interruption in my personal and professional life, but hopefully one for the better in the long run: I have recently accepted a position at Sun Microsystems. I will be evangelizing the heart and soul out of Java for consumer and embedded devices. I believe that my new role at Sun will allow me to provide more assistance and information to JavaWorld readers while also exploring my other strong interest in UI engineering (besides multimedia), namely, efficient and intuitive UIs for consumer devices.

I hope to have the opportunity to meet and discuss Java development and technology with a great many more of you in the coming months. Please let me know if there is any way I can help with your development efforts. I am always happy to answer your questions via e-mail, but please feel free to also contact me to ask for help in coordinating discussions between your developers, to help point you toward development resources of which you may not have been previously aware, or to provide any other Java development assistance for which you may be searching. I make no promise that I can find the resource you are seeking, but I do promise to do my best.

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.