If i would ever want to make a vulkan bridge for Java, would it be hard and how would i have to make it so it work with the actual JMonkeyEngine? Would i need to redo the whole engine or could i just replace the core with a new core?
Edit: If i wanted to make jmonkey Vulkan capable, wouldn’t it be extremely fast to make both API (OpenGL and Vulkan) enables(switch from one to the other, depending on Hardware compatibility) using LWJGL?
source: Vulkan Bindings For Java Are Also Available Via LWJGL - Phoronix
Well, first of all with vulcan you get one step nearer to the metal. This implies the api complexitiy itself is much higher. Just compare a hello triangle from opengl and vulcan.
After your first shock, you will notice that you will not get any help from the driver. Memory management, synchronizing buffer transfers drawcalls, its now all up to you.
That said it is clearly not an easy task, and will take months to implement.
Now, even if you manage that all, you will notice that you wont gain that much. Jme is designed around a single rendering context, while the main vulcan perfirmance increase comes from the ability to have many reusable commandqueues.
So the main question is, why do you need vulcan in the first place?
Then there is no reason to do it as you will basically be re-implementing the OpenGL API.
It’s like rewriting a library in raw assembly language. Unless you change the library itself you won’t be able to take advantage of any of the lower level stuff because you will still be calling higher level functions.
So, start on JME4 built from the ground up around Vulkan. Let us know how it goes.
In my honest opinion,time to talk about implementing Vulkan has not come yet. Let’s wait to see how to harmonize it with older layers because building JMonkey on top of Vulkan requires to rethink a big part of the engine.
I can’t do this by my self, even if i wanted to make jme4, i would need supervision from someone in the jme3 team. The way i would do this would be to make jme3-jme4 give the exact same functionality available. Ending with no refactoring/rework of anyone game. And yet provide the new way to any upgrade on existing game would be possible!
And the reason i m planing on going forward with Vulkan is to provide latest technologies for the community in general. Making new game available for OpenGL/Vulkan at the sametime would give a boost at JMonkey Popularity, thus more Plugin and Talent people helping in maintaining the Engine.
We could even get help from Khronos Groups, Oracle, Google or AMD/Nvidia to maintain the project of a free engine available to everyone.
Anyway for now i will read about LWJGL 3.1 and it Vulkan implementation.
If you want that jme supports state of the art tech, go for gl4+ features and implement those (UBOs, SSBOs, Computing …)
If you still want to go for Vulcan,i honestly suggest that you start from scratch and design your engine around the new concepts that come with vulcan. Starting from the core, and not at the renderer backend
If a Vulkan backend was implemented for jME 3.x there would be many breaking changes from a user’s point of view. For example, everything in Vulkan is immutable by default for efficiency. This and other constraints would need to be enforced in various parts of the engine, which means breaking existing code that does not take them into account.
Also, we use integer IDs reference native objects. Those would need to be changed to using Object instead, which would reference a Vulkan native peer / struct when using Vulkan and an Integer (like before) for OpenGL.
Yes i still want to go for Vulkan, There is so much to gain and from my point of view Jmonkey would suffer in the long term if it doesn’t get an Implementation.
I’m probably not the most qualify for this but I will still give it a try.
Edit: Android base device run on Vulkan already so giving this opportunity would be perfect in the long term to make the community bigger.