Java 3D progress and next steps

Today I made progress on updating ImageJ’s version of Java 3D to version 1.6, which has several advantages over older versions of Java 3D:

  1. Java 3D 1.6 is built on JOGL2, a modern 3D graphics framework for Java.
  2. Its native library dependencies are managed in more robust way which does not require anything to be installed as a Java platform extension into lib/ext.
  3. Hence, Java 3D 1.6 libraries can be declared as standard dependencies, just like any other library, and deployed at runtime in the standard way.

Using this new version of Java 3D should alleviate the problems people have been having with the 3D Viewer when using Java 7 and Java 8.

Actually, this new version of Java 3D requires Java 7 or later. So once we complete the work described below and switch things over, 3D visualization will no longer be possible in Java 6. This is probably OK, since we plan to migrate fully away from Java 6 soon anyway.

Recent progress

  • A while back, I forked the Java 3D 1.6 libraries—to ctrueden/java3d-core, ctrueden/java3d-utils and ctrueden/vecmath—and updated them to break circular dependencies and use Maven as the build system. Among other advantages, this makes it easy to deploy the builds to a Maven repository and consume them as dependencies.

  • Today, I rebased these forks over the latest upstream master branches. This updates them from JOGL 2.2 to JOGL 2.3. I also redid the work in a way which is much less disruptive that before, avoiding en masse renames of source files. See:

  • I filed some PRs in the upstream repositories to break the circular dependency between java3d-core and java3d-utils:

  • I created a scijava/scijava-java3d component to house Java-3D-related utility methods. At the moment, it has logic to check java.ext.dirs for obsolete Java 3D installations, and warn the user if any are found.

Testing the 3D Viewer

[EDIT: Please do not use these instructions anymore. Instead, turn on the Java-8 update site. See this news post for details.]

If you want to try out the 3D Viewer with these changes, you can download a Fiji bundle containing the updated libraries. If you are on Windows or Linux, you might need to copy your ImageJ launcher in there though.

Alternately, if you want to build things yourself, the steps are:

Unfortunately, you cannot use the imagej-maven-plugin as-is to copy them into an ImageJ installation (via, because it gets confused about all the JOGL artifacts with classifiers. So instead you must then:

  • Copy all JARs from target/dependency into $IJ_HOME/jars, except for ij-1.49*.jar (there is already a newer version).
  • Copy target/3D_Viewer-4.0.0-SNAPSHOT.jar into $IJ_HOME/plugins and delete the old $IJ_HOME/plugins/3D_Viewer-3*.jar.

Finally, to be safe, you should:

  • Check out scijava/scijava-java3d, build it, then copy target/scijava-java3d-0.1.0-SNAPSHOT.jar into $IJ_HOME/jars.

At that point, you should be able to launch Fiji, and:

  1. It will warn you if any obsolete Java 3Ds are on the extensions path; and
  2. If not, the 3D Viewer should work with the new Java 3D!

Still to do

  • Fix imagej-updater and imagej-maven-plugin to understand the JOGL artifact naming convention, rather than barfing on the classifiers.
  • Migrate the ctrueden/java3d repositories to the scijava org as forks, cut releases, then update the 3D Viewer to depend on those.
  • Cut the 3D Viewer 4.0.0 release.
  • Test how it all works with Java 6.
    • If it doesn’t work (and it almost certainly won’t), then create some kind of core component that proactively handles class version conflicts, giving the user a sensible explanation—e.g.: “You are attempting to use a feature which requires Java 7 or newer. Please update your version of Java.”
  • One things are better tested, upload everything to the Fiji update site.
    • Or perhaps the ImageJ update site—after all, ImageJ 1.x ships with the 3D Viewer, so maybe ImageJ2 should do so as well.