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:
- Java 3D 1.6 is built on JOGL2, a modern 3D graphics framework for Java.
- Its native library dependencies are managed in more robust way which does not require anything to be installed as a Java platform extension into
- 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.
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.dirsfor 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:
- Check out the
jogl-java3dbranch of fiji/3D_Viewer.
- Check out the
mavenbranches of ctrueden/java3d-core, ctrueden/java3d-utils and ctrueden/vecmath.
mvn clean installvecmath, then java3d-core, then java3d-utils, then 3D_Viewer.
mvn dependency:copy-dependenciesin 3D_Viewer to copy all the needed JAR files into
Unfortunately, you cannot use the
imagej-maven-plugin as-is to copy them into an ImageJ installation (via
-Dimagej.app.directory=...), because it gets confused about all the JOGL artifacts with classifiers. So instead you must then:
- Copy all JARs from
$IJ_HOME/jars, except for
ij-1.49*.jar(there is already a newer version).
$IJ_HOME/pluginsand delete the old
Finally, to be safe, you should:
- Check out
scijava/scijava-java3d, build it, then copy
At that point, you should be able to launch Fiji, and:
- It will warn you if any obsolete Java 3Ds are on the extensions path; and
- If not, the 3D Viewer should work with the new Java 3D!
Still to do
imagej-maven-pluginto understand the JOGL artifact naming convention, rather than barfing on the classifiers.
- Migrate the
ctrueden/java3drepositories to the
scijavaorg 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.