I've been working on the build scripts in preparation for moving Java3d to the autobuild system here at jogamp,
in the meantime, I've finally gotten it building well enough to release some prebuilt jars from the current state of
I suppose I should add that the surface rendered in the above image was extracted using OsiriX (http://www.osirix-viewer.com/index.html) from a sample data file provided for that program - all freely downloadable.
I still can't debug in the sources but I had a ClassNotFoundException when simply creating a new BranchGroup() before doing anything else. This ClassNotFoundException is only viewable in debug and I haven't found what is the missing class.
So it must be a problem in my configuration and not in your code ;)
I'll keep trying to make it work ...
On 05/30/2012 11:37 AM, ylliac [via jogamp] wrote:
> This is my configuration under eclipse :
> I tried to define the native location of jogl and gluegen but it doesn't
> change anything.
> I downloaded the sources from the master branch of the git repository but it
> doesn't seem to be the source used to build the jars (eclipse step into a
> comment ...).
> Is this the right branch ? How can I get correct sources of the released jars ?
As the wiki describes (Eclipse development),
you should attach the source zip files to their
corresponding JAR files. This will allow you to have
a proper Java API documentation and you can also browse
the source code for more clarification.
This feature is usually available with all Java IDEs.
I have been successfully using (porting, no new development) Java3D via the prebuilt jar files. You can see the results of my stand-alone-visualization app above, and over the past couple of weeks, I successfully moved that into a free window of my main app (didn't mess with heavy/lightweight issues). Anyway, I created packages for Linux, OS X, and Windows that copy the program .jar and system-specific files into a user-defined directory. Results...
1) OS X: I was developing on a MacBook Pro upgraded/migrated to Lion. Running after the install ran into conflicts due to multiple, identically named classes. Problem - my system had some old j3d files installed in /System/Library/Java/Extensions. Moving the j3d*, libj3d*, and vecmath* to a subdirectory fixed the problem.
2) Another user tried to install it on their newer MacBook Pro. Curiously, everything appeared to work except Mouse Button 1 for scene rotation. Upon my return home, I had the same problem on my older iMac with a clean install of Lion. Solution - same as #1 for my home system. Haven't heard from the other user. I suspect it is the same.
3) Alas, the program wouldn't work on Windows 7 and a basic Ubuntu installation running in VirtualBox machines on my MacBook. For that setup, Windows only supported OpenGL 1.1 and Java3D minimally requires 1.2. The program would crash-and-burn on Ubuntu with many exception messages I did not try to decipher.
4) A number of folks did the above on current Windows systems (probably 7) with no problems.
5) I just did an install in our computer lab on Red Hat Enterprise Linux Workstation release 6.2 (Santiago)
set up specifically for 3D graphics - no problem and it was impressively fast.
PS: Transparency seems to work much better than before. Not sure if it is opengl, jogl2, or java3d, but very nice for mid alpha values on up.
Sure, on my github page, if you go to the master branch, there should be a link for 'Download as zip-file'
which will get you the contents of the tip commit on my master branch, that is what I built from.
If you have any problems with that, I can generate you a source jar when I get home this evening.
Lordsmoke, you just have to update your driver under Windows 7 instead of using the crappy default driver provided by Microsoft.
One would think. But, I'm not sure the situation is as clear as one might hope. a) I am not a usual Windows user for some years, b) I am running in VirtualBox on a MacBook Pro. It appeared that upgrading involves a video-specific driver, but the only indication of the VB driver (from within windows) I saw was "generic" and it wasn't clear if installing for my Mac graphics would work. I had plenty of more productive things to do at the time. Would appreciate anyone who could point the direction. Otherwise, I will look into it at a later date. Best, LS
I think it's somewhat more subtle than that, he's running windows _inside_ VirtualBox on his Mac, who knows what
kind of virtual hardware it presents to the Guest OS, I don't think VirtualBox does GPU virtualization, so it may only be
presenting itself as some generic piece of hardware.
I'm not sure if there are any VirtualBox modules that allow GPU passthrough?
Running JOGL apps on guest operating systems inside VMWare or VirtualBox uses a software-emulated OpenGL which is usually an older version. For example, last time I checked inside VMWare the GL string was "OpenGL version string: 1.2 (1.5 Mesa 6.5.1)". JOGL as a whole should still work (though we occasionally get bugs like https://jogamp.org/bugzilla/show_bug.cgi?id=493), but if you try to request a GL 2.0 context and don't check for errors cleanly, you might crash.
To my knowledge, VMWare and VirtualBox do not do GPU passthrough from inside the VM to outside. The latest version of Google's Android emulator does, so it is possible. But it's a security issue for a "real" VM -- you can crash or exploit the host by issuing broken GL calls that go directly to host hardware :)