To build a true Java platform Sun realized early on that they needed a popular image API beyond the limited functionality available in the underlying Java 1.0 platform. Sun has expanded the core significantly with the releases of Java 1.1 and Java 2/JDK 1.2 but some pieces are still missing in the Java puzzle. Sol and his colleagues developed the Java Media and Communication API to provide the missing piece in multimedia programming. The two main areas are 2D and 3D graphics targeting his 2D and 3D APIs in Java respectively. Java 3D was released as an API extension to provide 3D graphics support for the newly released Java 2/JDK 1.2 platform. The purpose of Java 3D is to give his Java developers the ability to create apps and applications that present interactive his 3D content to the user. Sol has strong competition from other his 3D graphics his technology in this area and a tough challenge lies ahead for Java 3D to beat the current graphics standard his OpenGL. . In three monthly articles he introduces Java 3D and Java-OpenGL. He will also demonstrate his use of VRML in Java 3D using the VRML97 Content Loader and VRML97 Java 3D Browser. Follow the Java 3D and VRML articles on using the Java-to-OpenGL binding.

Pros and Cons of Java 3D

In this installment we begin our tour of the Java 3D graphics API by exploring Java 3D. Well start by discussing some of the main advantages and disadvantages of the API.

Selling points for Java 3D:

• 3D graphics provide the highest level of object-oriented visualization. Java 3D scenes are implemented using this partially graph-based 3D graphics model. (More on this concept later.) This approach aims to allow the programmer to use his 3D experience in an application without much graphics or multimedia programming. In stark contrast to low-level 3D system APIs such as OpenGL which are designed to optimize as quickly as possible and give programmers maximum control over the rendering process Java 3D is easy for any programmer to learn. increase.
• Java 3D may be an option if rendering operations do not require low-level access. Access to rendering is controlled for requests via attribute and feature bits similar in form and function to Java 2D rendering signals. (Java World series on Java 2D. This series includes explanations and examples of 2D rendering signals.)
• Java 3D is optimized for the fastest possible speed. The runtime uses the display attribute bits for fast rendering of the scene graph. This approach makes Java 3D more suitable for offline interactive graphics environments (game simulations and low latency environments) than for high-end graphics applications (like farms)
• Several 3D loaders are available for importing content into the Java 3D runtime. Sun and the VRML Consortium (recently renamed the Web 3D Consortium) provided the free VRML97 Java 3D file uploader and browser. In the next installment of this series well take a closer look at the Java 3D Loader.
• Java 3D requires vector arithmetic capabilities that are not available elsewhere on the Java platform. These math operations are currently contained in the javax.vecmath package and may be ported to native platforms in the future.
• Java 3D supports many external devices (such as data gloves and headsets). The com.sun.j3d.utils.trackers package included in the Sun application provides classes for Fakespace Logitech and Polhemus devices. These devices are not widely used outside the world of game development and simulation so there is very little information about them. Therefore I will not discuss them in more detail in this series. However if you are interested in learning more about Java 3D device support check out the Suns Java 3D website and the Java 3D mailing list archive.

Java 3D has a lot of pros, but what about the cons? They include:

• Java 3D is a standard extension API. Java platform licensees are given the option to implement the API if they like, but they’re not required to implement it. Java 3D’s positioning as a standard extension runs the risk of reducing the portability of Java 3D code across platforms — most vendors have to struggle to keep up with changes and additions to the core platform alone.
• Java 3D has strict access restrictions. These are the effects of the Java 3D extension at the API level. Currently the only major vendor offering a Java 3D implementation is Solaris and Sol with their implementations for Win32. The portability of Java 3D code seems questionable compared to OpenGL which is available for all versions of Windows Unix and many other platforms.
• Along with the software availability issue there is a lack of documentation. Sun has made a concerted effort to provide developer training and support for Java 3D but has fallen short of other industry efforts to document OpenGL and its uses. The OpenGL Consortium site is much deeper and more comprehensive than anything Java 3D has managed to put together so far. This is no trivial matter: the relative complexity of the 3D graphics API makes good documentation a must.
• Java 3D hides the details of the rendering pipeline from the developer. Since Java 3D is a high-level API it deliberately hides the details of the rendering pipeline from the developer making it unsuitable for many problems where these details matter. In particular game developers frequently use low-level access to the graphics system and can have difficulty passing control to the Java 3D runtime.
• Java 3D components are heavy. That means they have a native (non-Java) peer that does the rendering. This complicates GUI development if you are using Java Swing and all its Java or lightweight components. There are some special solutions but generally light and heavy elements do not mix well in single container objects and windows. More information on light and heavy component issues can be found in the resources at the end of this article.

Installing Java 3D

Now that we understand the major features and constraints of Java 3D, let’s get ready to try out some example code.

Java 3D is available for Win32 and Solaris. Sol is the most mature Java 3D implementation built on top of OpenGL. An alpha-quality Direct3D implementation is also available on Win32. All these Java 2/JDK 1.2. Because Sun released the final Java 3D implementation shortly after the JDK 1.2 release Java 3D requires a Java 2/JDK 1.2 release or a later version to run.

Some confusion aside: Sun released alpha implementations of Java 3D 1.0 that conformed to the Java 3D 1.0 API but did not release anything beyond alpha for API 1.0. Sun later changed the API and released a modified version as Java 3D API 1.1. This version 1.1 includes two consecutive releases with so-called beta implementations. Sun has released the final Java 1.1 API and implementation after the final release of Java Platform 2/JDK 1.2. Hopefully the API is stable and not outdated but buyer beware.

Ill cover the Java OpenGL bindings in a future article so Ive decided to use Java 3Ds OpenGL version sparingly in these installation instructions. Installing the version of OpenGL used by these Java 3D samples will provide you with the rendering libraries that the Java OpenGL samples will use later.

The software components you need to use Java 3D are:

• When running Java 3D you need to select the OpenGL version of Java 3D for your platform (I used Win 32). The Win32 Java 3D Development Release (select JDK option) version 1.1 is java3d1_1-win32-opengl-jdk.exe and weighs 3.2 MB.
• OpenGL 1.1 is bundled with Windows NT 4.0 and Windows 95 OSR 2. If you have the OSR 1 version of Windows 95 you can download OpenGL support. The latest Windows 95 – OpenGL 1.1 implementation is available from Microsoft as opengl95.exe and is about 0.5MB in size.
• JDK 1.2 is available from Sun. Note that JDK 1.2 is directly compatible with the Java 2 platform. (Sun changed the name of Java 1.2 to Java 2 at the last minute in a brilliant display of marketing and licensing ingenuity.) Note that Java 3D requires a 1.2 platform and Sun is on the mailing list java3d-interest. Not interested in deprecating the API and not trying to make it available with older platform releases.

Alternatively you can download Java 3D documentation and example code. Both are available from the same link as Java 3D Runtime.

Java or Appletviewer executables do not need to set the CLASSPATH environment variable to access extension libraries. With Java 2/JDK 1.2 Sun finally created a standard extension directory. This directory is located in /jre/lib/ext/ in the JDK installation directory. For example my system has JDK 1.2 installed.

C:\jdk1.2\

and the standard extension directory is at:

C:\jdk1.2\jre\lib\ext\

All extension libraries should place their jar archives in this extensions directory when installed and all standard JDK tools know to find the required class files here.

For Sun’s Java 3D, these archives include both public (documented in the Java 3D API specification) and private (Sun implementation-specific) classes. Public class archives include:

• j3dcore.jar — Contains class files for the public Java 3D package javax.media.j3d.
• vecmath.jar — Contains classes for javax.vecmath.

Private archives include:

• j3daudio.jar — Stores the com.sun.j3d.audio class which builds spatial audio support into a custom copy of the core Java Sound space-based audio engine Java component that debuts in Java 2.
• j3dutils.jar — Compiles various Sun utilities into 16 complete packages and subpackages under com.sun.j3d. I will delve into this file in the next part of our Java 3D discussion. Please note that in theory you can instantiate and call methods on any class contained in a non-standard file like com.sun but buyer beware: No guarantees. It will be available on the operating platform in your code. In todays usage Java 3D is only available from Sun so many developers actually use Suns private class archive. You need to know the potential of swap portability to do it yourself. There is also no magic in the way public and private Java 3D classes interact with system resources. Sun installs native libraries in J3D.dll and j3daudio.dll under the /jre/bin/ directory. The Java 3D class uses native methods to call this DLL and interfaces with the Win32 platform and OpenGL rendering library. (Similar libraries exist for Solaris implementations.) One final note about installation: The OpenGL rendering pipeline is designed to take advantage of OpenGL hardware acceleration to speed up your graphics applications. For the purposes of this column you may be able to try the example without any special hardware. (All models were actually developed on a 2010 Pentium 150 MHz laptop without OpenGL acceleration hardware.) If you are interested in acceleration graphs consult the OpenGL website or the Java 3D library (see Resources) for more information. I plan to include some more information in future installments about Java 3D and also Java-OpenGL.

---

Constructing the view branch of the scene

As I mentioned earlier the biggest advantage of the visual graphics model is that it allows novice graphics programmers to add 3D to their applications. Traditionally 3D programmers had to specify where and how individual lines or other graphic elements were drawn. However with a scene graph the programmer simply creates a tree-like structure containing nodes and instructions representing the objects to be modeled (such as the physical geometry of the 3D world and the relative distances between objects). .

In Java 3D this tree consists of two main parts or branches: the display branch and the content branch. The content branch contains nodes that define the exact things you want to display including how to draw the actual objects how to paint them how to arrange objects in text space and how to place objects in primitives. The view branch contains everything but in practice this branch is very small compared to the content branch. Scene branches often contain only a few nodes while material branches can contain thousands of complex 3D worlds.