I’m evaluating JME for production use and require multi-windowed support. At the moment, AwtPanel does not provide adequate performance to be considered as an option. I’ve been monitoring the forums for a few months and have not seen much discussion with regards to JOGL use in JME. It was mentioned that JOGL may replace LWJGL in 3.1. Is this still the case? I can get the current 3.0 to work with JOGL but it appears that this practice is discouraged. What is the future of JOGL in JME?
Are there any other options in JME for gaining multi-context support?
The official maintainer for jME3’s JOGL backend, @gouessej is no longer here.
Given that JOGL support is almost broken in the current jME3.1, it is very likely to be removed (especially since it is taking a lot of space in each installer package).
Does multi-windowed mean using AWT / Swing and having an embedded jME panel or just sepearate standalone jME3 windows?
Having jME embedded into a Swing application, either as a Canvas or Panel (any AWT component really). I need to have a main JFrame that displays a jME scene (main app) and then a floating dialog spawned from the main app that shows a different scene. At the moment JOGL is the only working renderer in jME that allows multiple contexts (the AwtPanel’s off-screen rendering solution has poor fps in my tests).
Maybe it’s time to have a look at LWJGL3? It supports multiple windows using GLFW (including hidden off-screen windows). Although it doesn’t have any official AWT/JavaFX support components yet, people have already been able to create AWT and JavaFX applications by simply draw everything to an hidden GFLW window and copying its contents over to a AWT or JavaFX image.
Drawing to a hidden window / pbuffer is what is currently used for AWT / Swing integration, and it is the same between LWJGL 2 and 3. There’s two issues with that approach:
its much slower than drawing directly to a canvas or window.
There’s no API to manage multiple windows within jME, instead there are AWT panels, which is more of a hack / workaround on top of the current system, which causes problems with things like post-processing filters not working when applied to more than one window.
Also, LWJGL3 support is already being implemented here:
Yeh the extra copy does make it slower but overall is probably the best and most reliable method. This is because AWT/Swing/JavaFX do not support or expose API’s to integrate with OpenGL, so any method to draw directly is nothing but a hack and usually results in all sorts of bugs and problems.
In retrospect adding AWT support directly into LWJGL 2’s API was a probably the wrong thing to do. It was a source of a major problems/bugs, increased the complexity of the library and required massive amounts of development time as implementations on various platforms occassionally changed therefore breaking the code. It’s something which hopefully won’t be repeated in LWJGL3 and if implemented be done in a way which doesn’t effect the core API.
Also I’d recommend for LWJGL3 that pbuffer’s be completely dropped in JME and the switch be made to using FBO’s + hidden window instead.
No worries, the pbuffer API’s are all gone in LWJGL 3 so that will all be going. The plan is to make the lwjgl3 renderer into a separate module (jme3-lwjgl3) which can be easily swapped into place of the jme3-lwjgl module to enable the use of LWJGL 3.
This may be the root cause of why there is no multi-context support. I have used Ardor3d in the past and they overcome the single LWJGL instance by managing and switching the local contexts of each scene/canvas to be rendered.
I’m still there, sorry. I can make the few adjustments soon. I’m just extremely busy, trying to maintain several engines at the same time is very time consuming. I have to implement the unified renderer and switch to JOGL 2.3.2 RC.
@Mr_Marbles The JOGL renderer will go on being maintained whatever happens in the future even though it won’t become something official.
Sorry for the off topic but JogAmp’s Ardor3D Continuation is actively maintained, it’s the same for the JOGL backend of LibGDX and Java 3D 1.6.0. Feel free to use the scenegraph API that fits your needs.
Do you have any guarantees that the jME renderer API will remain extendable so the the JOGL port will continue to work in the future? I am somewhat hesitant to rely on external engine extensions that may fail at any time due to API changes. Any thoughts on this?
From the recent talks on the forum I got an impression that JME3 is moving toward LWJGL3 which supports multiwindow applications and this feature will be added to JME3. Somebody correct me if I’m wrong…
@Mr_Marbles Actually, the JogAmp community is reliable, relying on our backends on the long term has proven to be a viable option, it is even sometimes safer (or at least something complementary) than relying only on the “official” maintainers, for example with Java 3D as we still maintain it (big kudos to Harvey, August, Emmanuel and the others) whereas Sun Microsystems abandoned it in 2009, with Ardor3D as Renanse decided to stop maintaining it in March 2014 as we still maintain it (but it’s called JogAmp’s Ardor3D Continuation now), with LibGDX as we are still almost daily synced with the “official” version (big kudos to Xerxes). The core maintainers won’t do anything that would intentionally prevent the JogAmp community from maintaining a separate renderer. Just look at my reactivity on our official forum, the bugs are fixed within days or in the worst case within a few weeks. Oracle abandoned JOGL in 2010 and we’re still here (thanks to Sven and others). Do you really need the pretty label “OFFICIAL” to feel reassured?
JOGL has supported multiple windows in an application for about ten years. All major scenegraph APIs written in Java has a JOGL backend, official or not.
Back to the topic, the answer to the question is: yes or no, it doesn’t matter as the JOGL backend will remain maintained in the official repository or in the JogAmp repository. As long as JMonkeyEngine will remain a major 3D engine written in Java, it will have a JOGL backend.
I don’t know, I don’t use the other library you talk about but I try to do nothing fancy that would annoy the JMonkeyEngine users. You just have to add one line of code to use JOGL and another one to use JOAL into your application at the very beginning. If you don’t use Maven or Gradle, it’s possible to use JogAmp thanks to only one JAR for everything (Java libraries + native libraries) since JOGL 2.3.2, which is named jogamp-fat.jar. Otherwise, JogAmp is on Maven Central You don’t have to set the Java library path, you don’t risk to pick the wrong libraries, typically when using a 32-bit JVM on a 64-bit OS.
There shouldn’t be any change but I wasn’t here since April. You’ll have to wait for September to use the unified renderer.
It’s not very difficult, I would rather explain it in the same tutorial rather than creating a separate tutorial just for this feature. It becomes a bit tricky when you want to share some data between several contexts.
If you need any assistance, please favour our official IRC channel and our official forum, these are more peaceful places to talk about the JOGL backends. This forum is still excellent for general JMonkeyEngine questions.
Okay, I’m using maven, so I guess this one will be easy.
Okay, I can wait till September, good to know it is coming rather soon.
Gonna read those! The articles look very interesting by the pictures. Still wondering what couple of lines I have to add that you mentioned in answer to question 1)…
Okay, but there is no tutorial yet… I wonder, how do I create the contexts from within my Java JMonkeyEngine app, what code exactly do I write and what are the implications of sharing the data between contexts…
Alright, I guess that when the unified renderer is released and I can work with it directly, in the upcoming September, I will come to the JOGL community to ask more about the particularities… probably some sort of a simple tutorial can be written for this as a result…
Interesting! Thank you, I am going to experiment with this and try it out on the weekend. If I understand correctly, this is the “fast” rendering, not the AWT panel slow thing? Btw, did you have any issues with data sharing between the contexts?