JOGL Support (JOGL2 that is)

Setekh · September 17, 2013, 10:24am

So any updates?

gouessej · October 9, 2013, 12:00pm

Hi

@Setekh said: So any updates? :D

I will have to switch to a more recent post build of JOGL 2 in order to allow JMonkeyEngine users to benefit of the latest fixes, especially under Mac OS X. The NEWT Input API is far from being ready and when it's done, I will add the support of controllers in another scenegraph, then I'll do the same thing for JMonkeyEngine 3.

I will have to work on 3D GUIs in some months (years?). I’d like to support Swing-like and enhanced lightweight 2D/3D graphical user interfaces, some of them will be defined in SVG files. I will use Batik’s parser. As these GUIs will rely on high level concepts, I don’t plan to implement them directly in JOGL, I will provide a first implementation for another scenegraph and another one for JMonkeyEngine if and only if its main developers are interested in this sub-project. Actually, I really need an AWT-free, cross-platform, very fast GUI library supporting both the fixed pipeline and the programmable pipeline, touch screens, and easy to integrate in existing scenegraphs for my editor (JFPSM). I need to use the typical components that you can already find in Swing (tree, table, …) and Netbeans Platform (property sheet, …) in one side and some basic components that I could use to build GUIs for games in the other side. For example, I’d like to be able to create menus whose items are in a kind of DNA strand, better transitions when closing a flat panel (imagine a panel that would be broken into pieces after an explosion), a file chooser whose image previews (videos too) are displayed on a soccer ball, … A GUI element should be made of meshes. I haven’t started to work on that because I’m already very busy with tons of stuff, for example the automatic construction of 3D towns with OpenStreetMap and OSM2World (a very small part of my suburb is already in TUER but the current result is ugly and boring), the control of native resources (mainly direct NIO buffers) in state-machine based games with the Fettle API, a state machine to simulate the way a gun works, …

mifth · October 9, 2013, 3:05pm

@gouessej said: Hi ...
I will have to work on 3D GUIs in some months (years?). I’d like to support Swing-like and enhanced lightweight 2D/3D graphical user interfaces, some of them will be defined in SVG files. , …

Hi.

Why don’t you want to use niftyGui? You will save much time if you work together with @void256 . I would like to get Android/IPhone support than get another GUI lib.

Edited: We also have Lemur by @pspeed and TonegoGui by @tonegod

toolforger · October 9, 2013, 4:24pm

Lemur is already integrated into the scenegraph. You could even create a Lemur-based GUI right inside the game that way.
No SVG support in any of the existing libraries AFAIK.
I think all three libs use shaders to allow for things like fast clipping - dunno if that can be done using the fixed pipeline only.

gouessej · October 9, 2013, 10:36pm

@mifth said: Hi.
Why don’t you want to use niftyGui? You will save much time if you work together with @void256 . I would like to get Android/IPhone support than get another GUI lib.

Edited: We also have Lemur by @pspeed and TonegoGui by @tonegod

I already worked a bit with @void256 as I ported Nifty GUI to JOGL several years ago. The remaining work to support Android and IPhone requires Project Ji Going (alias Jogamp Runtime Environment) which is far from being ready. Aren’t you already satisfied with the current Android support of JMonkeyEngine 3? Personally, I prefer using the JOGL renderer everywhere but I understand that some people prefer using Android Dalvik Virtual Machine with Android GL.

@toolforger said: Lemur is already integrated into the scenegraph. You could even create a Lemur-based GUI right inside the game that way. No SVG support in any of the existing libraries AFAIK. I think all three libs use shaders to allow for things like fast clipping - dunno if that can be done using the fixed pipeline only.

Nifty GUI, Lemur, TonegoGui, LibGDX Scene2D, PureSwing and JavaFX are some nice sources of inspiration. Of course, I will investigate a bit more before starting to create yet another GUI library, I'd like to avoid effort duplication.

mifth · October 10, 2013, 7:36am

@gouessej said: I already worked a bit with @void256 as I ported Nifty GUI to JOGL several years ago. The remaining work to support Android and IPhone requires Project Ji Going (alias Jogamp Runtime Environment) which is far from being ready. Aren't you already satisfied with the current Android support of JMonkeyEngine 3? Personally, I prefer using the JOGL renderer everywhere but I understand that some people prefer using Android Dalvik Virtual Machine with Android GL.
Nifty GUI, Lemur, TonegoGui, LibGDX Scene2D, PureSwing and JavaFX are some nice sources of inspiration. Of course, I will investigate a bit more before starting to create yet another GUI library, I’d like to avoid effort duplication.

We need IPhone/IPad support. And we have been awaiting it from JOGL as it has OpenGLES support.

We do’t need a new gui lib. We need to improve existing gui libs. If you will take existing one and improve it - it would be much better for our community. We would become much stronger.

These are only me thoughts. I don’t want to hurt you.

Edited: Mostly, guiLibs are one-man-project. That’s really bad. We need a strong lib, which will be supported by many people. Nifty, Lemur, toneGod libs are good! They are really good. If you will use one of them - it means you will improve it, fix many bugs, make it more usable.

toolforger · October 10, 2013, 8:22am

All three libs are a bit hampered by the fact that their respective main author has limited time to review contributions. And core contributions do require a review, which means they can be queued up for weeks.
Also, all have a strong view of what should not go in. I’m not sure whether it’s possible to do something as complicated as a GUI library in any different way, but if you want something that doesn’t fit you are simply out of luck.
Also, all three libs are a bit thin on docs, including on basic design principles, so it’s a bit hard to see how to fit some desirable feature into the existing framework.

This all makes collaboration difficult, despite all three projects being open to contributions in principle.

Disclaimer: I have been distracted by other things in the last three months, and I’m seeing echoes of Stuff Getting Done in both TonegodGui and Lemur, so the picture I’m painting might be somewhat outdated.

pspeed · October 10, 2013, 8:47am

For my part, I think all of the open Lemur stuff has been applied in one way or another. I try to do it within one or two days now.

Anyway, the basic design principle was to be as extensible as possible precisely so core changes were not necessary for a user to get work done. In fact, any issues with that I consider to be high priority if anyone finds a limitation in that respect. That’s the kind of stuff that festers badly if left too long.

Lemur was initially designed to be a base set of classes that others could use to jumpstart custom GUIs… it just happens to include its own sort of swing-like layer on top of that, too. Especially the event package… someone writing a custom GUI should leverage it or at least cut-paste many of those classes. Many hard-won best practices in there.

…but yeah, documentation is limited.

gouessej · October 10, 2013, 11:03am

Hi

@mifth said: We need IPhone/IPad support. And we have been awaiting it from JOGL as it has OpenGLES support.

IOS support requires much more than OpenGL-ES support. NEWT (the native windowing toolkit of JOGL 2) already supports Android but not yet IOS. The JogAmp Foundation needs some more contributors as supporting Mac especially with AWT is already very challenging (Sven makes a great job, big kudos to him), supporting another major platform is neither trivial nor costless. I would be happy if JOGL adopters using JMonkeyEngine could clearly express their expectations. I have the same kind of problem with a few other scenegraphs, I discover that some people are interested in my stuffs and use them only when something doesn't work. Controller support is in my todo list. Thank you for your feedback.

We do't need a new gui lib. We need to improve existing gui libs. If you will take existing one and improve it - it would be much better for our community. We would become much stronger.

I understand your position. There is already a request for enhancement about a GUI library for JOGL here but Graph-UI requires shader support and the geometry of SVG files is intended to result in data types supported by Graph-UI (i.e no mesh).

These are only me thoughts. I don't want to hurt you.

Your feedback is useful, don't worry, I'll make a wise choice.

Edited: Mostly, guiLibs are one-man-project. That's really bad. We need a strong lib, which will be supported by many people. Nifty, Lemur, toneGod libs are good! They are really good. If you will use one of them - it means you will improve it, fix many bugs, make it more usable.

I need a library to port existing Swing applications too, PureSwing isn't based on JOGL and is no longer maintained. I'll see what I can do with existing ones.

@toolforger said: All three libs are a bit hampered by the fact that their respective main author has limited time to review contributions. And core contributions do require a review, which means they can be queued up for weeks. Also, all have a strong view of what should not go in. I'm not sure whether it's possible to do something as complicated as a GUI library in any different way, but if you want something that doesn't fit you are simply out of luck. Also, all three libs are a bit thin on docs, including on basic design principles, so it's a bit hard to see how to fit some desirable feature into the existing framework.
This all makes collaboration difficult, despite all three projects being open to contributions in principle.

Disclaimer: I have been distracted by other things in the last three months, and I’m seeing echoes of Stuff Getting Done in both TonegodGui and Lemur, so the picture I’m painting might be somewhat outdated.

I see what you mean. I’ll see whether they are worth the effort… Yes they aren’t very well documented but I found tons of examples using Nifty GUI

@pspeed said: For my part, I think all of the open Lemur stuff has been applied in one way or another. I try to do it within one or two days now.
Anyway, the basic design principle was to be as extensible as possible precisely so core changes were not necessary for a user to get work done. In fact, any issues with that I consider to be high priority if anyone finds a limitation in that respect. That’s the kind of stuff that festers badly if left too long.

Lemur was initially designed to be a base set of classes that others could use to jumpstart custom GUIs… it just happens to include its own sort of swing-like layer on top of that, too. Especially the event package… someone writing a custom GUI should leverage it or at least cut-paste many of those classes. Many hard-won best practices in there.

…but yeah, documentation is limited.

I have to look deeper at Lemur’s source code. I have to admit that for the moment a mix of GLG2D + NEWT+ PureSwing might allow me to render Swing components without build-in Swing support in the JVM. I haven’t made a decision yet.

mifth · October 10, 2013, 11:22am

@gouessej said: Hi
IOS support requires much more than OpenGL-ES support. NEWT (the native windowing toolkit of JOGL 2) already supports Android but not yet IOS. The JogAmp Foundation needs some more contributors as supporting Mac especially with AWT is already very challenging (Sven makes a great job, big kudos to him), supporting another major platform is neither trivial nor costless. I would be happy if JOGL adopters using JMonkeyEngine could clearly express their expectations. I have the same kind of problem with a few other scenegraphs, I discover that some people are interested in my stuffs and use them only when something doesn’t work. Controller support is in my todo list. Thank you for your feedback.

I understand your position. There is already a request for enhancement about a GUI library for JOGL here
…

I see what you mean. I’ll see whether they are worth the effort… Yes they aren’t very well documented but I found tons of examples using Nifty GUI

…

There is good example if you want to play with niftyGui: Google Code Archive - Long-term storage for Google Code Project Hosting.

toolforger · October 10, 2013, 12:49pm

I found Nifty to get horribly unstable once you leave the beaten path.
Which is not surprising given its flaws:

It’s eating exceptions. By. Design.
Properties get converted to strings and back before they hit the actual setters.
It’s using an event bus, but tieing the event names to control names (eliminating the logical decoupling between event sources and event handlers), and executing all events immediately (eliminating the time-wise decoupling between event sources and event handling). That’s just absurd.

Initialization order does matter. Subtly.
There is no clear documentation of initialization order. That would be hard to do because the lib is using recursion, and lots of that, including mutual recursion, and recursion that happens only in some subclass. Somebody should tell Jens about the Visitor pattern so that one can tell with one look at the code which of the nodes are being touched by some update.
It came as no surprise that he’s constantly fixing initialization order issues. Which means he might be making the library more stable (he does have unit tests, I just hope he’s adding a unit test with each fixed bug), but he’s probably breaking client code.

You cannot shut down Nifty.
Nifty also uses global variables.

Nifty does have its nice points - it’s a large list of supported controls, it can deal with effects such as fade-in asynchronously, it has built-in skinning support, it comes with lots of docs that help you get up to speed really quickly. It’s really easy to get something to work with it, and it gets the job done if you stick with standard practices.
It’s the deeper and more complicated things like what you want to do where it starts to fail, sometimes subtly, sometimes spectacularly.

gouessej · October 10, 2013, 6:44pm

@toolforger said: I found Nifty to get horribly unstable once you leave the beaten path. Which is not surprising given its flaws:
It’s eating exceptions. By. Design.
Properties get converted to strings and back before they hit the actual setters.
It’s using an event bus, but tieing the event names to control names (eliminating the logical decoupling between event sources and event handlers), and executing all events immediately (eliminating the time-wise decoupling between event sources and event handling). That’s just absurd.

Initialization order does matter. Subtly.
There is no clear documentation of initialization order. That would be hard to do because the lib is using recursion, and lots of that, including mutual recursion, and recursion that happens only in some subclass. Somebody should tell Jens about the Visitor pattern so that one can tell with one look at the code which of the nodes are being touched by some update.
It came as no surprise that he’s constantly fixing initialization order issues. Which means he might be making the library more stable (he does have unit tests, I just hope he’s adding a unit test with each fixed bug), but he’s probably breaking client code.

You cannot shut down Nifty.
Nifty also uses global variables.

Nifty does have its nice points - it’s a large list of supported controls, it can deal with effects such as fade-in asynchronously, it has built-in skinning support, it comes with lots of docs that help you get up to speed really quickly. It’s really easy to get something to work with it, and it gets the job done if you stick with standard practices.
It’s the deeper and more complicated things like what you want to do where it starts to fail, sometimes subtly, sometimes spectacularly.

My main concern with Nifty GUI was its high memory footprint but Jens claimed it’s ok now. I don’t know how it has evolved as I used it at work several years ago without JMonkeyEngine, thank you for the insights.

pspeed · October 10, 2013, 9:34pm

If you are looking for a GUI that works without JME then that’s something that Nifty has over Lemur and tonegodgui.

gouessej · October 10, 2013, 10:32pm

@pspeed said: If you are looking for a GUI that works without JME then that's something that Nifty has over Lemur and tonegodgui.

Yes but the JOGL renderer of Nifty GUI is a plain port of the one based on the competitor of JOGL, both are underoptimized. Anyway, I have looked a bit at Lemur's source code, it seems very tightly integrated in JMonkeyEngine but some parts could be ported to a similar scenegraph.

pspeed · October 10, 2013, 10:54pm

@gouessej said: Yes but the JOGL renderer of Nifty GUI is a plain port of the one based on the competitor of JOGL, both are underoptimized. Anyway, I have looked a bit at Lemur's source code, it seems very tightly integrated in JMonkeyEngine but some parts could be ported to a similar scenegraph.

Yeah, that was kind of my point. Nifty is scene graph independent. Lemur was specifically designed to be tightly coupled with JME. It’s a JME-based GUI, not an OpenGL based gui.

Edit: in other words, I think Lemur may be unsuitable for your needs.

gouessej · October 24, 2013, 10:58am

Hi

I will switch to JOGL 2.1.1 in a few days. Let me know whether you find any regression especially under OS X. Best regards.

gouessej · November 4, 2013, 12:40pm

Hi

Instead of manually downloading and copying the JOGL JARs into the proper directories, I will add an Ant target into one of the scripts to do that more easily like it is the case in TUER, it’s up to the developer to give the proper URL to get them but I’ll provide some examples. I don’t remember whether JMonkeyEngine 3 uses mesh instancing, I may have to modify some calls which will affect only users of the Core Profile. A bug in NEWT under Mac OS X discouraged me to update JOGL JARs, its fix is going to be included very soon in a build. I’ll switch directly to JOGL 2.1.2.

Setekh · November 4, 2013, 1:28pm

Cool, cant wait ^^

gouessej · November 5, 2013, 6:02pm

I committed the changes yesterday

gouessej · January 3, 2014, 1:20pm

Hi

I’ll switch to JOGL 2.1.4 as soon as possible. NEWT now supports application, window and cursor icons but I haven’t deeply looked at the methods added into the API yet. Best regards.