Java3D Source Code Released

mrp101 writes "Over the past few months (aka year) the future of Java3D has been in question. Not too long ago Apple announced a port to Mac OS X, but still no official update from Sun. A few weeks ago Sun announced that they were going to release the source code and begin collecting comments for version 1.4/2.0. And today they delivered, right before the JavaOne conference. The announcement can be found here(1) and the CVS here(2). The code includes the core scenegraph, the vector math library, and Sun's own add-on utility libraries."

Comments

Testing the waters?

[Anonymous Coward]

I believe Sun is testing the waters for possibly fully releasing Java into the open source world.

3D people out there .. utlize this stuff so they'll be encouraged to release Java.

On a side (offtopic?) note. According to a member of the solaris dev team at http://blogs.sun.com/roller/page/tucker/20040618#o n_opening_up_solaris Solaris will probably be released as open source soon ..but people will foolishly ignore it, rather than implement it's plus points into Linux.

-Johan

Re:Testing the waters?

[Mithrandir]

Only the utils and examples are released under the BSD license. The core and vecmath libraries are released under licenses named Java Development License and Java Research License. These are most definitely not OSI-approved Open Source licenses.

Speed of 3D in Java?

[Anonymous Coward]

I've done my share of 3d programming, and I don't see how writing any part of your display routines in Java is a good idea when you're working on a 3d app. I know Java has gotten quite a bit faster than the initial releases, but it's still interpretted byte code, and that seems like a waste of cpu cycles when you're trying to perform complex graphics effects. Does anyone have any positive experiences with Java3D with high performance 3d applications? Games would be a good start since they are probably the hardest on the system. What about 3d CAD software as well.

Maybe some of you out there can prove my initial performance guesses wrong.

Re:Speed of 3D in Java?

[allenw]

If the final release of Looking Glass turns out to be as impressive as the demo shows, I don't think anyone will ever doubt Java as a 3D application language.

Re:Speed of 3D in Java?

[koreth]

Java hasn't been interpreted byte code (strictly speaking) for some time now. The byte code gets compiled to native code at runtime, with optimizations that are determined by the runtime behavior of the code rather than by simple static analysis.

Re:Speed of 3D in Java?

[thedigitalbean]

I have been writing 3D software in C++ for years and every so often (every release of Java) I get excited and want to port to Java. However, every time I try running simple performance tests of Java's floating point, the results are tragically dissapointing. The last time I tried (with JDK 1.4.1), Java was 2 decimal orders of magnitude (ie. 100x) slower than the identical code in C++ (interestingly, C# was 50x slower). My test was really simple involving vector math and matrix multiplication.

I did some reading and found (from a long time ago) that floating point representation in Java was really slow because of the floating point standard in the VM set forth by Sun.

My challenge is for Java advocates to publish with source a head to head comparison of floating point performance of Java vs. C++. Most of the challenges tend to focus on integer performance or memory performance, but very few people talk about floating point performance which is essential for 3D graphics.

Re:Speed of 3D in Java?

[Anonymous Coward]

The java compiler is like a meat grinder. You put steak (source code) in, and it "compiles it" into ground beef (bytecode). When you eat a hamburger, your stomach's acid "compiles" the ground beef into it's different protiens/minerals/fats/whatever (native code). That's much more efficient than rubbing the ground beef (bytecode) into your skin (using a bytecode interpreter), don't you think? Your stomach acids (JVM) break down the hamburger (bytecode) and make it run on your "platform" natively.

Re:Speed of 3D in Java?

[Laser Lou]

Java3D was used for the game Roboforge. It was also used in Law and Order: Dead on the Money.

Re:Speed of 3D in Java?

[Anonymous Coward]

Get a clue, dude. It depends on the platform. If you're running on an x86, yes, the IEEE FP standard that is used by x86 CPUs is the backward one. SPARCs support nateively the same FP format, and that's the reason Sun chose it. Intel has been bitching for years to Sun asking them to change the format to one that does not require conversion for x86 systems. If Intel had chosen the better format, they wouldn't have this problem. Try runing FP on a SPARC -- it's on par with C++ code.

Re:Speed of 3D in Java?

[Anonymous Coward]

Java FP may run well on Sparc, but do you know anybody who owns a Sparc machine? I presume my university's got a few of them, but absolutely nobody I know uses them for their own machines. And that's the crux of the issue. It's fine to say that x86 is the inferior platform and all, but the fact of the matter is that it's the platform that the vast majority of end-users use.

fav java 3d demos

[Anonymous Coward]

one of my personal favs... http://equinox.planet-d.net/java/vectorball/

Re:OpenOffice.org is NOT GPL

[Macrat]

FYI, OpenOffice.org is LGPL and SISSL. Not GPL.

Re:Java 3D is slow

[Anonymous Coward]

My understanding is that Xith 3D is a mess. It's also quite incomplete.

The primary problem with Java3D is not that it tries to be "everything". There are four problems with Java3D. First, it is synchronized everywhere, with heavy locking mechanisms. Second, it has both float *and* double environments. Third and most important, it puts an efficiency emphasis on static scenes where few things get added or deleted. Fourth, it attempts to run on both OpenGL and Direct3D, and so its underlying subsystem has an unnecessary layer of abstraction.

Open-sourcing Java3D should do a world of good. It'd give Java3D a chance to fix this stuff. First, dump Direct3D and the private OpenGL bindings it uses, and sit it directly on top of JOGL. That's no small job, but it'd make a big difference. Second, strip out the synchronization and use of doubles. That'd be enough to get it more than a match for Xith3D. What to do about its emphasis on static scenes, I dunno.

Java3D is a superset to DirectX, OpenGL

[karnat10]

I'd like to think that under the hood Java3D uses whatever hardware accelerated 3D technology is available on the current system.

So whether Java is "just another 3D library" or an abstraction layer to truly make cross-platform development easier depends on the quality of the VM.

Re: J3D is more a competitor of VRML

[Cochonou]

Java 3D uses scenegraph and branchgroup concepts, exactly like VRML. It is a "higher level" 3D language than OpenGL, and therefore C+OpenGL and Java 3D are not (maybe just for now) in the same playing fields.
Where Java3D should thrive now is rapid developpement of possibly complex 3D scenes. We're not talking of a game with pixel shaders, but for example of a simulator of a robot with a manipulating arm. The scenegraph would make it very easy to set up the arm articulations quickly.
Given the current sorry state of VRML browsers, and the immaturity of X3D, the release of Java3D could give birth to very interestings developements.
For complex game development in Java, look for Java OpenGL bindings instead.

A few references:
Scenegraph basics
X3D

Some of it is BSD, some of it isn't

[fdobbie]

If people would have the decency to RTFA:

LICENSE
-------
We are releasing the source code for the j3d-core-utils and j3d-examples projects under a BSD license.

We are releasing the source code for the j3d-core and vecmath projects under separate research and commercial license. The research license is the Java Research License (JRL). The commercial license is the Java Distribution License (JDL), a no-fee license that allows a vendor to ship a compatible version of Java 3D with or without modification.