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.
Until very recently, the major choices for bindings for OpenGL programming in Java were:
- 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.
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:
Sun JVM, Cambridge OpenGroup, RedHat Sun port, Kaffe
Mesa for all
Mesa for all
Solaris OpenGL, Mesa (respectively)
SGI OpenGL, Mesa
Sun, Microsoft, SuperCede, Borland JBuilder, Symantec Cafe, Netscape Navigator
SGI OpenGL, Microsoft OpenGL, Mesa
Apple MRJ, Metrowerks CodeWarrior
Conix OpenGL, Mesa
IBM OpenGL, Mesa
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:
Unix (tested by developer on Linux) and Win32 (tested on Windows NT)
Unix (requires GNU make), and Win32
Interface to Mesa OpenGL-like library for Unix, Win32, other Mesa-supported platforms
A port of most OpenGL C functions to Java for platforms with OpenGL or Mesa implementations
Win32 (uses OpenGL32.dll from Microsoft)
(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, 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:
- 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. 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.
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
Java-OpenGL bindings and jFree-D
- The GL4Java binding
- The Jogl Java-OpenGL binding, which is still in beta
- The Tree Java-OpenGL binding (it's free)
- The OpenGL4Java binding
- The JavaOpenGL 1.0a3 binding
- JSparrow, an alternative Java binding for OpenGL
- The jFree-D Java 3D implementation is available from Jean-Christophe Taveau. The site includes a link to download his updated version of Jogl
- Want to try your hand at using GNU tools and a free Unix-like development environment for Win32? Check out the open source CygWin development and runtime tools from Cygnus Solutions. Highly recommended
OpenGL tutorial resources
- "Introduction to OpenGL" (MSDN Online Library) If you're new to OpenGL, this brief provides a good, concise overview (requires free MSDN registration)
- OpenGL Tutorial (Tulane University) Once you understand the very basic concepts from the MSDN overview, take a look at OpenGL code http://www.eecs.tulane.edu/www/Terry/
- "Windows NT OpenGL: Getting Started" (MSDN Online Library) A good, though dated, technical article on Windows-specific OpenGL. This article includes some useful figures illustrating the relationship between OpenGL and other graphics DLLs and the Win32 graphics system (requires free MSDN registration)
- "An OpenGL Update for Game Developers," (Gamasutra magazine, November 1997) An update on OpenGL for Windows that addresses a lot of the out-of-date sections in Microsoft's document. Though this document itself is dated in places (SGI no longer provides a Win32 OpenGL implementation, instead it now works with Microsoft on theirs). The best technical description of OpenGL for Windows I have found online
- SGI maintains an excellent OpenGL site, and no, I'm not just saying that because I worked for the company! The site includes links to download a copy of the latest OpenGL specification (1.2), links to standard helper and extension libraries, and much more.
The OpenGL Consortium resources
- OpenGL Consortium home page. Stop here first when looking for OpenGL information and resources
- The OpenGL Consortium also lists the known Java-OpenGL bindings on its site. Click here to get URLs for the bindings
The Red Book programming reference
- OpenGL Programming Guide: The Official Guide to Learning OpenGL, Version 1.1 (aka The Red Book), Jackie Neider, Tom Davis, Mason Woo (Addison-Wesley 1997) The definitive OpenGL programming reference
- The previous version of the Red Book, corresponding to OpenGL 1.0, is available online
Arcane's Magician resources (while available)
- Arcane Technologies's Magician site is still active, though much of the content has been removed
- The Magician documentation. Still available as of this writing, this includes javadocs for the API, as well as a programmer's guide and information on Magician's submission to the OpenGL ARB board for consideration as the basis of the standard OpenGL Java binding
- Archives of the discussions of the OpenGL Java Binding Subcommittee. List members are currently working to specify a standard Java-to-OpenGL binding for all vendors to be able to provide a consistent Java API for OpenGL graphics. Scroll down to the "Java-OpenGL Working Group," section to read through previous postings
- Java-OpenGL FAQ. Not convinced that Java bindings to OpenGL are a good choice for your application? Arcane dissects the available options
Other OpenGL, Java 3D, and graphics resources
- The OpenGL Perl Module site. Do you use Perl for Web hacking or other scripting tasks? If so, you might be interested to know that you can also use OpenGL from within Perl
- Tom's Hardware Guide. Want more speed from your OpenGL applications? Upgrade your accelerator card! Tom Pabst has assembled an excellent section on video cards in general and good information on OpenGL accelerators in particular
- "Fahrenheit: No Spontaneous Combustion Here!" Ron Fosner (Gamasutra, April 1998) Have you heard about a new graphics technology called Fahrenheit and wondered where it fits into the OpenGL versus Direct3D and 3D-graphics-in-Java puzzles? Read this third-party assessment for more information and an idea of how it will affect graphical application development in the coming year
- "Exploring the Java 3D API," Travis Bryson (Performance Computing, April 1999) includes all the gory details of the API, and it includes an example application, EarthSim http://www.performancecomputing.com/features/
- SynaPix doesn't currently have a Web site. Keep an eye out in case it decides to publish one.