Administrator
|
Yes I'm working on this as it's my mission, I'm responsible for engine support :) It's not just a pretty title to look cool during the meetings :D I'm going to fix it after a good dinner ;) I'm open to your suggestions. I will probably compare what happens when I create a display to see when the system listener should be set. Your help is welcome, I'm very glad to see a few developers using our stuff even though I know that numerous corporations use the JOGL backends of several engines... they are a bit too much silent about that :(
Julien Gouesse | Personal blog | Website
|
I've gotten a little further. If Application.startCanvas() is not explicitly called, or it's called with a false value, then the JFrame will always show and we can see the rendered scene for about 5sec. At that point the exception will be thrown because of a lock timeout in RecursiveLockImpl01Unfairish. From the stacktrace is seems the JOGL system is never notified that the canvas is being repainted from EDT and so it times out.
|
I got TestSafeCanvas to work finally by commenting a couple lines of code:
... frame.setVisible(true); // Thread.sleep(3000); // // frame.getContentPane().remove(canvas); // // Thread.sleep(3000); // // frame.getContentPane().add(canvas); ... It appears the JOGL canvas did not like getting removed/added outside of the EDT. In general, this is bad practice. Any modifications to the Swing/AWT heirarchy should be done from within the EDT, however, this works with the LWJGL canvas. |
The TestCanvas app is also working with the JoglNewtCanvas but performing some of the "canvas torture methods" such as "remove/add" or "start/stop" will cause the same crash as before.
|
I just ran some tests with scenes containing skinned meshes and the jME hardware skinning feature is broken when using the JOGL renderer (both canvas and display versions). The meshes appear distorted. When I disable hardware skinning all is fine. You can see this in TestOgreLoading, TestOgreAnim, TestOgreComplexAnim.
|
Administrator
|
In reply to this post by Mr.Marbles
I remind you that the AWT support of this other library is quite bad and has been removed from its very latest version. All those troubles are annoying because it just works flawlessly with JogAmp's Ardor3D Continuation. Thanks.
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by Mr.Marbles
I have implemented the unified renderer but I have spent no time in testing it yet.
Julien Gouesse | Personal blog | Website
|
JoglGLExt doesn't compile. There are casts from Object to primitive long. I had to change them to Long:
@Override public int glClientWaitSync(Object sync, int flags, long timeout) { return GLContext.getCurrentGL().getGL3ES3().glClientWaitSync((Long) sync, flags, timeout); } @Override public void glDeleteSync(Object sync) { GLContext.getCurrentGL().getGL3ES3().glDeleteSync((Long) sync); } |
In reply to this post by gouessej
Just tried running TestOgreLoading and the app crashes with the following exception:
Exception in thread "main" java.lang.RuntimeException: com.jogamp.opengl.GLException: Caught NullPointerException: null on thread main-Display-.windows_nil-1-EDT-1 at jogamp.newt.DefaultEDTUtil.invokeImpl(DefaultEDTUtil.java:249) at jogamp.newt.DefaultEDTUtil.invoke(DefaultEDTUtil.java:163) at jogamp.newt.DisplayImpl.runOnEDTIfAvail(DisplayImpl.java:427) at jogamp.newt.WindowImpl.runOnEDTIfAvail(WindowImpl.java:2133) at jogamp.newt.WindowImpl.setVisible(WindowImpl.java:1024) at jogamp.newt.WindowImpl.setVisible(WindowImpl.java:1029) at com.jogamp.newt.opengl.GLWindow.setVisible(GLWindow.java:499) at com.jme3.system.jogl.JoglNewtDisplay.createGLFrame(JoglNewtDisplay.java:67) at com.jme3.system.jogl.JoglNewtDisplay.privateInit(JoglNewtDisplay.java:147) at com.jme3.system.jogl.JoglNewtDisplay.create(JoglNewtDisplay.java:168) at com.jme3.app.Application.start(Application.java:446) at com.jme3.app.Application.start(Application.java:407) at com.jme3.app.SimpleApplication.start(SimpleApplication.java:132) at jme3test.model.TestOgreLoading.main(TestOgreLoading.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140) Caused by: com.jogamp.opengl.GLException: Caught NullPointerException: null on thread main-Display-.windows_nil-1-EDT-1 at com.jogamp.opengl.GLException.newGLException(GLException.java:76) at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1311) at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:1131) at com.jogamp.newt.opengl.GLWindow.display(GLWindow.java:680) at jogamp.opengl.GLAutoDrawableBase.defaultWindowResizedOp(GLAutoDrawableBase.java:259) at com.jogamp.newt.opengl.GLWindow.access$200(GLWindow.java:119) at com.jogamp.newt.opengl.GLWindow$2.windowResized(GLWindow.java:141) at jogamp.newt.WindowImpl.consumeWindowEvent(WindowImpl.java:3682) at jogamp.newt.WindowImpl.sendWindowEvent(WindowImpl.java:3616) at jogamp.newt.WindowImpl.setVisibleActionImpl(WindowImpl.java:1003) at jogamp.newt.WindowImpl$VisibleAction.run(WindowImpl.java:1015) at com.jogamp.common.util.RunnableTask.run(RunnableTask.java:150) at jogamp.newt.DefaultEDTUtil$NEDT.run(DefaultEDTUtil.java:372) Caused by: java.lang.NullPointerException at com.jme3.system.jogl.JoglNewtDisplay.init(JoglNewtDisplay.java:162) at jogamp.opengl.GLDrawableHelper.init(GLDrawableHelper.java:641) at jogamp.opengl.GLDrawableHelper.init(GLDrawableHelper.java:663) at jogamp.opengl.GLAutoDrawableBase$1.run(GLAutoDrawableBase.java:430) at jogamp.opengl.GLDrawableHelper.invokeGLImpl(GLDrawableHelper.java:1275) ... 11 more |
It seems the AtomicBoolean renderable is false when JoglContext.internalCreate() is called, so JoglContext.initContextFirstTime() is not called and therefore the renderer is never initialized.
|
Administrator
|
In reply to this post by Mr.Marbles
It should work better now.
Julien Gouesse | Personal blog | Website
|
Ok the app doesn't crash now, but I can't get anything to render. I've tried several of the jME test apps and they're all loading up with a blank display/canvas.
|
Administrator
|
I'll try to fix that as soon as possible.
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by Mr.Marbles
I have temporarily re-enabled the legacy renderer until we succeed in fixing the unified renderer, you just have to uncomment one line in JoglContext to change that. I have debugged a bit the code, I'm 100% sure that the problem comes from the renderer itself, not from the caller.
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by Matthew
Hi
It's now possible to use a subset of JogAmp's Ardor3D Continuation with a compact profile since Java 1.8. The only sub-projects requiring the full JRE are those based on AWT: ardor3d-awt and ardor3d-jogl-awt. There are a few optional classes in ardor3d-terrain depending on AWT. ardor3d-collada and ardor3d-savable requires the "compact2" profile because of their dependency on javax.xml and maybe SAX. ardor3d-collada no longer uses any deprecated classes of JDOM 2. Last but not least, there is no longer any GLException thrown when exiting the demos. Enjoy! I still have to update the documentation and the binaries, the source code is up to date.
Julien Gouesse | Personal blog | Website
|
Any updates on the JME port? Do you think there will be a working JOGL renderer for JME 3.1 before the end of the year?
|
Administrator
|
It's already working but with the legacy renderer. I just need to find why the new unified renderer doesn't behave like the older one. I plan to fix it before the end of September.
In the meantime, you can try to modify a few things in the way the shaders are handled. Compare the code of the both renderers, I'm sure that there is something quite dumb that prevents the latter from working.
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by Mr.Marbles
Look at this:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-jogl/src/main/java/com/jme3/renderer/jogl/JoglRenderer.java#L2267 and this: https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-jogl/src/main/java/com/jme3/renderer/jogl/JoglGL.java#L523 Then, reenable the new renderer: https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-jogl/src/main/java/com/jme3/system/jogl/JoglContext.java#L195
Julien Gouesse | Personal blog | Website
|
In reply to this post by gouessej
Are there any side-effects to using the legacy renderer with JME 3.1? For example, I remember in my tests there were issues with the instanced nodes. And what about the canvas support, any problems to expect there?
|
Administrator
|
You don't benefit of the bug fixes done in the unified renderer when using the old renderer. It's just temporary.
Julien Gouesse | Personal blog | Website
|
Free forum by Nabble | Edit this page |