Alternatives to Java 3D


Criticisms of Java 3D for Games Programming

The misconceptions and complaints about Java 3D closely match those used against Java, which we discussed in Chapter 1:

  • Java 3D is too slow for games programming.

  • Java 3D is too high-level.

  • Java 3D isn't supported on games consoles, so why bother using it?

  • No one uses Java 3D to write real games.

  • Sun Microsystems isn't interested in supporting Java 3D.

Java 3D Is Too Slow for Games

This claim comes with almost no evidence. Jacob Marner did the only serious test (2002). Marner carried out comparative performance tests on OpenGL and Java 3D versions of the same 3D noninteractive space of randomly positioned, scaled and rotated boxes. He used the C++ and GL4Java bindings for OpenGL, and used Version 1.3.0 beta 1 of Java 3D. His master's thesis, Evaluating Java for Game Development, can be obtained from http://www.rolemaker.dk/articles/evaljava/.

The C++ version was fastest, the GL4Java implementation a little slower, and Java 3D about 2.5 times slower. However, the slowdown was due to a performance bug in that version of Java 3D and a poorly optimized scene graph. The timings haven't been repeated with the latest version of Java 3D or with more recent Java bindings to OpenGL such as JOGL or LWJGL.

Marner's code highlights some striking differences between Java 3D and OpenGL. The C++ and GL4Java programs are of comparable sizes (about 10 classes and 30 pages of code with documentation), but the Java 3D application is smaller (5 classes and 11 pages). Marner comments on the complexity of the OpenGL code, which requires a kd-tree data structure, a culling algorithm around the view frustum, and preprocessing vertex operations. All of these capabilities are built into Java 3D, so they didn't need to be implemented in the Java 3D application. In the GL4Java source, the optimized view frustum algorithm is hard to understand but is responsible for an order of magnitude speedup over the simpler version.

The OpenGL applications could have been considerable faster if extensions available on the graphics card were employed.

Another outcome of Marner's work is that it shows a negligible overhead for JNI: GL4Java uses JNI to interface Java to OpenGL, and its performance is slightly less than the C++ binding.

Java 3D is slow because Java is slow

Java 3D performance is often equated with Java performance: the myth of Java's slowness somehow demonstrates the slowness of Java 3D. Since Java 3D relies on OpenGL or DirectX for rendering, much of the graphics processing speed of Java 3D is independent of Java.

History suggests that performance will become a less important consideration as the base speed of hardware keeps increasing. Many successful games rely less on special effects, more on gaming characterization and story. Of course, games will always need performance, but the real bottleneck will not be the platform but the network as multiplayer games begin to dominate.

Performance should be considered alongside issues such as code complexity, productivity, maintainability, and portability. These criteria strongly influence a move toward higher-level APIs, as typified by Java 3D.

Java 3D Is Too High-Level

Java 3D's scene graph is often considered an unreasonable overhead, especially by programmers with experience in OpenGL or DirectX. Though Java 3D's scene graph does introduce some overhead, this overhead should be compared to the optimizations that comes along. These can be implemented in a low-level API by an experienced programmer but at what cost in time and maintainability?

Most large OpenGL and DirectX applications need a data structure like a scene graph to manage code complexity, so the scene graph versus no scene graph argument is often invalid.

A powerful, high-level, and flexible 3D graphics API needs a scene graph and a way to access the graphics pipeline efficiently. These mechanisms are aimed at different levels in 3D graphics programming, sometimes called the entity level and the rendering level. An application's entity level requires a data structure for organizing the scene objects, and the rendering level handles light mapping, shadows, radiosity, vertex shading, and so on. Great games are designed at the entity level, in terms of game play, characters, scenarios, and story elements. The look and feel of a great game, the light and dark, the atmosphere, is created at the rendering level.

Though Java 3D has highly developed tools for entity level programming, its deficit is at the rendering level. For example, the current version of Java 3D cannot perform vertex and pixel shading. Part of this is due to the desire to support Java 3D portability across OpenGL and DirectX, preventing it from making assumptions about which low-level features are present. Nevertheless, it is possible to achieve some striking rendering effects in Java 3D by employing multi-textures. The next major Java 3D release, Version 1.4, is scheduled to support two shader languages (Cg and GLSL); a beta version is due out in the middle of 2005.

The high-level nature of the scene graph makes Java 3D code harder to tune for speed unlike programs using OpenGL or DirectX directly. However, a programmer does have the option of moving to Java 3D's mixed or immediate modes.

Hiding low-level graphics API makes programming code around bugs harder in the APIs or the drivers.

Lack of Console Support

The lack of a console implementation for Java 3D is a serious problem, but if Java and OpenGL are available on a game machine, then Java 3D should be readily portable. The Game Cube already uses OpenGL.

Linux for the PlayStation 2 includes OpenGL support (http://playstation2-linux.com/projects/openglstuff/). There's an old alpha version of an OpenGL for the PlayStation 2, implemented by DataPlus (http://www.dataplus.co.jp/OpenGL4ps2.html). However, the future for OpenGL on consoles and other small devices is probably OpenGL ES, a subset of OpenGL (http://www.khronos.org/opengles/).

A Java binding is being developed for OpenGL ES, managed by JSR 239 (http://www.jcp.org/en/jsr/detail?id=239). A JSR is a Sun-sanctioned process for defining a new Java API. Much of the work is derived from JSR 231, which will be based on JOGL and/or LWJGL (both are explained in the section "Java Bindings to OpenGL"). JSR 239 is scheduled to be finished early in 2005.

No Real Java 3D Games

Java 3D has been employed in relatively few games, but they include bestsellers and award winners. I mentioned the commercial games in Chapter 1.

  • Law and Order II by Legacy Interactive (http://www.lawandordergame.com/index2.htm).

  • Pernica by Starfire Research (http://www.starfireresearch.com/pernica/pernica.html).

  • Cosm by Navtools, Inc. (http://www.cosm-game.com/).

  • Roboforge by Liquid Edge Games (http://www.roboforge.com).

  • FlyingGuns (http://www.flyingguns.com/).

  • CazaPool3D (http://cazapool3d.sourceforge.net/cazapooljws/Pool.html).

  • Out Of Space (http://www.geocities.com/Psionic1981).

  • Cassos (http://www.la-cfd.com/cassos/english/index.php). Racing monkeys, with a dragon.

  • Immediate Mode Interactive (http://www.imilabs.com/) has built several impressive game demos with Java 3D over the years, including Java 3D Grand Prix (a racing game), JAMID (a first-person shooter in the Quake mold), and Underworld Assault (a two-person fighting game). Pictures and videos of these games can be found at the web site.

  • The Virtual Fishtank (http://www.virtualfishtank.com/main.html). A distributed simulation of a 24,000-gallon aquarium rendered to 13 large projection screens and running on 15 networked machines. The fish migrate from server to server as they swim from screen to screen. It was shown at the Boston Museum of Science and the St. Louis Science Center to teach children about emergent self-organizing behavior in decentralized rule-based systems.

  • DALiWorld (http://www.dalilab.com/). Another distributed aquatic virtual world inhabited by autonomous artificial life.

The "Other Sites" page at j3d.org (http://www.j3d.org/sites.html) is a good source for Java 3D examples and includes games and demos sections with many links.

The Java Games Factory (JGF), http://grexengine.com/sections/externalgames/, places its games into 2D and 3D categories, with the 3D examples further subdivided by the 3D API being used, such as Java 3D, JOGL, and LWJGL.

The third year Computer Graphics course in the Computer Science Department of the University of Applied Sciences in Biel, Switzerland, maintains a site of student projects using Java 3D (http://www.hta-bi.bfh.ch/~swc/DemoJ3D/). Several of them have been games, including Battleship3D-Net (networked Battleships), Billard-3D (pool), Glymp3D (role playing action), JBomba (based on Bomberman), and TriChess (3D networked chess).

A good strategy for finding Java 3D games and source code is to visit SourceForge (http://sourceforge.net/search/) and FreshMeat.com (http://freshmeat.net/) and search for keywords such as "Java," "3d," and "game."

Two very exciting Java 3D projects, which aren't really games:


Project Looking Glass(https://lg3d.dev.java.net/)

A prototype 3D desktop offering rotating, transparent windows, multiple desktop workspaces, and an API for developing applications. It received much attention at JavaOne in 2004.


The Mars Rover Mission(http://www.sun.com/aboutsun/media/features/mars.html)

Java 3D and JAI are being used to render and interpret the real-time images captured by the rover. A rover simulator is implemented in Java 3D, which is sort of a game.

Java 3D loaders for games

A loader is an essential tool for quickly populating a game with people, artifacts, and scenery. All the model loaders listed below are for popular games formats, and all support animation.


Quake Loaders (http://www.newdawnsoftware.com/)

Supports Id Software's Quake 2 MD2 and BSP and Quake 3 MD3 formats. A morphing animation example using the MD3 loader can be found at http://www.la-cfd.com/cassos/test/md3/index.html.


JAVA is DOOMED (http://javaisdoomed.sourceforge.net/)

A complete 3D engine, including loaders for Quake 2 MD2 and 3D Studio Max 3DS files.


The Java XTools (http://www.3dchat.org/dev.php) package

Offers a range of Java 3D extras, including loaders for Renderware, Caligari TrueSpace, Alias/Wavefront Maya OBJ, and MTL files. Other elements include a lens flare mechanism, a text-to-texture converter, and a skybox class.


Salamander3D (https://skinandbones.dev.java.net/)

Supports a file format for specifying 3D worlds and levels, character animations, collision objects, sensor objects, and other useful aspects of game scenes.


NWN Java 3D utilities (http://nwn-j3d.sourceforge.net/)

Handles Neverwinter Night models, including animation and emitters.


Java 3D 3DS Loader (http://sourceforge.net/projects/java3dsloader/)

Supports 3D Studio Max models, including cameras, point and directional lights, animation, and hierarchy textures.


Anim8or Loader (http://anim8orloader.sourceforge.net/)

Can load 3D models and scenes saved in the Anim8or file format. Anim8or is a 3D-modeling and character animation program (http://www.anim8or.com/main/index.html).


Xj3D (http://www.xj3d.org/)

Implements the X3D standard, a successor to VRML 97, and provides for keyframe animation. Xj3D also contains it own OpenGL renderer, which is reportedly much faster than the one inside Java 3D.

Add-ons for gaming
  • Yaarq (http://www.sbox.tugraz.at/home/w/wkien/), by Wolfgang Kienreich, offers APIs for several gaming-related features, including texturing, bump maps, reflection maps, overlays, and particle systems. It also demonstrates how to achieve stable frame rates.

  • Lighting Effects (http://planeta.terra.com.br/educacao/alessandroborges/java3d.html). Java 3D is often criticized for lacking sophisticated lighting effects. Alessandro Borges has developed several examples that show how to use bump maps to generate irregular surface lighting and cube map textures for reflection effects. Florin Herinean has also developed a series of texture examples, available at http://www.seelenbinder-schule.de/~fherinean/.

  • Toon shaders (http://www.antiflash.net/java3d/comicshader.html) demonstrates how simple cartoon-style shading can be added to shapes.

  • A library for building 3D geometries using meshes, NURBS, and subdivision surfaces (https://jgeom.dev.java.net/).

  • A CSG API, by Danilo Balby Silva Castanheira, for geometry Boolean operators is available at http://www.geocities.com/danbalby/.

  • A skeletal animation and skinning system, by Mark McKay, can be found at https://skinandbones.dev.java.net/.

  • Java 3D Game SDK (https://java3dgamesdk.dev.java.net/). The extra functionality includes a menu to let the user choose between full-screen and window mode, a game mouse, and a collision box for the precise steering of objects.

  • JXInput (http://www.hardcode.de/jxinput). This game supports joysticks and other input devices on Windows via Java 3D's Sensor class. It's also possible to interface Java 3D with JInput for game controller discovery and polled input (https://jinput.dev.java.net/).

  • The j3d.org Code Repository (http://code.j3d.org/) includes code (or partial code) for ROAM terrain rendering, particle systems, and 2D overlays.

  • The j3d-incubator project (https://j3d-incubator.dev.java.net/) on java.net is for sharing examples and utility code.

Sun Doesn't Support Java 3D

Perhaps this statement was true in 2003, but Java 3D is now a community project managed by the Advanced Software Development Group at Sun. If support means a pool of knowledgeable people ready to offer advice and large archives of technical information, then Java 3D has an abundance of support.

In the middle of 2003, Doug Twilleager issued the now infamous message "Java 3D 1.4 is currently in a holding pattern" (read it in full at http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=3D;action=display;num=1054567731). Doug Twilleager is the chief architect of the Game Technologies Group at Sun and one of the designers of Java 3D.

His message appeared just before JavaOne 2003, a conference that emphasized the JOGL, JOAL, and JInput APIs. Many people interpreted this as meaning that Java 3D was heading for the dustbin of history.

A possible reason for the holding pattern was Java 3D's development origins in the 3D Graphics Hardware Group at Sun. As graphics cards from companies such as ATI and nVidia caught up and surpassed Sun's hardware, the group started to become less profitable. Layoffs occurred and unprofitable group projects, such as Java 3D, were given low priority.

In March 2004, Doug Twilleager was back, this time announcing that Sun was making Java 3D available through a public source license at https://java3d.dev.java.net/.

The reemergence of Java 3D is due to the work of a few key people, including Doug Twilleager, and high-profile uses in Sun projects such as Mars Rover and Looking Glass. Java 3D has moved to the Advanced Software Development Group, a unit within Sun that is actively supported by upper management.

The new Java 3D project site (https://java3d.dev.java.net/) hosts the source code for Java 3D 1.3.2, a bug fix release. The version that was stable while I was writing was 1.3.1, which is used in this book.

Java 3D's license allows developers to download the source code and to contribute bug fixes and utilities. Modifications are allowed for research purposes, and a no-fee commercial license is available.

An expert group is being formed to define and implement future versions of the Java 3D API. An important point is that much of the implementation work is expected to come from the community, a strategy successfully employed to develop the JOGL, JOAL, and JInput APIs.

Four new Java 3D mailing lists exist:

  • interest@java3d.dev.java.net

  • announce@java3d.dev.java.net

  • issues@java3d.dev.java.net

  • cvs@java3d.dev.java.net

A new Java Desktop 3D Forum is at: http://www.javadesktop.org/forums/forum.jspa?forumID=55.

Older Java 3D information sources are still around:

  • The Java 3D Product Page (http://java.sun.com/products/java-media/3D/), with links to demos, a basic FAQs page, and several application sites such as the Virtual Fishtank.

  • The Java 3D Gaming Forum (http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=3D).

  • The Java 3D Interest Mailing list can be searched at (http://archives.java.sun.com/archives/java3d-interest.html). Subscription is possible from this site. A searchable-only interface can be found at http://www.mail-archive.com/java3d-interest@java.sun.com/.

  • The Java Technology Forum for Java 3D (http://forum.java.sun.com/forum.jsp?forum=21).

  • A Java 3D Programming Forum hosted at Manning Publications (http://www.manning-sandbox.com/forum.jspa?forumID=31). This is a good place to contact Daniel Selman, the author of Java 3D Programming (Manning).

  • The best independent Java 3D site is j3d.org(http://www.j3d.org). It has a great FAQs page, and a large collection of tutorials, utilities, and a code repository.

  • Java 3D at VirtualWorlds (http://java3d.virtualworlds.de/index.php) is a German/English site with sections on loaders, input devices, add-on libraries, documentation links, and a Java 3D Wiki (at an early stage).

  • The USENET newsgroup comp.lang.java.3d can be searched and mailed to from Google's Groups page (http://groups.google.com/groups?group=comp.lang.java.3d).

Roadmaps for the future

A feature-complete beta version of Java 3D 1.4 may be released by mid-2005 and will include programmable shaders and other features that can be quickly added.

The shader support will be able to process descriptions written in the Cg or the GLSL shader languages. There is an active forum thread on this topic at http://www.javadesktop.org/forums/thread.jspa?threadID=5056.

There have been discussions about using JOAL to replace Java 3D's buggy sound and to add in character animation, terrain utilities, improved collision detection and avoidance, NURBs, CSG (geometry Boolean operators), and more loaders. As mentioned in the sections "Java 3D loaders for games" and "Add-ons for gaming," many of these extensions exist.

The Java 3D team at Sun has a web page containing proposed Version 1.4 (and later) API changes: https://j3d-core.dev.java.net/j3d1_4/proposed-changes.html.

Whether these plans for Version 1.4 bear fruit depends on the Java 3D developer community; Sun is involved mainly as a manager and adjudicator. The signs for the future look bright since the community is involved in the bug fix release, Version 1.3.2.

It's interesting to look at the future plans list for Project Looking Glass (https://lg3d.dev.java.net/), which is built on top of Java 3D. It includes some of the Java 3D wish list, a physics engine (perhaps using odejava, https://odejava.dev.java.net/), and a particle system.

Java 3D 1.5 (or perhaps 2.0) will take longer to arrive since major changes are planned, such as pluggable renderers and extensibility. Athomas Goldberg, the head of the Game Technologies Group, has remarked that JOGL and JOAL may come into the picture at this stage.

The eventual release dates for Java 3D will probably be closely linked to those for Java. J2SE 5.1 (code-named "Dragon Fly") in the middle of 2005, Version 6 ("Mustang") in early 2006, Version 7 (Dolphin) in late 2007. Snapshot releases of the Mustang project can be accessed at https://j2se.dev.java.net.



Killer Game Programming in Java
Killer Game Programming in Java
ISBN: 0596007302
EAN: 2147483647
Year: 2006
Pages: 340

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net