JOGL 2 support for Ardor3D, JMonkeyEngine 3, jzy3d and NiftyGUI

Hi,

as mentioned in my post on 20th Oct. 2015 I had a sizing problem on my linux system with the up to date JOGL and Jogamp's Ardor3D continuation with the JoglSwingCanvas.. I found the point where this happens but don't know how to solve the problem correctly. This happens inside the JoglSwingInitializerRunnable of the JoglSwingCanvas. When _joglSwingCanvas.display(); is called the backend of the JoglSwingCanvas is not initialized and _joglSwingCanvas.getDelegatedDrawable() is null. Therefore a NullPointerException is thrown. If I add

        if (_joglSwingCanvas.getDelegatedDrawable() == null){
            _joglSwingCanvas.initializeBackend(false);
        }

after _joglSwingCanvas.display(); everything is working fine and the sizing is done correctly. Could this additional lines cause other problems? It's more like a workaround then a solution. I wasn't able to find the reason why this happens.

Andreas

Hi

I'll investigate tonight. I'm a bit surprised as I don't reproduce your bug.

Your fix seems to be correct, it forces the initialization on the most appropriate thread, I'll put it into the code just before _joglSwingCanvas.display(). Please can you confirm whether you have the same trouble with JoglAwtCanvas?

Hi,

I still have to try with the JoglAwtCanvas. But I'm having another problem. As told before I'm using the JoglSwingCanvas inside the Netbeans RCP. If you maximize a window there it is removed from the actual JComponent und again added to another. This means that addNotify and removeNotify is called for the JoglSwingCanvas/GLJPanel. After adding again the JoglSwingCanvas is not working correctly. I think it the same code since init() is not called again for the JoglSwingCanvas. It the same like removing and adding the JoglSwingCanvas from it's parent.

How can I avoid this.

Andreas

Is it reproducible without Netbeans Platform on your machine only with Swing?

When you remove the GLJPanel from its parent, the OpenGL context is destroyed, this is the expected behaviour. If you want to preserve the OpenGL context, you'll have to use JoglNewtAwtCanvas.

If you reinitialize the context, you'll lose what you stored into the previous one anyway.

Hi

I've just updated the binaries and the Java documentation of JogAmp's Ardor3D Continuation, it contains the following changes:
- equals() and hashCode() in the classes of bounding volumes
- pixel access in the image utilities (i.e you can get the color of a pixel in an image and modify it)
- creation of much more kinds of NIO buffers on the Java heap
- option to use such buffers in the main geometry tool
- encoding fixes (UTF-8)
- debug information generated by default
- removal of the applet support
- fix of the JoglSwingCanvas resizing
- fix of ImageLoaderUtil to allow to manage images without having to pass the extensions by using the default loader
- minor javadoc fixes
- JUnit 4.12

I advise you to use the indirect NIO buffers when the direct ones give no noticeable speedup in your use case and when you don't want to be forced to release their native resources at runtime. Numerous utilities don't really benefit of direct NIO buffers. JogAmp's Ardor3D Continuation allows to use different kinds of NIO buffers when using various tools and when loading a model, it helps to always use the "best" solution depending on the constraints.

Hi

I'm going to add STL file format support into JogAmp's Ardor3D Continuation very soon. At first, I have to fix the importer. I don't know yet whether I'll implement an exporter too.

I think I found a bug with the JOGL canvas in one of the jme3 tests. I've posted the details here:
https://hub.jmonkeyengine.org/t/jogl-support-jogl2-that-is/20891/333

gouessej wrote

Hi

I'm going to add STL file format support into JogAmp's Ardor3D Continuation very soon. At first, I have to fix the importer. I don't know yet whether I'll implement an exporter too.

If you want, I can provide you an stl reader, Julien

Mr.Marbles wrote

I think I found a bug with the JOGL canvas in one of the jme3 tests. I've posted the details here:
https://hub.jmonkeyengine.org/t/jogl-support-jogl2-that-is/20891/333

Thank you for reporting this bug. I'll see what I can do.

elect wrote

gouessej wrote

Hi

I'm going to add STL file format support into JogAmp's Ardor3D Continuation very soon. At first, I have to fix the importer. I don't know yet whether I'll implement an exporter too.

If you want, I can provide you an stl reader, Julien

gmseed, a contributor of mine, provided a STL importer ready to use with JogAmp's Ardor3D Continuation two years ago, I just have to clean up a bit his excellent code and maybe provide an exporter too :)

Just found another bug: https://hub.jmonkeyengine.org/t/jogl-support-jogl2-that-is/20891/334
Something wrong with the NewtMouseInput.

Mr.Marbles wrote

Just found another bug: https://hub.jmonkeyengine.org/t/jogl-support-jogl2-that-is/20891/334
Something wrong with the NewtMouseInput.

This is probably caused by this commit:
https://github.com/jMonkeyEngine/jmonkeyengine/commit/836bf856303dff607fd5700961c5b2766780842f#diff-1f750733002669c0916734c6e4b1ecb7

I cannot investigate right now.

Hi

I'm switching JogAmp's Ardor3D Continuation to Java 1.7. I was fed up with not being allowed to use the try-with-resources, Objects.equals(), Objects.hashCode(), java.nio.charset.StandardCharsets, ... I fixed a lot of code smells that were causing numerous warnings. I'm not interested in Java 1.8 new APIs (Stream API, ...) and language features (lambdas, default methods, ...).

I remind that you can bundle your software(s) with a JRE (OpenJDK, Oracle Java, ...). Some individuals and Azul Systems provide OpenJDK binary builds for GNU Linux, Mac OS X and Microsoft Windows. You're not forced to use the JRE installed on the system.

I suggest you to reconsider java 8.

Streams proved to me to reduce code a lot and thread management is also improved, don't underevaluate it.

I have no OpenJDK 1.8 binary builds for all supported operating systems and architectures, even Azul Systems (Zulu) doesn't provide any OpenJDK 1.8 binary build for Windows 32-bit. Switching to Java 1.8 now would prevent me from packaging my game correctly with JNDT. I don't want to rely on the JRE installed on the system.

Moreover, I know the Stream API and it wouldn't be very useful in JogAmp's Ardor3D Continuation but it doesn't mean that I find this API useless. I'm not convinced by the syntax ("->", "::") but it's possible to use the Stream API without using "->". I prefer external iteration, I find the source code heavily using internal iteration sometimes difficult to read. I think that I will use the Stream API in the future but as explicitly as possible instead of using the most concise style.

gouessej wrote

Mr.Marbles wrote

Just found another bug: https://hub.jmonkeyengine.org/t/jogl-support-jogl2-that-is/20891/334
Something wrong with the NewtMouseInput.

This is probably caused by this commit:
https://github.com/jMonkeyEngine/jmonkeyengine/commit/836bf856303dff607fd5700961c5b2766780842f#diff-1f750733002669c0916734c6e4b1ecb7

I cannot investigate right now.

I've investigated this bug a little more and found that the issue goes deeper than just that NewtMouseInput. The jogamp.newt.WindowImpl.confinePointer(boolean) actually moves the mouse cursor to the center of the screen using the warpPointer() method. Unfortunately, this mouse movement to the center of the screen is interpreted as a user action and causes the JME camera to jump. Why does the cursor need to be centered? Can it not simply be locked to whatever position it was last in?

I've got a fix for the mouse cursor auto-centering issue and created a pull request:
https://github.com/jMonkeyEngine/jmonkeyengine/pull/519

In that fix, the jogamp.newt.WindowImpl.confinePointer() is no longer used. I am manually locking the mouse cursor position, when the mouse cursor is hidden, to it's last known location. This fixes the jumping camera observed in JME.

Pull request for the v3.1 branch: https://github.com/jMonkeyEngine/jmonkeyengine/pull/520

Great job. confinePointer() shouldn't be called when gaining/losing the focus neither.

Hi

JogAmp's Ardor3D Continuation uses Java 1.7 now, the source code was updated some days ago. I'll update the JARs when the STL importer is ready. I fixed numerous warnings, some resources are better handled, the hash codes are more consistent.