Are there any Java Game engines, using Vulkan?
Personally I haven’t found one, even though it would be a really interesting alternative to OpenGL in the Java gaming scene.
Doesn’t LWJGL3 have Vulkan bindings?
Or do you mean an Engine in the scope of something like Unity?
lwjgl 3 does have vulkan bindings. However there is no “engine” per say. I guess you could add a backend to Java Monkey Engine. But since that has a lot of “gl” type rendering, you may not see any real world benefit. In fact in general i wouldn’t expect much difference between Vulkan and gl. Is there any particular reason?
I mean more like LibGDX or something. Unity and Co are quite big engines to take on, using something like LWJGL.
Well, with Vulkan it takes a lot more effort to do the same as in OpenGL, but frame fates can be significantly higher. Especially the multithreading is interesting in my opinion.
I just was curious if somebody already has begun making that hard and time expensive ground work and build a easy to use engine around it.
My 2p on Vulkan and Java is maybe wait until value types are a thing before you go attempting to chase performance, as Java is always going to be horribly hobbled by its objects model and buffer IO.
Cas 
[quote=“princec,post:5,topic:59322”]
This would be true with typical JNI bindings. LWJGL bindings are not typical. This is what Vulkan code that runs at 5000fps looks like with LWJGL:
http://www.java-gaming.org/user-generated-content/members/4730/lwjgl-vulkan-ea-jitwatch.jpg
See those crossed out lines? They are Java allocations that have been eliminated with escape analysis. After scalar replacement, all that remains in the JITed code is a pointer address. Here’s the list of eliminations in the entire hot path:
http://www.java-gaming.org/user-generated-content/members/4730/lwjgl-vulkan-ea.jpg
It is possible to write high performance Vulkan applications with LWJGL, with no Java allocations (escape analysis) and no native allocations (MemoryStack “allocations” are simple pointer additions/subtractions). In fact, almost every major decision that has shaped lwjgl3’s API and internals, has been made to support writing and running Vulkan code efficiently.
It’s a pain in the arse manually serializing data into buffers though innit? And not to mention all the other irritating high-efficiency woes of Java objects that ruin stuff like particle systems. So I’m just saying… wait it out a bit, value types will come along and then you won’t feel like having to rewrite everything to use them when they happen.
Cas
There’s no manual serialization in the classic serialization sense. That’s just how the Vulkan API works. Instead of many functions with many parameters like in OpenGL, you have fewer functions and many structs (literally hundreds of them). You fill the struct members, you pass it to a function (that’s why EA works well).
Value types won’t change anything in the API. The JVM won’t need to do EA for performance and maybe my life as a library maintainer will be easier, that’s all.
Just to be clear, I can’t wait for value types for normal Java code. It’s incredibly exciting, considering that we’ll also get generics with value specializations (List anyone?). But they won’t do much for native interop. We need Project Panama for that.
The interesting thing is that compute heavy stuff like particle systems also need Project Panama. Removing object header overhead and pointer indirections is cool. SIMD vectorization for 7-8x speedups is much cooler. Automatic vectorization is not cutting it, there are so many annoying limitations, even on latest Java 10 builds.
Yeah, absolutely. I can’t wait either. I’m just thinking that when the JVM manages to put so many irritating slow obstacles in your code elsewhere, it seems a bit pointless chasing the efficiency gains in Vulkan at this time as you’ll just end up bottlenecked elsewhere by Java.
(By serialization I meant, writing vertex data out into NIO buffers painstakingly manually - a massive arse, prone to error, hard to debug, etc)
Cas
Yes, everyone will somewhen get to this problem when doing engines/higher performance stuff with Java that goes beyond basic games. I wrote an abstraction for myself for exactly this purpose, which is kind of a StructuredBuffer. It’s not as nice as using the objects directly, but hey, it’s okay for the few cases where one really needs it. Debugging is afterwards just fine with implementing buffer fetches for an object type/printing it. I think it’s okay, if everything else works on the given performance levels. Combined with the memory utils of LWJGL, I managed to get pretty much rid of “ugly” code and allocations.
w00t! I might even consider learning it now.
Cas
Yees! That’s actually awesome! It would make it worth to me now too.
The first LWJGL 3.1.7 snapshot is now available with Vulkan 1.0.69 and MoltenVK. If you’re on macOS, add this to your Maven script:
<dependency><groupId>org.lwjgl</groupId><artifactId>lwjgl-vulkan</artifactId><version>3.1.7-SNAPSHOT</version><classifier>natives-macos</classifier></dependency>
or equivalent for Gradle/Ivy, or get it from lwjgl.org.
A new binding has also been added: the Vulkan Memory Allocator (lwjgl-vma module). It simplifies CPU & GPU memory management of Vulkan applications.
Just found this article that brings up a lot of interesting things and wanted to share it:
https://www.anandtech.com/show/12465/khronos-group-extends-vulkan-portability-with-opensource
First read, then post: http://www.java-gaming.org/topics/vulkan-game-engine/38598/msg/368512/view.html#msg368512
There is a lot more in the article, that’s why I shared it. You could’ve read it first too 
You did not get what I was referring to. By the way, I also found another great article which noone in this thread has shared yet, which I would like to share. Please read this as well 