So with some help from Riccardo , I’ve submitted a PR that drops JOGL from the engine.
This solution is likely the best route for the engine as providing JOGL support comes with a few important cons
Our JOGL support is very minimal; it is filled with bugs.
It is built for general use of openGL, not gaming, which is LWJGL’s focus.
Very few use it in their jME games.
If the PR is merged, all JOGL related issues should be closed as they would no longer be relevant.
I’ve opened a forum topic for discussions on anything related to the PR, and I hope to see a good amount of feedback.
I wrote several years ago that I couldn’t go on maintaining jMonkeyEngine’s JOGL backend, I thought that some other developers could do it. Some APIs, frameworks and engines are actively maintained by a very few people, we can’t be everywhere. I failed in sharing some responsibilities, I didn’t find someone to maintain this backend whereas someone else took this role for Java3D (Phil, keep up the good work ). In my humble opinion, some developers have a customer mindset when dealing with APIs whereas I’m only a volunteer, I do what I can on my spare time, I would be happy if much more developers contributed to the APIs they use and it’s not only specific to JOGL.
By the way, I don’t question your arguments about the JOGL support in jMonkeyEngine but what is “built for general use of openGL, not gaming”? JOGL is built for gaming too and it’s used in some commercial and non commercial games and some features in development are done with gaming in mind (especially the next NEWT input API possibly with build-in support of raw mouse/pointer relative motion events, whose most obvious use case is first person shooters).
I left Github several months ago, I can’t comment on Github issues. It’s not up to me but in the current context, it can be helpful not to put your eggs into the same basket. I’m not the only developer who decided to leave Github after it was bought by Microsoft. Maybe it would make sense to use Github only as a mirror and to have both your source code and your issues in your own infrastructure (I won’t promote any competitor of Github as I seriously consider self-hosting all my stuff on the long term).
I’ll probably not resurrect the JOGL backend. I encourage the very few developers using jMonkeyEngine’s JOGL backend to contact us on the official JogAmp forum so that we can suggest some viable alternatives. If someone really needs JOGL support in jMonkeyEngine, we’ll maintain a fork on our side but this isn’t a solution that I seriously consider.
@gouessej, in theory, it is possible to resurrect JOGL, but it had a lot of accompanying glitches. I use JOGL myself in my games, but for most, it doesn’t work. Also, one of our engine leaders now is working on an ANGLE based renderer so we can use platform native APIs without the worry of Apple dropping OpenGL for example. So in the long run, we also will probably be dropping the LWJGL based renderer.
When I was on Github, I saw a very few bug reports about jMonkeyEngine’s JOGL backend. I can’t fix bugs that I don’t even know the existence and it’s the same for JOGL itself. No, JOGL works, JOGL works for games too but feel free to contradict me as long as you have some evidences. Then, where are your bug reports? https://jogamp.org/bugzilla/
If you imagine that you’ll have less bugs (which bugs?) by dropping OpenGL bindings, you’ll be completely wrong. I remind you that JOGL contains some render quirks to work around some known limitations and driver bugs. If you use any other API to access OpenGL including ANGLE but without our render quirks, you’ll have to deal with them by yourself. The use of platform native APIs doesn’t magically fix bugs in them. Metal has bugs, Direct3D has bugs too, Vulkan has bugs, nothing is perfect. If you really think JOGL doesn’t work, please let me create a bugzilla account for you and fill some bug reports.
I know that you don’t use github, but jMonkeyEngine uses it and I don’t think our repo is hosted anywhere else. But this is what some core devs have spotted FlyByCamera doesn't work with JOGL · Issue #796 · jMonkeyEngine/jmonkeyengine · GitHub. If that can be fixed, then sure we can add jogl back, but at the moment, that is a killer bug. You are correct though that it didn’t have many.
Edit: And maybe this is an issue with our integration with JOGL, but I have to embed my jME canvas (JOGL) into swing gui because the JOGL display window dosen’t seem to use the jME app settings.
He doesn’t possess the ability to understand what a renderer is, nor does he speak on behalf of the project or team, and I really wish he’d stop talking like he does.
I really don’t know why the PR was merged when he doesn’t have the ability to understand or fix any potential issues around it. If that PR breaks anything - the merger is going to have to deal with the work to fix it.
If you (@gouessej) have sufficient argument to retract the merge and are willing to fix the single issue surrounding it’s departure, i’ll happily put it back.
@ItsMike54 please stop pretending you have any idea what you’re talking about, because it’s got the the point now where it’s directly affecting the project. I am not a happy bunny at all.
I’m not sure that I can still launch jMonkeyEngine on my very old computer (it barely supports OpenGL 2.1) and I’m not allowed to use the computer owned by the company I work for in my spare time (I work remotely). The issue 796 is caused by a bug in jMonkeyEngine’s JOGL backend, not in JOGL as JogAmp’s Ardor3D Continuation has a similar type of camera for first person shooters and it works like a charm in T.U.E.R and it’s possible to embed JogAmp’s Ardor3D Continuation Swing, SWT and AWT (OpenJFX soon) canvases and windows into Swing graphical user interfaces.
@jayfella I don’t blame you but is it a good idea to drop the JOGL backend in the middle of a pandemic? Imagine that I spend two days in fixing this bug, someone else will find another excuse to drop the JOGL backend in several months or years. I assume that the decision of dropping jMonkeyEngine’s JOGL backend wasn’t made by a single person and it’s not just because of the issue 796. At first, I’d like to know why jMonkeyEngine’s JOGL backend was dropped. Then, I’ll consider spending some time in fixing it. It’s not up to me to decide, I don’t consider myself as a jMonkeyEngine core developer but I’m responsible for engine support in the JogAmp community. I just want to know whether fixing this bug would be a pure waste of time and I would like to know @sgold 's position.
Feel free to tell me that you’re no longer interested in JOGL, it’s ok, it’s not my engine, I respect that but please don’t even think about starting a FUD campaign against any JogAmp API. If there is a bug, there will be a bug report and possibly a fix.
There has been no end of objection to your white noise. If you can’t see it now, there’s no point re-iterating it. I have no interest in going around in circles.
Speaking for myself only (not the project as a whole), here’s my position:
JMonkeyEngine is not the same project it was back when I joined, in 2012. We have only a handful of people actively working on the Engine, and even fewer who do much outside of jme3-core. With our limited resources, we can’t properly support the huge codebase we inherited from JME 3.0.
Getting to JME 3.3.0-stable took over 2 years. In discussions of JME 4, one theme that has emerged is de-coupling features from the core of the Engine, so that they can have their own release schedules. To that end, we’ve begun spinning off sub-projects, starting with the Blender importer.
In my view, spinning off a project without an owner amounts to abandonment of the software in question.
I’ve nothing personal against you, nor JOGL, nor the jme3-jogl backend. I’m sure JOGL is a fine product. I noticed, however, that issue 796 was left unaddressed for 2 years. This told me that the backend had been effectively unsupported that whole time.
Our latest release is 3.3.2-stable, which came out yesterday. It includes the jme3-jogl backend. If there are further patch releases from the v3.3 branch, they will also include jme3-jogl.
It’s true that the jme3-jogl backend has been removed from the master branch of JMonkeyEngine. Based on our inability/unwillingness to support it, I believe that was a good decision. However, the removal could still be reversed if someone convinces us it was a poor decision.
I make no judgement on whether or not the removal was appropriate or not but @ItsMike54 followed protocol of the engine by posting this thread to the forum. His pr was discussed and accepted.
Thank you for your complete reply. I understand your position. Maybe we can find a solution so that you don’t have to modify the source code of jMonkeyEngine to treat the JOGL backend as something that would be potentially hosted elsewhere. In my humble opinion, it would be better if jMonkeyEngine’s JOGL backend was hosted in JogAmp’s repository and maintained by the JogAmp community. That way, it wouldn’t be up to the jMonkeyEngine team to deal with its bugs.
P.S: Hosting it in our (JogAmp) repository would help me to work on it as I still have no plan to register anew on Github.
@gouessej I’m very glad to know someone’s interested in supporting and maintaining jme3-jogl.
I’m not the right person to redesign the interface between JME and its render backend(s). Perhaps @riccardoblb could suggest such how a redesign might look.
I’m willing to restore the hooks that were deleted by PR 1339, so that maintenance of jme3-jogl can move to JogAmp. It might be a good idea to document the interface, to reduce the risk of finger-pointing in case something breaks.
I’m willing to act (for the time being, at least) as your liaison to the JMonkeyEngine community, if only to save you from having to rejoin GitHub. Just let me know the best way to contact you.
Please mention the JogAmp community when you close jMonkeyEngine’s JOGL backend’s specific bugs, so that the developers who’d like to use this backend know who to contact.
I just hope that no change in jMonkeyEngine’s core will prevent JOGL from working. I started using JOGL in 2006, I remember that some engines was designed only with its main competitor in mind, it was very difficult to make JOGL work in jMonkeyEngine 2.
, I’ve submitted a PR that drops JOGL from the engine.
). In my humble opinion, some developers have a customer mindset when dealing with APIs whereas I’m only a volunteer, I do what I can on my spare time, I would be happy if much more developers contributed to the APIs they use and it’s not only specific to JOGL.