Upgrade to LWJGL 3 (or LibGDX)

[msteiger]

We are currently using LWJGL 2 for rendering and mouse/keyboard input handling. It won't be maintained for much longer, since version 3 is in the making for a while now.

It also has better support for the Oculus devices and input controllers.

The most natural thing to do would upgrading to version 3, but the API is fairly different so the effort will be significant.

An alternative would be LibGDX. I believe that @immortius has already looked into that a bit.

Which library should we use in the future?

[Cervator]

I've been curious about the status of LWJGL 3 - back in late April the first release (3.0.0a) was announced, yet based on the road map it seemed like there was still a fair amount of stuff to do on the integration/extension front, so it is unclear to me whether it is truly ready yet or not. And then weirdly the blog has been quiet after June 1st.

There's still plenty of activity on GitHub and in the forum with another new release 3.0.0b in November. It sounds sort of like it is still in a pre-release sort of state?

The very latest LibGDX is still based on LWJGL 2.9.2 although it sounds like a switch to LWJGL 3 is being worked on with some initial work being released just a few days ago.

I think we should first wait for LWJGL 3 to be formally "finished" and/or for LibGDX to start using it. I'd lean toward LibGDX to take advantage of the extras like an Android facade like is currently in place for Destination Sol.

Also: LibGDX is now advertising Blackberry compatibility. C'mon! We can't resist that! :D

Pinging @emanuele3d for reference although this is probably something to start looking at in a few months for a later v2.0.0 engine release. Adding this to that milestone.

[emanuele3d]

A lot of the work I've been doing on the top-level classes of Terasology's graphics engine should have somewhat concentrated opengl calls into a few opengl-dense classes, eliminating them (almost?) completely from others. This will certainly ease the process of switching to a different API.

That been said, there are many parts of the graphics engine that I haven't touched or not even seen. Who knows what an API switch would require for those!

[Cervator]

Oh, oh, oh, I do! I know who! @emanuele3d you do! In the future sometime :D

[emanuele3d]

You are thinking too quadridimensionally for my taste Cervator... =D

[HeadClot]

I strongly think that we should go with Libgdx -
Here is my reasoning for that.

1. We would get LWJGL 3
2. We would get .FBX support for free if we went with Libgdx. So a more modern File format for Terasology content creators.
3. We would be part of the Libgdx Ecosystem which means we can take advantage of the some what large community LibGDX has to help develop terasology further.
4. We would be able to take full advantage of the LibGDX-AI framework. https://github.com/libgdx/gdx-ai
5. Cross platform support - If the Terasology code is written in a way that can support Desktop/Android/HTML5/iOS then we can port to those platforms easily.

This is just my reasoning but overall I think we should go to libGDX for terasology.

However keep in mind that from a code point of view I am clueless if this would work.

I am unsure if LibGDX has Oculus or HMD Support but I am going to ask on the libGDX forums in the next hour or so.

[HeadClot]

Ok, so I did some looking and from the looks if it LWJGL3 has bindings for libOVR and there is also google cardboard support for LibGDX via a plugin.

https://twitter.com/code_disaster/status/693909542162292736 <- LibGDX dev working with the Rift via the LWJGL3 Bindings and LibGDX.

LibGDX cardboard plugin -

https://github.com/yangweigbh/Libgdx-CardBoard-Extension

[Cervator]

Yep not surprised to hear they have a lot of that stuff, including VR and some AI. Good stuff.

The benefits are quite clear, the drawbacks are harder to identify without outright starting an implementation. Generally when you try to fit into a framework that expands compatibility you lose some options that work well on one system but only one system.

Thanks for the links :-)

[code-disaster]

Hi! Just dropping by to leave my €0,02 because HeadClot told me so. :)

To clarify, I'm not a libGDX core dev, but a contributor. I've mostly done bug fixes, small API additions and some work on packr so far. I'm heavily (ab-)using libGDX in my daily work though, targetting desktop platforms with GL 3.2+ support.

To my knowledge I'm one of the very early adopters on the libGDX Lwjgl3 back-end, and I don't intend to ever look back. In my opinion the parts libGDX uses are at least as stable and usable as the Lwjgl2 back-end.

A few notes:

• The nice thing about libGDX is that you can pick your parts and leave it be for everything else. It can act as a glorified Java windowing and GL context wrapper only, if needed.
• If you use it, esp. for cross-platform, don't fight the build system. But as you use Gradle already, you should be fine.
• If you aim cross-platform, you should plan to do so as early as possible. At least you need understand the libGDX concepts early on. It requires some discipline to work on a desktop project you intend to port later.
• As it is, libGDX isn't threadsafe at all. I'm doing some multithreading work (background non-GL geometry processing), but it requires to be careful with certain parts, e.g. its math classes. There are considerations to this as well.

[Cervator]

Hi @code-disaster and good to see you, your nick seems familiar to me from somewhere, maybe I've seen your work before, like the steamworks thing :-)

Good to hear about LibGDX with LWJGL 3. I was hoping we could just go that route and get LWJGL 3 "for free" rather than go for that first then maybe LibGDX on top later. Although yeah we probably still have lots of fun rendering refactoring to do first in any case.

Build system - our current project structure is actually inspired by a LibGDX template I came across a couple/few years back, so maybe that's even a little better than "just" using Gradle :-) We also picked up DestinationSol which is LibGDX already and on Steam (but not Steamworks yet - hmm!)

We heard from jMonkeyEngine at one point and talked about libraries. Math came up as a spot that could be unified a bit more so we worked a bit with JOML. I think that stalled out though. We've been playing a bit with building LibGDX / its physics stuff too, looking for something to graduate into beyond our TeraBullet lib.

As always lots of options, little time :D

Thanks for the feedback!

[emanuele3d]

@code-disaster: thank you for your assessment Daniel.
@HeadClot: also thank you Benjamin for bringing further advantages to the table.

To me, it sounds like LibGDX is the way to go as even among us there's a fair amount of theoretical support for it. In practice, I look at the state of our engine and especially at the parts I haven't even glimpsed at, and I'm like: when are we going to have the time to do it all?

I'd certainly put it into the wishlist but I'm skeptical this should get much priority. I understand the wish to go cross-platform but Daniel said it right that cross-platform should be planned as soon as possible. Perhaps only in my ignorance I do not see a lot of signs of Terasology having been designed with cross-platform in mind, certainly not the rendering engine. Looking into that direction at this stage would probably require some serious architectural changes. Perhaps @immortius is already one step ahead on this and his gestalt work is already going in that direction.

Other than that, for me the obstacle #1 to this kind of changes is the codebase being largely new contributor-unfriendly. In only about a year I have been on the project I have seen many people dropping-in with much enthusiasm only to disappear silently shortly thereafter, no doubt because of the steep learning curve. I'm not blaming anybody in particular for this but I'm thinking before we can even think about changes like a major library switch we should be thinking about systematically combing the whole code base with the specific intent of keeping the feature-set stable and dramatically increase code-based readability, comments, javadocs and wiki-based documentation, refactoring along as needed. Otherwise we'll keeping having these discussions on certainly desirable changes but no manpower to consider them properly.

I don't want to end on a pessimistic note. Ultimately, everything is possible. =)

[Cervator]

Doesn't sound pessimistic to me, just realistic :-)

I don't foresee us somehow perfecting rendering even in a year or two. LibGDX is at least that far out and that's just on the existing PC platform, not for any of the touch screen or other fun needed to expand onto, for instance, Android.

I really should move this out of the v2.0.0 milestone, it was just the only "future major release" one handy.

The silver lining is as always our open source nature: really anything could happen based on contributors who do make it through the troublesome bits in the more arcane parts of the code. But any kind of estimate would be no better than a stab in the dark, and plenty of things may never happen.

In the meantime we do what science we can, because we must!

[pollend]

I believe this also entails dropping these calls from the engine since they are considered legacy in terms of OpenGL 3 and OpenGL ES. The slimmed down nature of OpenglES also entails dropping dependent features from the core rendering setup or offering different rendering paths for such a case. This is just the basic minimum in terms of even supporting mobile as a platform.

glTranslatef, glColorPointer, glEdgeFlagPointer, glFogCoordPointer, glIndexPointer, glNormalPointer, glSecondaryColorPointer, glTexCoordPointer, glVertexPointer, glEnableClientState, glDisableClientState, and glInterleavedArrays, glClientActiveTexture, glFrustum, glLoadIdentity, glLoadMatrix, glLoadTransposeMatrix, glMatrixMode, glMultMatrix, glMultTransposeMatrix, glOrtho_, glPopMatrix, glPushMatrix, glRotate_, glScale_, and glTranslate_, glMaterial_, glLight_, glLightModel_, and glColorMaterial, glShadeModel, and glClipPlane_.

[emanuele3d]

@pollend, thank you for letting us know.

I can confirm that from my perspective moving to LibGDX to support multiple platforms will necessarily involve supporting multiple rendering paths. I certainly do not want somebody with a high performance PC to be constrained by the capabilities of a mobile phone.

This is consistent with the vision on the DAG-based rendering pipeline: the high level architecture would stay the same, but different platforms would enable/disable different nodes in the pipeline or would use entirely different pipelines potentially provided by external modules.

[LadySerenaKitty]

Would libGDX or LWJGL3 allow us to use the GLSL shaders the jMonkeyEngine team created? I like some of their shaders.

[ghost]

With LWJGL3 possible full real-time ray tracing. I want to make in future anisotropic filtering in ray tracer.

[emanuele3d]

@capitalknew: the current renderer is being overhauled into a node-based system, with nodes potentially provided by external modules. We still have some way to go, but when the renderer is open to modules, you'll be able to replace the existing render nodes with your own, and they could be raytracing rather than rasterizing as we are doing now.

Have a look at our Renderer Overhaul project and our Renderer Improvements project. If you keep an eye on them you'll know when the renderer is ready for external modules. And of course keep an eye on this thread for possible switches to LWJGL 3 or LibGDX.

[keturn]

At some point, when we reach The Year of Linux On The Desktop, a current version of LWJGL may be beneficial in order to get support for running under Wayland.

[DarkWeird]

Upgradingto LWJGL3:
#3969

Wayland not works at LWJGL 3.2.3(latest now).
They used pure glfw_wayland for it. and it have problem with memcpy and version glib (api breaks)
and they have code with required modification. but no released yet (commit at 2 month ago)