Java3D 1.6.0 Released

Harvey has released a final release of Java3D 1.6.0.

This version relies entirely on the JOGL project from jogamp.org to access 3D rendering functionality, so you'll need to grab that as well.

Prebuilt jars available here: https://github.com/hharrison/java3d-core/releases/tag/1.6.0

Source code:
https://github.com/hharrison/java3d-core/
https://github.com/hharrison/java3d-utils/
https://github.com/hharrison/vecmath/


And just to let anyone who's interested know the pre1 of Java 1.7.0 is released here:
https://github.com/philjord/java3d-core/releases

The main feature of it is the addition of an OpenGLES2 pipeline, which will run on mobile devices and is "significantly" faster than the older pipeline.
But it's far less tested that the 1.6.0 Harvey just released so unless you need performance or the new pipeline stick with 1.6.0 for now.
Also it's not going to run on Android or any system that doesn't have the AWT sub system, that release is coming in the not too distant future.

This is really wonderful news ... keep up the great work!

I guess I have to use Java3D 1.7 because the following bug was only fixed in Java3D 1.7:

https://jogamp.org/bugzilla/show_bug.cgi?id=1318

But I can't find the jar files for Java3D 1.7 here: http://jogamp.org/deployment/
Where are they?

Hi

I'll copy them into deployment/java3d soon, sorry.

P.S: Actually, you have to build Java3D 1.7.0-pre1 yourself by using Phil's code until we copy it into an official JogAmp repository.

It's not urgent so I can just wait until you guys copy it into the repository.

I've copied the binary builds provided by Phil. The Java documentation will be uploaded later and I still have to update the wiki and the tutorial.

I've just copied the documentation. Enjoy :) I'll update the wiki soon.

Thanks gouessej.

But it appears that I won't be able to upgrade to Java3D 1.7 after all, because all the packages are renamed :(
In my Graphing Calculator 3D when the users save their work, the program serializes my classes which include some of the Java3D classes. After I upgraded my Java3D I get serialization exception when trying to open old files.

Yes this is a concern for 1.7.0, I haven't invested any time, but I'm sure there must be ways that you can provide a backwards compatible package naming system, some vendors of major OSS must have already hit this requirement and solved it.

SweetHome3D faces the same issue where third party plugins have been written against the 1.60 package names and in some cases it's not possible to ask the to release new plugins (along with complexity of having to careful install the correct code line of plugin).

So there's plenty of need to a solution of some sort.

I think the new package names are far clearer and more correct than javax.media which is a real throw back.

So if/when I find a solution I'll drop a note on this forum and try to follow up with people interested in getting onto the newer version.

I tried using my own suggestion here to rename packages with a script:

http://forum.jogamp.org/Dealing-with-the-outdated-java3d-libraires-on-Mac-tp4031866p4031907.html

But looks like Java3D 1.7 hardcodes access to some of the package names as I get this exception:

java.lang.IllegalStateException: No GeometryService implementation found. Please add j3d-core-utils to the classpath.
        at javax.media.j3d.Font3D.newGeometryService(Font3D.java:956)
        at javax.media.j3d.Font3D.triangulateGlyphs(Font3D.java:471)
        at javax.media.j3d.Text3DRetained.updateCharacterData(Text3DRetained.java:700)
        at javax.media.j3d.Text3DRetained.setString(Text3DRetained.java:254)
        at javax.media.j3d.Text3D.<init>(Text3D.java:276)

Yeah, that's a work around to stop the Font3D from requiring the utils jar, which causes a compilation loop.

To fix it you'll need to change the Java3D Utils and alter this class

package org.jogamp.java3d.utils.geometry;

import java.util.ArrayList;

import org.jogamp.java3d.GeometryArray;
import org.jogamp.java3d.GeometryService;
import org.jogamp.vecmath.Point3f;

/**
 * Default implementation of the {@link GeometryService} service interface.
 */
public class GeometryServiceImpl implements GeometryService {

To import and extends javax.media.j3d.GeometryService from your newly altered core project.
So although the Service loader stops a compilation cycle it still requires a developer to include the utils jar to use Font3D.




That's the only use of the Service interface in Java3D.

You'll also need to consider the Pipeline class that uses reflection to instantiate the pipeline

@Override
public Pipeline run() {
        try {
                switch (pipeType) {
                case JOGL:
                        return (Pipeline)Class.forName("org.jogamp.java3d.JoglPipeline").newInstance();
                case JOGL2ES2:
                        return (Pipeline)Class.forName("org.jogamp.java3d.Jogl2es2Pipeline").newInstance();
                case NOOP:
                        return (Pipeline)Class.forName("org.jogamp.java3d.NoopPipeline").newInstance();
                }
        } catch (Exception e) {
                throw new RuntimeException(e);
        }
        return null;
}
}

I think MasterControl and it's various property settings should be ok

The java3d.utils.scengraph.io will be totally broken I expect.

The ConfigContainer and possibly everything about ConfiguredUniverse could well break, not sure.

It would be a good start if you do get a script going and are willing to share it here.

My script is basically feeding jarjar with the following rules.txt:

rule org.jogamp.java3d.utils.** com.sun.j3d.utils.@1
rule org.jogamp.java3d.** javax.media.j3d.@1
rule org.jogamp.vecmath.** javax.vecmath.@1

But from what your explains there seem to be several hardcodes references to packages.

I agree that the new package naming is much nicer but I wonder if this is worth it the trouble.
After all, most people who use Java3D use it to be backward compatible with their older projects.
I don't think many new developers will chose Java3D when there are other options such as Ardor3D and JavaFX available. Am I wrong?

Yeah, so possibly a overwritten Pipeline and GeometryServiceImpl class in your own project would get it all to compile.

As for who uses JAva3D that's an interesting question, certainly my aspirations are for it to pick up new developers once I make it's dependency on awt optional, but of course who knows if anyone will be interested. I'm hopeful that it might find a place as a 3D scenegraph on Android, (there are only a few that are not NDK), especially if I can get the stereo features working nicely.

Yes it's worth the trouble. Now there is no risk of collision with the old Java3D 1.3 versions still installed under OS X. Anyway, we aren't allowed to use "javax" in our package name. We should have moved to a new package naming earlier.

I'm against investigating tons of time in keeping backward compatibility. Maybe we can find a solution for your specific problem. Using binary serialization was a bad idea. If you used an XML encoder, it would be more flexible.

@philjord It's nice to hear that the work on Java3D goes beyond just maintenance, keep up the good work ;)

@gouessej yes serialization has these risks but it's also a huge time saver when in development. It's okay I'm sure I can find a solution, my serializable dependencies are limited to few vecmath classes so I suppose I could just duplicate those classes in my project.

But for now Java3D 1.7 doesn't seem to offer much improvement compared to Java3D 1.6_pre 9 which I'm currently using so I guess I stick to that version. In fact the initiation of Java3D 1.7 seem to be 50% slower than _prev9. My main hope for Java3D 1.7 was that maybe you guys solved the problem with some users having old video card drivers or Microsoft video cards and getting this exception: Java 3D ERROR : OpenGL 1.2 or better is required (GL_VERSION=1.1). But I doubt that's a solvable issue unless I downgrade to Java3D 1.5 before directx pipeline support was removed from Java3D.

The problem isn't serialization, it's rather binary serialization. You can override writeObject(ObjectOutputStream) and readObject(ObjectInputStream) in your own code and call defaultWriteObject() and defaultReadObject() when no special treatment is required. If you want to control everything with no default mechanism, Externalizable is the way to go:
http://www.oracle.com/technetwork/articles/java/javaserial-1536170.html

Another solution consists in reading those files as text files, replacing the class names and then reading the resulting files with the source code taking into account the latest versions of the class.

If you use XML encoders and decoders, rather use some persistence delegates or XSLT.

Numerous bugs have been fixed since Java3D 1.6_pre 9.

runiter wrote

My main hope for Java3D 1.7 was that maybe you guys solved the problem with some users having old video card drivers or Microsoft video cards and getting this exception: Java 3D ERROR : OpenGL 1.2 or better is required (GL_VERSION=1.1). But I doubt that's a solvable issue unless I downgrade to Java3D 1.5 before directx pipeline support was removed from Java3D.

This problem cannot be solved because the main root cause comes from Intel who chose to provide half broken drivers for Windows 10 just not to prevent the migration but decided not to maintain some of them, Phil and me talked about that in a bug report. The only workaround consists in using an old JRE so that Windows 10 believes that your software isn't ready for Windows 10 but then, you might fall on unfixed bugs in those drivers and Intel stopped maintaining the corresponding Direct3D drivers on this hardware too, which means that using Java3D 1.5.2 or 1.5.1 wouldn't solve your problem and you would have to undergo all bugs fixed by Harvey, Phil, numerous other contributors and me. Moreover, I remind you that the native Direct3D renderer of Java3D was very buggy, that's why its removal was planned since Java3D 1.3. If you decide to package your software with an outdated and unmaintained version of Java3D, we won't be able to help you and this subsection of the forum is about Java3D >= 1.6.0.

The slowdown might be caused by paranoid virus scanners. At least one StackOverflow user confirmed that disabling Avira fixed the issue. You can disable automated native library loading to mitigate this issue.

Thanks but I only use the default windows anti-virus and I always disable automated native library loading anyways since I no longer do webstart and using stand-alone exe installer now.

I think the slow down is because Java3D code was changed to create Frame/Dialog and do some other extra checks in this commit to help with stereo graphics here:

https://github.com/hharrison/java3d-core/commit/8593fa0991feb9c9baa85a83269fc50c755dff80

I suppose these changes are necessary for stereo but since my app doesn't use stereo. It's not too big of a deal though as it only adds 1 second to initialization.

gouessej wrote

This problem cannot be solved because the main root cause comes from Intel who chose to provide half broken drivers for Windows 10 just not to prevent the migration but decided not to maintain some of them, Phil and me talked about that in a bug report. The only workaround consists in using an old JRE so that Windows 10 believes that your software isn't ready for Windows 10

Unfortunately this problem doesn't seem to be limited to Windows 10, I get reports on Windows 8 and 7 too.
Also this error occurs in the older JVM that I bundle with my exe installer which is Java 1.8.0_51

Please fill a bug report concerning the slowdown and thank you for the investigation.

The main problem appeared between Java 1.8 update 45 and Java 1.8 update 60 with Intel HD Graphics (Intel HD 4000?):
https://jogamp.org/bugzilla/show_bug.cgi?id=1278#c15

Using Mesa, ANGLE or SwiftShader might help in the future but keep in mind that JOGL isn't responsible for driver bugs. We do our best to work around this kind of bug but the GPU manufacturers should provide better drivers, it's their job, not ours.