LWJGL 3.1.0

[spasi]

LWJGL 3.1.0 has been released!

Release notes
Download

[advanced_set]

This is awesome !

Just a question:

I did not know bgfx ... and it is impressive. I still have to try, but it could be a backend to any sort of game/graphics application.

Does bgfx sort of "compete" with lwjgl's OpenGL and Vulkan Bindings? I mean, what are the advantages of using direct bindings over a portable solution as bgfx? (btw, their "official" java bindings are nowhere to be found)

[spasi]

Does bgfx sort of "compete" with lwjgl's OpenGL and Vulkan Bindings? I mean, what are the advantages of using direct bindings over a portable solution as bgfx? (btw, their "official" java bindings are nowhere to be found)

I haven't used bgfx yet, but these are the advantages I see:

- Higher level API than OpenGL/Vulkan, easier to use.
- Ability to use the Direct3D backend on Windows, for users with problematic OpenGL drivers.
- Ability to use the Metal backend on macOS, for better performance. Also, Apple hasn't updated their OpenGL implementation since macOS 10.9.

Using a low-level API directly has the obvious disadvantage that allows full customization and optimal performance for your particular needs. In general, high-level APIs often get in the way when you're trying to do things not supported out of the box. Support for new features is also usually delayed, because they have to first be supported in a cross-platform/backend way for the high-level API to adopt them.

On the other hand, bgfx is very actively developed and is low-level enough; it's nowhere close to what you'd call a 3D rendering engine or framework. It's small and lightweight and that's why we thought it was a good match for LWJGL. It might just be at the optimal intersection of features and usability for many LWJGL users.

[starfyre]

Are there plans to update the WIKI Setup page to work with the new LWJGL3.1.x file structure?

[spasi]

Someday, yes. Contributions welcome!

[Ktof0001]

Hi,
I'd like to make a good judgement about using LWJGL, as opposed to using Vulkan (directly, or using custom JNI). I am convinced about the wrapper, but how about continuity? (How can you guarantee this on long term? What is long term? what is the Vulkan-version followup planning? How many people are working on this?...)

Second, how about support for Oculus when it becomes available with Vulkan bindings? And how fast will they follow the (fast) releases of the Oculus SDK (currently in OpenGL)? Or is the access abstracted irrespective of the underlying API?

Thank you in advance...

[spasi]

Hi,

I'd like to make a good judgement about using LWJGL, as opposed to using Vulkan (directly, or using custom JNI).

There is no difference between using Vulkan via LWJGL and using Vulkan "directly" or via custom JNI. LightWeightJGL bindings, as the name says, are lightweight, meaning that there is no hidden layer between the Java API and actual driver calls to Vulkan. In fact, LWJGL goes to extreme measures to ensure that the binding is as efficient as possible, so you won't gain anything from doing it yourself.

I am convinced about the wrapper, but how about continuity? (How can you guarantee this on long term? What is long term?)

LWJGL is a project that has existed for 14-15 years. We've invested a lot of effort in LWJGL 3 in the past 3 years and we're not stopping any time soon. You can check the activity log on Github. Also, it's an open source project, so anyone can contribute.

what is the Vulkan-version followup planning? How many people are working on this?...

Vulkan is now actually the easiest binding to maintain; it's been completely automated using the same registry Khronos uses to generate the Vulkan specification and reference pages. The implementation for this is in a separate repository: lwjgl3-vulkangen. So there are no people involved. Vulkan revisions are pushed to Vulkan-Docs once a week and we just have to regenerate the LWJGL bindings when this happens.

Second, how about support for Oculus when it becomes available with Vulkan bindings? And how fast will they follow the (fast) releases of the Oculus SDK (currently in OpenGL)? Or is the access abstracted irrespective of the underlying API?

The bindings for the Oculus SDK are updated whenever a new version is released. When they add support for Vulkan, LWJGL will have support for it very quickly. There's no additional abstraction in LWJGL, we have bindings to whatever the SDK supports.

Also note that Oculus is part of the Khronos Virtual Reality Standard Initiative. There will soon be a standard cross-platform cross-vendor API for VR that will likely replace the Oculus SDK.