JOGL Support (JOGL2 that is)

@gouessej said: Abstracting windowing stuffs is easy if and only if you don't allow the end users to modify the resolution, if you allow only the use of the default virtual monitor. @Momoko_Fan seems to talk above several renderers for the desktop whereas you talk about a single renderer :s I understand that you want the jME users to be "clients" of the jME API by wrapping NEWT or anything else.

Momoko is talking about different platforms renderers, i.e. desktop, iOS, Android, PS3 etc. Imo something like NEWT is backwards for us because the window frame is in almost all cases handled by the OS in the end and the programming environment already allows managing it. On desktop systems its convenient theres NEWT but for Android and iOS its kind of annoying to have an opaque library handle the native windows. On iOS for example the user can place and use the window any way he likes using XCode, on Android he can do that in the Android code of the application using the Android API.


Actually, NEWT doesn’t prevent you from accessing the android.view.SurfaceView under Android.



I’ll have to switch to JOGL 2.2.4 soon, it contains numerous fixes including some impacting lots of Intel chips under Windows in offscreen rendering.

The next version of JOGL (probably 2.3) will fix once for all a very annoying problem under OS X by moving the classes from* to some other packages:

Apple goes on shipping a very old version of Java 3D even with OS X 10.10, this obsolete version comes with JOGL 1. As these libraries are installed as extensions, they are loaded in priority and they cause conflicts with other versions. It impacts those who still use Apple Java (which is deprecated since OS X 10.6), I’m not sure it impacts those who use OpenJDK or Oracle Java.

As we don’t want to make the same mistakes again, please avoid copying the JARs of third party libraries into the JVM (especially jre/lib/ext), into any directory mentioned in the CLASSPATH variable environment (use -cp or -classpath instead) and into any directory used by the extension mechanism. This advice applies to other operating systems too.

Best regards.



I will probably have to disable HiDpi on Retina displays by default. When it’s on, pixel units and window units are different, this information is available in JOGL but it’s tricky to take it into account in an engine. I have found no way of using only pixel units everywhere and using window units with a non unit surface scale would drive the mouse management inaccurate. The coordinates of the mouse events are in pixel units whereas the screen dimension(s) and the windows are in window units.

Please let me know whether you need to use HiDpi.

Best regards.



Sorry for the delay. I’ve just updated the JogAmp backend, it now uses JOGL 2.3.1. I have to check whether some fixes haven’t been ported to this backend, I have to implement the support of HiDpi and to follow the unified rendering architecture if it is possible.

In the future, I’d like to put this backend into our Maven development repository and maybe on Maven Central.

By the way, Gradle works very well in Eclipse, it’s a pleasure to use it :slight_smile:



I haven’t worked on the unified renderer yet and I have to use JOGL 2.3.2. I’ll try to find some time to update the JOGL backend at the beginning of September.

Please contact me on our official IRC channel, our official forum or by email if you need some help. I’m rarely on this forum and when some JOGL users make spelling mistakes when writing my pseudonym, I receive no alert. My little presence on this forum doesn’t mean that I have no time for the maintenance and the development of this backend. It just means that I have almost no time to spend on all forums of the web, rather come to us.

Moreover, my password became suddenly invalid and I had to reset it. It’s safer not to contact me on this forum.


Hi. An untested change on the gamma correction caused a regression reported by Mr. Marbles during this night, I have found a fix this morning, it will be committed in about 11 hours:

Sorry for this disturbance.


Hi. I’ve just fixed the regression caused by a change on the gamma correction and I’ve added the support of DebugGL for OpenGL ES 3. Enjoy :slight_smile: JoglNewtDisplay and JoglDisplay are working anew but there is still something wrong with JoglNewtCanvas and JoglCanvas (just a NullPointerException). The old-style JOGL renderer doesn’t work with TestInstanceNode because of a bound VBO in a location in which it should be unbound, I’ll fix it by implementing the unified renderer, maybe I’ll have a few questions to ask to some core developers about it.

By the way, I thank a lot @Mr_Marbles for his precious help.


Thanks Julien :wink:


Thanks @gouessej
Implementing the unified renderer is very important, as its already supported by all platforms (LWJGL, iOS, Android) except for JOGL. Some features that are added to the engine might only be supported by the unified renderer.


@nehon You’re welcome, I should have read more carefully what you wrote in the comment of your commit, you mentioned that it was untested with JOGL.


@Momoko_Fan As the old-style renderer has been removed from the other backends, the fixes are only in those unified renderers, I understand that it’s the same for the new features. I assume that it’s similar to what has been done in LibGDX for several years, it should work.

I’d like to rename the sub-project, “jme3-jogamp” would be a better name as it uses both JOGL and JOAL (maybe JOCL one day?), it would be more consistent with LibGDX.

I see that there are more and more developers interested in non gaming applications with multiple windows. Should I plan to port the recent changes I did in LibGDX and what I did for a long time in JogAmp’s Ardor3D Continuation? It would improve the interoperability with SWT, AWT, Swing and OpenJFX (JavaFX). GLJFXPanel will probably be implemented before the first stable release of Java 1.9, I have to keep it in mind too. Actually, instead of providing only one AWT canvas, one AWT display, one AWT-free canvas and one AWT-free display (which was the case in Ardor3D 0.9), I provide all available canvas and I separate them into several sub-projects so that it remains modular and it helps those who use the compact profiles and the work of the small VM JEP. It will be relevant if and only if JMonkeyEngine doesn’t stay focused on games.

Last but not least, splitting the JogAmp backend to isolate the AWT-free part would help to use it in environments not supporting AWT, for example Android :smile: Then, the JMonkeyEngine context for Android would require a few changes to be able to use JOGL optionally instead of AndroidGL. Actually, this is what I mean by “unified renderer”, a single renderer for both desktop and mobile environments.


Hardware skinning is currently broken with the JOGL renderer. The meshes look distorted. A workaround is to disable hardware skinning on the skeleton control.


Thanks. I really have to implement the unified renderer.


@Momoko_Fan I’ve just implemented the unified renderer. I’ll test it later.



I have temporarily re-enabled the legacy renderer as there is something wrong in the unified renderer. I hope to find a fix this week.

Edit.: The maintainer of JainJa got in touch with the JogAmp community recently, he succeeded in running Java and OpenGL ES 1 on a Nintendo Wii. His “transpiler” has some hard constraints (Java <= 1.4) but maybe it will be worth a try.



I have to remove a useless empty character added when handling the attributes and the uniforms. I hope that it will fix the new unified renderer. Best regards.


I’ve just removed the old renderer as the new unified renderer works correctly now. I’ve just tested it with TestOgreAnim in debug mode to be sure that the unified renderer is used. I get a NullPointerException when exiting the demo but it works.

You can easily try the JOGL backend by settings the default renderer to JOGL and the default audio renderer to JOAL in the class “AppSettings”. Enjoy :slight_smile:

Edit.: I’ve just fixed the NullPointerException. Good night.



By the way, I tested it just now and I noticed that when I close the app by clicking the X button, it continues to run - it doesn’t seem the window close event has been caught by any of the backend code.
I am using Ubuntu 14.04 x64 with Intel HD Graphics.


@Momoko_Fan It’s caught, I see it goes in destroy(boolean). Do you run a demo separately or do you use the test runner?