Jmonkeyengine's future and Vulkan Api

Hello Jmonkeyengine community.
Is there any plans for Vulkan support?
Do we need to re-write whole engine for it ?
I know this question is asked before many times but it’s 2023 and I want to know about future of jmonkeyengine because Vulkan is new, fast and have many new features.
I think that opengl support is good in jmonkeyengine and currently we don’t need anything but in future after 2 or 3 (2025 onwards) years Vulkan will be used everywhere because of new hardware of mobile and PC etc. I think a new version of jmonkeyengine should be released within 2 years. I wish I could help but I don’t have any graphics Api level skills and I feel sorry about that. Jmonkeyengine is my favorite game engine and I am working on it as my hobby game development in 3D games. Sorry for my bad English!!


Vulkan has been discussed previously in this Forum. Here’s my take…

Based on what I’ve read so far, I don’t view Vulkan as a feature to include in JME 4. Rather, I see it as an opportunity to craft a revolutionary open-source game engine, building on what we’ve learned from JMonkeyEngine (and perhaps borrowing some of its code and concepts) but not retaining its name, nor much of its API.

It would be a major undertaking. Such a project would require a critical mass of committed developers. At the moment, I don’t expect to find that critical mass in this Forum.

It’s likely JME will continue releasing new versions for many years to come, but the changes will be incremental (based on OpenGL) not revolutionary.


Another option is to fork JME and removing LJWGL2 support, so you can only focus on version 3 and modify modules such as jme3-lwjgl3 so that it supports Vulkan and extend it to have the extra features. But at that moment it will be your own custom engine based on JME.

Last time I checked, LibGDX does not support Vulkan either in its current version. so we are not the only ones

“I want to use Vulkan with JME”.
“Well, what features do you want?”
Option 1: “I don’t know… I just want to use it.”
Basically a dead end conversation from a productivity perspective.

Option 2: “I want to use features X, Y, Z from Vulkan.”
“Ok, well those features are completely incompatible with the whole design of JME.”
“You can already do those in OpenGL and here’s how JME lets you do it.”

Yes, it’s essentially a total rewrite. Nothing short of that would satisfy anyone who “needs Vulkan”.

So far, in addition to “critical mass”, etc. as already mentioned, we are waiting for the second conversation to happen.


I have spent the last few years working on my own in house engine to fully support vulkan. It is a huge task to say the least.

My current efforts were to continue to use Java and LWJGL, and I have a working prototype engine that is usable.

The main issues begin when wanting to use any of the great vulkan tools that exist, such as Nvidia RTXDI and RTXGI. You quickly run into a situation where you are spending more time working on native bindings than you would be if you wrote the engine in c++.

Having built a complete prototype in Java, I’m now working on laying out a new engine in c++ based on what I learned.

For existing engines, Vulkan IS NOT OpenGL. Without very good abstraction layers you cannot make an engine support Vulkan and OpenGL. Existing engines do NOT have these abstraction layers and this you will not find them working on vulkan rendering. It basically would take a complete rewrite of the entire engine. Trying to make vulkan work in place of OpenGL in an existing engine will have major performance issues because the structure of the rendering APIs and the way they work is fundamentally different.

If anyone has questions on how to get started with building an engine, I’m more than happy to give pointers. Vulkan engines must take advantage of operating on multiple threads to take full advantage of the rendering API, which is a major hurdle for any game engine.

Just my two cents,


I got the point. Thanks for your response guys. I will try to learn Vulkan. It will may take one to two years to learn. If I will be successful then I will contribute in future. May God help me doing something for jme community. Thanks again!!


As tlf30, I’ve spent over a year working on an own Vulkan-based engine and got pretty far (I’m still continuing with the project, but with very large gaps in between and no intention of a timeline - I’m happy diving into it from time to time). The most important takeaway is that Vulkan shines when you need to do custom stuff specific for your game (which is also part of the reason why it got created, it’s A LOT more explicit than OpenGL). So the whole point of creating a reusable general-purpose engine in Vulkan might not be using it properly. One of the biggest advantages is that they built-in multithreading in by design, so you can take full advantage of that.
I still think a general purpose Vulkan engine can be a huge step forward, but it will be a very very very very big effort and yes, a complete rewrite because the approaches behind OpenGL and Vulkan are very different.

1 Like

@destroflyer @tlf30 do you have public repositories of these anywhere?




There has always been a misunderstanding in domestic game making. Many people just keep applying the latest technology, technology iteration after version, but still can not grasp the most essential things. Vulkan and then DX12, are these technologies really useful? Whether it's Vulkan or OpenGL, your graphics card is still a graphics card, the CPU is still a CPU, and it won't automatically change to 3090 because of what technology the developers use for your bright card, so what's the point of using Vulkan? It's not that complicated to really write a game engine, OpenGL and C are enough. Optimizing these problems is really not that hard, and optimization is only caused by the average level of programmers is not enough. And now because of the compiler optimization, there is very little room for optimization.

Now the game engine, settings to choose a variety of DX11/DX12/Metal, in fact, are useless, these things frankly just let you increase the cost of learning. You use the engine in the end is to do the game or play the terminology? Unity and UE4 all kinds of support for light chase, in fact, the final use of light chase game but few. Even if the technology is as strong as Tencent Northern Lights, it is only a mass production of skinned games without a soul of the company.

We can think about, "Cyberpunk 2077" blow so long, why the end will be such an end? CDPR technical force is not enough but blindly chase technology hot, have to engage in light chase, the final PS4 and X1X on the performance is so bad, this is the problem of blind technology iteration. Because of this, which led to the planning of excessive learning costs, the final project painted a big pie can not be achieved. It can be said that CDPR completely failed to see the essence of technology, technology is only to serve the game, and must not override the gameplay.

I judge that the future game engine must be the self-research engine based on the simplest technology, and the self-research engine of OpenGL is fully compatible with all platforms, and can be customized according to the "needs" of the plan, so that the game engine is less gimmicky and the game focuses on the game itself.

This is part of the view in the Chinese forum I also agree with this view.
The translation may be imperfect so I have written the original text as well.
(The point here is not that any technology is bad, but that one should focus on what really should be focused on)

Thank you for asking this question which is also what I wanted to ask . :smiling_face_with_three_hearts:

I was also curious about VulKan to learn more.


As much as I agree with the fact there’s no point in chasing the latest technologies just for the sake of it, it becomes a problem even if the others do.
The other day I was working on some compute shaders for mobile and to render the results I needed SSBOs. Which shouldn’t be a problem… if one major mobile GPU manufactureres bothered suporting SSBOs. When I went to search around the internet, I found a post on their forum where someone asked them if they intend to support it in the future. Their answer? “Just use vulkan, it works there.”

Now while I don’t see the situation turning this way on the desktop side of things anytime soon, I wouldn’t be surprised if we eventually get to that point.


@tlf30 do you have public repositories of these anywhere?

I do not, the repos are hosted on my private gitlab server.
I would not recommend using my engine in its current state. I was preparing to do a major overhaul on the persistence code, and never got to it before deciding to change directions to move to c++. PM me if you would like to see parts of the engine. I will have to review to see if I can share the whole things.

If people are interested, I would consider making the c++ engine open source, you can PM me for more details as I am currently in the planning stage and very little code has been converted from java to c++ at this point. For the C++ engine, I am using existing technologies such as (but not limited to) GLM, GLFW, and ImGui. I am also focusing on several NVIDIA technologies such as Physx5. The Java version of the engine was completely plugin based and used an abstraction layer to isolate the underlying technology from the implementation, and I would like to get there with the C++ version, but the initial versions of the engines probably won’t include full abstraction layers yet.


Why didn’t you use the LWJGL bindings for Vulcan? (that sounds accusatory, but I have no experience with this and want to know)

1 Like

I did. My java engine uses LWJGL almost exclusively. But there are many other native libraries built for using advanced functions in vulkan, like raytracing, or troubleshooting GPU crashes (NVIDIA NSight). And yes, when working with Vulkan, you WILL crash your GPU, many times in fact. It is not as forgiving as opengl which will seemingly work with any garbage input. Vulkan is very picky. I want to be able to utilize those tools and libraries, which is not possible without creating a C interface library, then building a JNI wrapper to map to it. It ends up being a huge amount of work.

The only big disadvantage with working exclusively in LWJGL is Android support. JME has its own native bindings just to support Android, and I had little interest in building those for my engine as well. When working directly in C++, it becomes much easier to support Android when working with Vulkan.

I spent a lot of time looking at NVRHI NVIDIAGameWorks/nvrhi ( to see if it was a possible route or getting directx support too, but it ends up being a large pain since you do not have direct access to the rendering API. Specialty functions in Vulkan and DirectX are not accessible unless NVIDIA builds an interface to them, so I am sticking with porting my Java Vulkan rendering engine to C++. Unfortunately, the rendering component is only one large piece of what a game engine needs to do. A lot of my java work can be converted over to C++, but not all of it since some things in C++ just work different and need a different structure. Right now I am working on getting plugin loading working in Windows, and for now I will be mostly focused on Windows support until all the abstraction layers are built.


Same here, I don’t recommend anyone looking at the stuff as it’s under heavy development and completely changes as I’m learning along. Plus it’s heavily biased from what I deem useful. A proper community effort would most likely look different.