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.
Or:
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.”
Or:
“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,
Trevor
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.
@destroflyer @tlf30 do you have public repositories of these anywhere?
国内做游戏，一直都有一个误区。很多人只是不断地套用最新的技术，技术迭代了一版又一版，却仍然不能抓住最本质的东西。一会Vulkan一会DX12，这些技术真的有用吗？不论是Vulkan还是OpenGL，你的显卡还是显卡，CPU还是CPU，不会因为开发者用了什么技术你的亮机卡就自动换成3090，那我们用Vulkan的意义何在？真正写一个游戏引擎，并没有那么复杂，OpenGL和C就已经够用了。优化这些问题真的没有那么难，优化仅仅是因为程序员的平均水平不够导致的。而且现在因为有了编译器优化，可以做优化的空间少之又少。
现在的游戏引擎，设置里选择各种DX11/DX12/Metal，其实都是没用的，这些东西说白了只是让你增加学习成本的。你用引擎到底是做游戏还是玩名词？如果你的答案是做游戏，那为什么要和这些名词斗智斗勇？Unity和UE4各种支持光追，实际上最终用到光追的游戏却寥寥无几。技术纵使强如腾讯北极光，也仅仅是个批量生产换皮游戏的没有灵魂的公司而已。
我们们可以思考一下，《赛博朋克2077》吹了那么久，为何最后会是这样的结局？CDPR技术力不够却盲目追技术热点，非要搞光追，最后PS4和X1X上的表现如此糟糕，这正是盲目技术迭代带来的问题。也正因如此，导致了策划过高的学习成本，最终项目画的大饼无法实现。可以说CDPR完全没有看到技术的本质，技术只是服务于游戏的，绝不能凌驾于游戏性之上。
我判断，未来的游戏引擎，一定是基于最简单技术的自研引擎。OpenGL的自研引擎是完全全平台兼容的，又可以根据策划的“需求”进行定制，让游戏引擎少一些噱头，让游戏专注于游戏本身。
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 . 
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)
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 (github.com) 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.