how to run jogl+j3d successfully?

Dear all,
I was very glad to detect your works for j3d+jogl, close to my current job to "reanimate" a  j3d software I'd developed 6 years ago so I try to check it out. But at the moment without any success - or may be some partial ones...

I am quite sure that it is just any silly error of mine, so I try to explain what I did and got

I'm working on win7-64 bit and put all of the following jars in the lib/ext Folder:
(those 32bit libs are for my try using a 32bit mashine - but same results)
vecmath.jar, j3dcore.jar, j3dutils.jar, jogl-test.jar, gluegen.jar, gluegen-rt.jar, gluegen-rt-natives-windows-amd64.jar,
gluegen-rt-natives-windows-i586.jar, joal.jar, joal-natives-windows-amd64.jar, joal-natives-windows-i586.jar
joal-test.jar, jocl.jar, jocl-natives-windows-amd64.jar, jocl-natives-windows-i586.jar, jogl-all.jar, jogl-all-mobile.jar,
jogl-all-natives-windows-amd64.jar, jogl-all-natives-windows-i586.jar, jogl-all-noawt.jar

the jogl gear example works and is able to be compiled...so jogl seem to work, but j3d did not :(
HelloUniverse, neither the Morphing j3d Example were running...they're able to be compiled but when they should start I just get that:
3D [dev] 1.6.0-pre1-daily-experimental daily
Message and nothing else happend...no exit just hanging...
I'd realized the posting of ylliac but not the solution...
I'd try at jdk 1.6.22 and 1.7_u3 using the newest nvidia driver
I got the jogamp-all-platforms from:
http://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z
and the j3d jars from:
http://cloud.github.com/downloads/hharrison/vecmath/vecmath.jar
http://cloud.github.com/downloads/hharrison/java3d-utils/j3dutils.jar
http://cloud.github.com/downloads/hharrison/java3d-core/j3dcore.jar
...hopefully the correct combination....

sorry if the question is silly but it's my first time since 4 years back to java...and many knoledge seem to be lost in the past...
kind regards
rolf

Hi

gmrolf wrote

I'm working on win7-64 bit and put all of the following jars in the lib/ext Folder:

Never do that, it is very dirty and can cause conflicts with other versions when using applets and Java Web Start.

You should read my tutorial.

gmrolf wrote

Message and nothing else happend...no exit just hanging...
I'd realized the posting of ylliac but not the solution...

There is a problem of freeze but Harvey has not found a solution as far as I know.

gouessej wrote

Hi

gmrolf wrote

I'm working on win7-64 bit and put all of the following jars in the lib/ext Folder:

Never do that, it is very dirty and can cause conflicts with other versions when using applets and Java Web Start.

You should read my tutorial.

I'd never (realized) trouble with that but anyway...I did and I'd set the classpath to an other directory, where all desired jars are, then I stumbled over
"Simply put the JARs above (except those whose name contains the word “natives”) into the classpath."
in your tutorial
what should be made with "those natives"? Where they has to be put?
...now here with win764 + jdk 1.6.22-64 bit the jogl gears example runs as desired
(on that computer j3d should run "normally" until jogl+hhmod_j3d will replace everything - some really sudden presentations should be madeable...)

but on my test computer
win7-64 with jre7_3(32bit) it won't run...and just throws a ClassNotFoundException for
javax/media/opengl/GLEventListener

could this be happend when using jre7? I am curios because it is the onliest diference

anyway I'll try at monday if j3d+jogl will work at win7-64 & jre-32-1.6.X

best thanks
rolf

Just don't put any JARs into the VM, that's the point.

Put the JARs whose name contains the word “natives” into the same directory than the others but not in the classpath. I will be more explicit in my tutorial.

If you use the RC10, the main JOGL JAR is called jogl-all.jar. If you use an outdated version, it is called jogl.all.jar. You have to take care of that when setting the classpath so that javax.media.opengl.GLEventListener can be found by the class loader. Your problem has nothing to do with the version of Java. If you follow my tutorial, you will download all JARs and if you use a 32 bits JVM on 64 bits machine, you need 32 bits native libraries.

Edit.: I have just edited my tutorial to clarify what you have to do with JARs.

OK I tried it several times without bigger success...
i put all jars into a directory and took any "non-native"-called jar into the classpath
(    j3dcore.jar     j3dutils.jar    vecmath.jar    jogl-all.jar    joal.jar    gluegen-rt.jar   )
JOGL works fine and nice (the Gears example), but when starting the HelloUniverse or an other Example
made for java3d the onliest thing I'll get is: (also tried: Morphing, GearBox, Applet3D
"3D [dev] 1.6.0-pre1-daily-experimental daily"
and a waiting cursor - but nothing else...

Just when I use the FourByFour Example it differs...the above message occurs, but
also
two NullPointerExceptions before
then a blank Frame opens with nothing inside (everything is grey...)

then the following error-text:
Exception in thread "J3D-Renderer-1" java.lang.NoSuchMethodError: javax.media.nativewindow.GraphicsConfigurationFactory.getFactory(Ljavax/media/nativewindow/abstractGraphicsDevice:)Ljavax/media/nativewindow/GraphicsConfiguration(JoglPipeline.java:8271)
          at javax.media.j3d.JoglPipeline.getBestConfiguration(JoglPipeline.java:8000)
          at javax.media.j3d.Renderer.doWork(Renderer.java:507)
          at javax.media.j3d.J3d.J3dThread.run(J3dThread.java:270)

the same will happened, when I call a tiny j3d soft I'd wrote...just the swing-gui elements will be shown
no canvas3d will be added to the Frame. When Closing the app with the x-button (closingadapter) it runs into an nullpointerError AWT so seem to be a swing problem...

When Starting (from j3d example) jcanvas3d just the message above occurs and the swingUI occurs but without any function noch checkbox is selectable neither deselectable...

OS win7 64-bit with JRE 1.7.0_05, latest nvidia drivers
those jogl-jars and j3d jars from your Blog
 (btw. now better undesrtandable how to do with "native" jars )

I'll gave a try tommorrrow with a xp32 with jdk1,6...
at the moment I couldn't see anything which I'd mistaken..
everything is controlled and it seem that java find the j3d jars...otherwise it'll end all in NoClassDefError...so should be something inside...
if you got any ideas what to do - just let me know.
I am greedy to get it to run,
best wishes
rolf

There is a conflict with another version of Java3D and/or I fixed a bug in Java3D during Siggraph, maybe Harvey has not yet integrated it:
https://github.com/hharrison/java3d-core/issues/4

Please check that you have copied no third party libraries into your Java virtual machine (lib/ext folder).

ok...sounds that I got the bug inside....
is there the updated jar anywhere?

In the ext folder are some other jars e.g. used by our remote sensing software also the "famous" qtime.zip asf...
it's impossible to throw them somewhere else - otherwise dependend software will not work again. They're installed during any installation.
Or you mean just for the test-envirionment - this I could produce tommorrow, when I got a fresh-but older-mashine

you scare me about this....do you have any source/articles for these potential lib/ext Folder problems...as I told the last (uff) 12 years - I haven't any troubles with that ..I'd put not masses of jars inside but a few - without any troubles...
thanks!

I'm sorry, I used them during Siggraph with another machine, I don't have these JARs anymore, you will have to rebuild Java 3D yourself or contact Harvey on Github.

lib/ext folder is the directory reserved for official extensions, they are treated as system libraries, it is not a trivial difference in term of security. When you use any Java application, Java tries to use them first. If any Java application or applets needs to use another version of a third party that should have never been put into this directory, it will use the version in lib/ext instead of the one in the classpath. Putting everything into lib/ext defeats the purpose of the classpath. "Optional packages" or "standard extensions" should be used only for frozen APIs. Some softwares use none of these mechanisms to retrieve classes, they build their own system class loader with their own path, for example Apache Tomcat does so.

Just look at StackOverflow, some people already gave similar answers. Using the classpath is not difficult and I have wasted a lot of time with students and engineers with messy environments when using JOGL and Java3D. The problem is that even some commercial softwares wrap some existing APIs and put them into this directory...

If you're really convinced I'm totally wrong, just put JOGL 1.1.1a JARs into lib/ext and try to run an applet using JOGL 2.0...

gouessej wrote

I'm sorry, I used them during Siggraph with another machine, I don't have these JARs anymore, you will have to rebuild Java 3D yourself or contact Harvey on Github.

I gave a try on waiting for harvey...loads of other works are here which have to do... the rebuilding could be a solution but I have to remind how to do that...long time ago... on the other hand I believe will be nice if your tutorial links point to the correct jars...so waiting for Harvey would be the best solution I believe. he told me that he'll have a look inside here one ore the other day...if not I try to reproduce how to build it...

gouessej wrote

lib/ext folder is the directory reserved for official extensions, they are treated as system libraries, it is not a trivial difference in term of security. When you use any Java application, Java tries to use them first. If any Java application or applets needs to use another version of a third party that should have never been put into this directory, it will use the version in lib/ext instead of the one in the classpath. Putting everything into lib/ext defeats the purpose of the classpath. "Optional packages" or "standard extensions" should be used only for frozen APIs. Some softwares use none of these mechanisms to retrieve classes, they build their own system class loader with their own path, for example Apache Tomcat does so.

OK, sounds logical! as I am more a some-times-programmer I'd never stumbeld over that. When developing any tools I try to put any needed 3rd party jars directly in the folder of the Source, so it is save that only that version will be token. If the "." is in the classpath (...) The other Point  I'd (may) never realized - but good to know and would be integrated in my future.

gouessej wrote

Just look at StackOverflow, some people already gave similar answers. Using the classpath is not difficult and I have wasted a lot of time with students and engineers with messy environments when using JOGL and Java3D. The problem is that even some commercial softwares wraps some existing APIs and put them into this directory...

If you're really convinced I'm totally wrong, just put JOGL 1.1.1a JARs into lib/ext and try to run an applet using JOGL 2.0...

using of classpath isn't a magic thats true - wasting time is not a good thing - so you won 2:0  
thanks for explanation!
best wishes
rolf

Providing my own JARs and posting different links would just add much more confusion. I really hope Harvey will fix that bug as soon as possible, it is not very difficult, really.

Have pushed out some updates to Java3d, but it still requires -rc9 of jogl.

I've been giving some thought to the lockup problems people have seen and finally think I have the culprit.

The JoglPipeline does its own capability querying directly relying on an AWT canvas, and relies on getting
everything done on the AWT event queue.  I'm pretty sure that jogl2 provides all the capability querying
needed and am trying to remove this bit of code.

Once I deal with that task, I'll look into the API changes for -rc10.

I forgot to push out some updated jars, will do so when I'm back at home tonight.

Thank you Harvey. Let me know if you have any problem with the changes to support the RC10.

I also pushed out an update removing the use of the com.sun.JPEGEncoder/Decoder bits in the j3d-utils
part and have closed the issue you opened in the github repos.

That's good news Harvey, looking forward to an RC10-compliant version without lockup! :)

I've pushed out an updated build (1.6.0-pre3) to the usual place, this one requires JOGL2-rc10 or newer so you'll need a newer JOGL as well.

Please let me know how it goes.

Using RC10 and newest jar builds on github, I still get a hang, with:

3D [dev] 1.6.0-pre3-daily-experimental daily

AWT-EventQueue-1 - Info: NativeWindowFactory.<init>
Threading: jogl.1thread null, singleThreaded true, hasAWT false, mode ST_WORKER, plugin null
GLProfile.initSingleton(firstUIActionOnProcess: false) - thread J3D-Renderer-1
java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1342)
        at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:135)
        at javax.media.opengl.GLProfile.initSingleton(GLProfile.java:199)
        at javax.media.opengl.GLProfile.getProfileMap(GLProfile.java:1914)
        at javax.media.opengl.GLProfile.get(GLProfile.java:848)
        at javax.media.opengl.GLProfile.get(GLProfile.java:877)
        at javax.media.opengl.GLProfile.getMaxFixedFunc(GLProfile.java:683)
        at javax.media.j3d.JoglPipeline.getDefaultProfile(JoglPipeline.java:6248)
        at javax.media.j3d.JoglPipeline.getBestConfiguration(JoglPipeline.java:7907)
        at javax.media.j3d.Renderer.doWork(Renderer.java:503)
        at javax.media.j3d.J3dThread.run(J3dThread.java:270)
J3D-Renderer-1 - NativeWindowFactory.initSingleton(false)
JAWTUtil initialization (JAWT/JNI/...
JAWTUtil.getJAWT(tryOffscreenLayer false, tryOnscreen true)
OGLUtilities.UNDEFINED = 0
OGLUtilities.WINDOW = 1
OGLUtilities.PBUFFER = 2
OGLUtilities.TEXTURE = 3
OGLUtilities.FLIP_BACKBUFFER = 4
OGLUtilities.FBOBJECT = 5
Checking for Java2D/OpenGL support
Java2D support: default GraphicsConfiguration = sun.awt.X11GraphicsConfig
JOGL/Java2D integration disabled

elotter, it is fixed in the next RC (RC11) but we have to test it a bit more before pushing it.

Excellent news Julien, looking forward to it - thanks for the effort you and Harvey are putting into this.

Regards,
Ernest

I had very little to do with it, this was Sven/Julien's work, I just try to keep up with any API changes.

Julien/Sven - can you explain a bit or point me at the commit that fixes this, I'm very curious what the problem was.

Harvey

On 09/26/2012 08:52 PM, hharrison [via jogamp] wrote:
> I had very little to do with it, this was Sven/Julien's work, I just try to
> keep up with any API changes.
>
> Julien/Sven - can you explain a bit or point me at the commit that fixes this,
> I'm very curious what the problem was.
>

I assume Julien assign this 'hang' w/ Bug 616 (what a number),
i.e. XInitThreads() call.

~Sven

> Harvey