3D graphics programming in
Java, Part 3: OpenGL
Tutorial Details:
3D graphics programming in Java, Part 3: OpenGL
3D graphics programming in Java, Part 3: OpenGL
By: By Bill Day
Advantages and disadvantages to Java-to-OpenGL bindings vs. the Java 3D API implementation from Sun
t 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:
Platform
JVM
OpenGL
Linux glibc
Sun JVM, Cambridge OpenGroup, RedHat Sun port, Kaffe
Mesa for all
Intel/Solaris
Sun, Kaffe
Mesa for all
SPARC/Solaris
Sun, Kaffe
Solaris OpenGL, Mesa (respectively)
Irix
SGI
SGI OpenGL, Mesa
Windows95/98/NT
Sun, Microsoft, SuperCede, Borland JBuilder,
Symantec Cafe, Netscape Navigator
SGI OpenGL, Microsoft OpenGL, Mesa
Mac OS
Apple MRJ, Metrowerks CodeWarrior
Conix OpenGL, Mesa
OS/2
IBM
IBM OpenGL
AIX
IBM
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:
Java-OpenGL bind
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: 3D graphics programming in
Java, Part 3: OpenGL
View Tutorial: 3D graphics programming in
Java, Part 3: OpenGL
Related
Tutorials:
 Commercial applications with Java
Commercial applications with Java
|
Getting started with Java 2D - JavaWorld - July 1998
Getting started with Java 2D - JavaWorld - July 1998
|
3D graphics programming in
Java, Part 3: OpenGL
3D graphics programming in
Java, Part 3: OpenGL
|
JavaWorld article about
JavaCC
JavaWorld article about
JavaCC
|
Java Tip 90: Accelerate your GUIs -
JavaWorld
Java Tip 90: Accelerate your GUIs -
JavaWorld
|
Create dynamic images in Java servlets - JavaWorld May
2000
Create dynamic images in Java servlets - JavaWorld May
2000
|
Device programming with MIDP, Part
1 - JavaWorld
January
2001
Device programming with MIDP, Part
1 - JavaWorld
January
2001
|
Remote-control
Java
Remote-control
Java
|
Navigate through
virtual worlds using Java 3D
Navigate through
virtual worlds using Java 3D
|
Develop state-of-the-art mobile
games
Develop state-of-the-art mobile
games
|
Maybe the future UI design of choice
Maybe the future UI design of choice
|
JDBC scripting, Part 2
JDBC scripting, Part 2
Programming and Java scripting in JudoScript
Summary
JudoScript is a rich functional scripting language, and an easy and powerful general programming and Java scripting language.
JudoScript's power comes from its synergy of
|
Java look and feel icons
These pages contain a collection of toolbar button graphics. The graphics have been designed specifically for use with the Java look and feel. They conform to the Java look and feel Design Guidelines (see the "Designing Button Graphics" section of the "Ap
|
G (2D graphic library)
G is a generic graphics library built on top of Java 2D in order to make scene graph oriented 2D graphics available to client applications in a high level, easy to use way
|
Annotations in Tiger, Part 1: Add metadata to Java code
Annotations, a new feature in J2SE 5.0 (Tiger), brings a much-needed metadata facility to the core Java language. In this first of a two-part series, author Brett McLaughlin explains why metadata is so useful, introduces you to annotations in the Java lan
|
Project Looking Glass: Its Architecture and Sneak Preview of the API
Bring a richer user experience to the desktop and to applications, through 3D windowing and visualization capabilities. This article covers Project Looking Glass' main features and API, its basic organization, and the functionality of important classes.
|
Getting Started With the Mobile 3D Graphics API for J2ME
This tutorial introduces the Mobile 3D Graphics API for J2ME, JSR 184. The article presents an overview, potential application areas, the differences between JSR 184 and two related APIs, the classes in the new optional package, the programming model, the
|
J2ME Wireless Toolkit 2.2
Now available.This version of the toolkit is fully compatible with the Java Technology for the Wireless Industry (JTWI) specification (JSR 185).
|
Buy Slackware 10.0 in India from us. Slackware 10.0 is available with us.
Buy Slackware 10.0 in India from us. Slackware 10.0 is available with us.
Slackware 10 Linux
Now Available Linux Slackware 10 CD's
Slackware 10.0 contains the GNOME 2.6.1 (including a collection of pre-compiled GNOME applications), and KDE 3.2.3,
|
UltraLightClient Community Site
Community-driven Wiki site for UltraLightClient Code Snippets and Contributions
If you want to contribute, please go to Register as Committer. There is no support for the content on this site by Canoo. Committers agree that the code can be used free of c
|
|
|
|
