Why so much confusion over Java3D?

There seems to be a lot of confusion over Java3D, mainly in how one implements it into their preferred IDE, and how to deploy it to end users. Perhaps this is why, in comparison to other 3D graphics libraries for java, this one doesn’t fare to well in the popularity contest.

Anyway, to my question; what makes Java3D different than other graphics libraries, LWJGL comes to mind. Why can’t you simply add Java3D to a projects class path like you would with any other 3rd party library. Personally I prefer the Eclipse IDE, and adding jars to the class path is very easy. Even adding LWJGL was a breeze, add the jars, and reference the natives folder for your operating system. What makes Java3D different in a way that forces developers, and end users alike, to go through a complicated installation process?

If what I mentioned above is not true, and you can simply add Java3D to a projects the class path (and distribute a fully working .jar), why is this method not documented, well known, or even mentioned?

Finally, how would one deploy an application / applet with this library, if in fact it needs to be ‘installed’ as the documentation says. Would one have to tell end users, “Wait! You have to download, and install this before you can even play my game!” which to a person new to java, or someone who knows nothing of programming and only wants to play your game, this may seem overwhelming.

Let me finish by clarifying that I don’t need a ‘tutorial’ on installing Java3D, I am simply bringing up some questions for discussion that haven’t been addressed elsewhere to my knowledge.

It doesn’t help that Java3D is dead. It’s being kept alive in some forks here and there by independent devs, but as an official project, or anything going beyond pure maintenance by said devs, it’s run down the curtain, shuffled off this mortal coil, and joined the choir invisible.

As for it coming in a big cumbersome installer, that’s just how “system-wide” software for Windows platforms gets distributed for end-user installation. LWJGL doesn’t have this conceit of installing globally, and aims squarely at developers who will bundle lwjgl with their app instead.

No it certainly doesn’t. I was just curious about the differences and reasons why. I’m a programmer, question everything, you understand, haha!

It’s best to just leave Java3D in its measly grave and use more mature libraries. LWJGL is not a graphics library, it is only a simple binding to OpenGL. An equivalent to Java3D would be JMonkeyEngine, Ardor3D, or libGDX, all of which use LWJGL underneath to access OpenGL.

Java3D is exactly like all other projects. Download the zip binaries from here: http://java3d.java.net/binary-builds.html and put the jar files to the class path and the native files in java.library.path.

Sure, there is also an installer. I think there are historical reasons why it exists. Java3D is really old and back in the day it was common practice to put the libraries in the jre. At least the official sun ones. This was never a good idea, and now we know better.

It is too bad that Java3D is dead, or perhaps not, seeing that there are much better solutions now. I do like the libraries implementation though, it has the same feel as Java SE (for obvious reasons) I suppose one could develop an engine over top of LWJGL to accomplish the same intuitive java like methods while still accessing openGL.

All I am saying is that I prefer this:

Model model = new Model(obj loader);
gl.drawModel(model, x, x, z);

opposed to this:

… vertexes

the above is pseudo code of course.

Perhaps my next long term project will be creating something like that…

There are libraries that achieve that kind of code :wink:

jMonkeyEngine and Ardor3D are two engines you should look into for high level work. LWJGL is raw OpenGL, much lower level.

I have used JME3, I find it to be very bloated… not necessarily a bad thing if you need all of those features, but I like to keep things simple. not to mention the complete lack of documentation if you choose not to use their SDK. Come to think about it, most engines have a lack of documentation. Currently I am working with JPCT. It is pretty intuitive once you know what classes to use, but again there is a serious lack of useful documentation. I have literally spent entire days just looking at the java doc!


Sorry to refresh this thread. Java3D is not dead and we already plan to implement some new features, we won’t provide only maintenance releases.

JPCT is closed source which does not help especially because the lack of documentation. When an open source engine lacks of doc and tutorials, you can still look at its source code to understand how it works. Ardor3D has a very few tutorials but the Java documentation is quite good and it’s provided with a lot of simple examples and with a few moderately complicated examples. I used one of them as a starting point to port my game from JMonkeyEngine to Ardor3D.

Edit.: JOGL renderers are available for all engines and middle-level APIs ra4king listed except JMonkeyEngine 3 (JMonkeyEngine 2 works fine with mine).

update to 1.6 and then I might take another look at it, haha!

What is fun in what you said? Keep in mind that I work on it on my spare time. It already works with Java 1.6. What do you mean exactly? The next release will be called Java3D 2.0 if I make some major changes in the public API.

Do remember to get permission from Oracle before using their trademark :slight_smile:

I sense that you took offence to what I said, let me assure you that I meant none.

At first, I’m not liable for this project. I’m not a lawyer, I see what you mean. JOGL already existed before Sun Microsystems invested in it whereas the situation is a bit different with Java3D.

@Harvey Maybe you will have to find another name for this scenegraph.

Ok, sorry, maybe I overreacted.

Got any good ideas for a name?

In any event, I finally got the java3d offscreen rendering going, so I’m likely going to start running the jogl2
backend in my day-to-day use @work…thanks again for the roadmap (and patches) to get it converted.


Blah, what kind of flame war is that? This is the Internet. You guys are doing it wrong!

Hahahahahahaha…! Here, have a medal for that one! XD

I’ll help out. Scenegraphs = good for art-like packages. Scenegraphs = worst way on the planet for simulations. Any better?

Nah, not controversial enough.


Cas :slight_smile: