Finally, there is a fourth scenegraph occasionally mentioned called "Aviatrix". Aviatrix was developed as part of a next generation .VRML type project based on XML. Aviatrix has also been open sourced and it has a few vocal supporters (though I know of no completed games using it.)

Why would I not want to use a scene graph API?

Can Java do 3D games?

What is a Game Engine?

Game engines come in two forms. Some are programmed by the game programmer by adding code written in the same language as the game engine. Renderware for instance, is writen in C and requires that you write C code to use it. Some game engines support their own custom "scripting languages". The quake engine is coded primarily in their script language Quake-C. Bioware's "aurora" engine is coded in another C derived scripting language called NWNC.

Most commerical game engines today that support scrupting languages let you code at both levels, script and. "native code".

Are there any Game Engines for Java?

In general Java based game engines don't support additional scripting languages because there is no need. Java provides everything a traditional scripting language does and more. In fact, Java has been used as a scripting language in such hit comercial products as IL2 Sturmovik. Yes.

Finally, also as mentioned above, if you really have the time and inclination to write an entire sophisticated scene management system for your game that is custom to that game and takes advantage of limits inherent in the game's design, you may be able to squeeze better performance out then if you used a standard scene graph system such as Java3D.

Why would I not want to use Java3D?

There are a few good reasons to chose not to use Java3D. The biggest one is if you need access to absolutely the latest, greatest features on the graphics hardware. These features are always available first through the OpenGL extension mechanism. The Java3D team takes some time to analyze the new features and figure out the best way to implement them. Then they have to actually add them to the Java3D code base. Often when these features are new, different actors in the 3D world (Nvidia, ATI, etc) will come up with slightly different ways of handling them. The Java3D team will often wait until a clear standard emrges, because they don't want to put out versions of Java3D that end up incompatable with later versions.

Some good exampels are pixel shaders, which came in with Java3D 1.4, and multi-pass rendering which is planned for Java3D 1.5. (This is differnt from mjulti-pass texturing, which Java3D has supported for quite awhile.)

Can Java do 3D games?

Absolutely. There are quite a few demos and independant 3D games out there written in pure Java that are every bit as good and high performance as those written in C or C++. Here are a few of my favorites:

* Jake2 * TribalTrouble * MegaCorps Online * Worm Online

How do I write hardware accelerated 3D games in Java?

You write hardware accelerated 3D games by using an API that allows you to communicate with the 3D hardware in your computer or device. In the J2SE^? Configuration, these APIs are optional packages today that you include with your application. In J2ME Configurations the APIs are generally provided by the device manufacturer and are resident in the device.

What APIs are available to do 3D rendering in Java?

The Java 3D APIs fall into two main categories-- Render library bindings and Scenegraphs.

Render library bindings are Java APIs that make calls directly to the underlying libraries all programs use to talk to the 3D hardware. There are 2 choices in render libraries today-- OpenGL and Direct3D^?. They functionally do the same things. The big difference between them is that Direct3D^? is only available for Windows while OpenGL is supported on many different system including Windows, Linux, Macintosh, the PS2 and the upcoming PS3. For this reason Sun and the open source Java game development communoity have both decided to support OpenGL and not Direct3D^?. (At least not yet.) By writing Java 3D games ontop of an OpenGL binding you preserve your portability and many Java based 3D games run un-modified on Mac, Linux and Windows.

Render libraries are very low level. You render by sending indvidual strings of polygons along with their render parameters to the card. The Render library has no sense of a world, 3D objects, or those objects relationships to each other.

Scenegraphs are a higher-level way to talk to 3D hardware. They organize the world in terms of 3D objects and their inter-relationships to each other. A good scene-graph does much of the work a game engine would otherwise have to do. It determiens what is visible and doesnt waste the computer's power processing things you can't see. It also organizes the order of operations sent to the lower level render library in order to allow it to work in the fastest possible manner.

Are OpenGL bindings faster then scenegraph APIs?

This is at best an incomplete, and at worst a totally nonsensical question. The missing component is "faster for what?"

Scenegraphs are designed to handle viewpoint travel through moderately to very complex environments. As explained above they do many things to speed up the rendering of such scenes. In order to do the same thing starting with OpenGL, a game developer would have to effectively write a scenegraph system themselves as part of their game engine.

But scenegraphs are a very bad fit for some other kinds of games. A lot of classic-style 2D games are written using OpenGL today because the video hardware of a computer is typically a 3D accelerator and OpenGL is the best way to use its power. These games draw small numbers of textured polygons directly in the view. Generally every polygon they draw is in the view, as there are very simple and fast 2D ways to determine what is not visible. A scenegraph would only add complexity and give no value ina case like this. Its better just to use the OpenGL binding.

Some very simple 3D games might also not justify the use of a scenegraph. Board games where the camera veiw is fixed are one good example. Here too using the scenegraph might mean paying the scengraph over-head for little to no gain.

Finally, on some very complex 3D environmental games, where the game developer writes their own scenegraph system just for that game, it is possible to use game-specific cheats to improve the performance over a general scenegraph API. These custom scenegraphs would also be written ontop of an OpenGL binding. However, developign such a system is generally a huge undertaking, The classic example are the Quake engines, but each Quake engine takes ID many many years of team development to produce.

So the upshot of all this is this: unless your game has a very simple rendering situation, or unless you are a rendering system expert like John Carmack and willing to take years just developing your game-custom scenegraph system, you are generally best off performance wise using a standardized scenegraph.

What OpenGL Binding APIs are available for J2SE^??

The currently popular and supported OpenGL bindings are JOGL and LWJGL.

JOGL is the open-source binding supported by Sun and the OpenGL ARB (the comittee that defiens the OpenGL standard.) It is currently going through the standards process and, when complete, it will be the official OpenGL binding for Java. It is a pure OpenGL binding, matching the C calls mostly call for call. Because it is being promoted by Sun, the Sun JDK group is actively supporting JOGL and as a result it has particularly good integration with AWT and Swing in the latest Sun implementations of J2SE^?.

LWJGL was developed by a very talented Java game developer and has been supported by an active group at JavaGaming.org. Unlike JOGL, it does not rely on AWT, though the latest versions of LWJGL can inter-operate with AWT and Swing. LWJGL stands for "Light Weight Java Game Library" and is more then just an OpenGL bindin g. It also provides APIs for 3D positional sound and discovering and reading controllers. (JOGL developers can access these functions by using the independant JOAL and JInput APIs.)

What is the fastest OpenGL API for J2SE^??

JOGL and LWJGL have the same performance. Both perform about as well as the C OpenGL APIs.

What Scenegraph APIs are available for J2SE^??

The original Java 3D scenegraph API is Java3D. It is still the only Java scenegraph API for J2SE^? that is defined by a JCP standard. Java3D was developed originally as an internal Sun project but the code has recently been made open source. Sun maintains a team that contineuds to support and develop Java3D further in conjunction with the Java3D open source community.

For a period of about a year however Java3D was in mopthballs. During that time some people were unsure of Java3D's future and felt a need to develop their own solutions. One such group was a game team working on a 3D MMORPG in Java called "Magicosm." They developed their own scenegraph they called "Xith." The Magicosm project has since become defunct but the Xith scene-graph was also released into open source and there is a small but active developer community still using it at JavaGaming.org

Finally, there is a thrid scenegraph ocassionally mentioned called "Aviatrix". Aviatrix was developed as part of a next generation .VRML type project based on XML. Aviatrix has also been open soruced and it has a few vocal supporters (though I know of no completed games using it.)

What is the fastest scenegraph API for J2SE^??

This is a hotly contested point. Ther are vocal advocates of both Xith and Aviatrix who will insist that they are faster then the standardized Java3D. Frankly, every time I've looked at a "proof" of this point (and I've looked at quite a few) it turned out to be a fundementally flawed test in at least one major way.

I have seen no evidence to suggest that any one scenegraph API out there is faster or slower then another one. For individual use cases, one or another might have a slight edge. In particular, Java3D is designed to process the kind of complex environments we find in most 3D games very efficiently. This entails some over-head so that, for very simplistic 3D environments that don't need all the sophisticated processing, I can imagine that a simpler scenegraph engine might be faster. (On the other hand, if your 3D environment is that simple you really shouldn't be having any speed problems on modern 3D hardware anyway.)

One noteable difference between Java3D and the others is that Java3D is the only multi-threaded scenegraph system. This means that Java3D should perform much better then the other two on multi-core systems. (Both Xbox360 and PS3 are multi-core systems. While single-core is still dominant on the desktop multi-core desktop systems are readily available and likely to become increasingly common in the coming years-- particularly as high-end gaming rigs.)

-- Main.jeffpk - 04 Dec 2005