The same opinion here!
Java3D is - like Java - a nice concept which allowes it to implement complex 3D-applications very fast and with no (low level) programming overhead. And for that the speed is really good.
People who have enough time to play around with low level solutions (like one of the different, plain OGL to Java wrappers) may be lucky with this solution. But nevertheless, they have to invest more time and efforts for less results.
And just to point to my project which uses J3D: http://www.3dchat.org ;-)
Claudio Mazzuco writes:
> No issue, no questions.
> Only some word to say that java3d is great!
I want to second this.
And now that I am a full time student again, I believe I can.
I was the main Java3D person on the team at JPL that implemented Maestro/SAP, which is one of the primary interfaces that scientists used/use to operate the Mars rovers Sprit and Opportunity.
http://mars.telascience.org (website seems to be down atm...)
We used Java3D in several parts of this software. Most prominently, the "3D View" is an interface for viewing large textured triangle mesh terrain datasets, with added annotations for up to thousands of marked points on the terrain (we call these "targets") and including an articulated VRML model of the rover.
Java3D enabled us to build an extremely robust 3D View that supports huge datasets via dynamic geometry and texture LODs, natural (at least to me ;-) interaction, and, very importantly, portability across Linux, OS X, Solaris, Windows, and (I am told, due to a heroic user community contribution) IRIX.
For those that are worried about the capabilities of Java and Java3D to handle large datasets: we typically throw around geometry and texture data which is fundamentally in the hundreds of MB range, sometimes pushing up to around 1GB in-core. In an early pre-mission test we were able to handle datasets about twice as large as some C++ OGL code on the same hardware.
The Maestro/SAP codebase is currently closed-source.
The main terrain engine in 3D View is based on J3D indexed triangle strip arrays with large interleaved vertex buffers mmapped in via NIO. Our textures are loaded and scaled with JAI (another key technology which we used extensively).
As I said, I have since left JPL to finish my education. Already I've used Java3D to great effect in several smaller projects.
"Reflector" -- An applet to model and "simulate" axisymmetric reflectors, for kids' science projects:
"VIsolate" -- an applet that computes PCB isolation routing toolpaths, optionally following the boundaries of the entity Voronoi diagram induced by the traces. Given a board design, the program computes a toolpath for a CNC mill to cut out the traces.
These run well on Linux/NVidia with recent JVM and Java3D. YMMV on other configurations, mostly because I don't care yet. (Reflector runs ok on windows and OS X, and on ATI, iirc; I think VIsolate has some UI platform bugs that I haven't fixed, and fails spectacularly on ATI, I believe due to driver bugs (*)). If you run into problems, please complain (nicely) directly to me, not to the whole list.
Statements made in this email are my own and do not reflect the policy or opinion of my former employer, the Jet Propulsion Laboratory.
(*) I am not surprised by this -- after 4 years of working with both mid-range and high-end PC gfx cards from many manufacturers, I have developed a strong bias to stick with NVidia. They just seem to consistently have the fewest bugs, especially when running novel apps, Java3D or otherwise. And just look at the tremendous documentation they supply with their Linux driver: ftp://download.nvidia.com/XFree86/Linux-x86/1.0-6629/README.txt
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.