I am very interested in the new Vulkan API and was wondering if anyone can either point me to a demo or a game that they’ve themselves built which using Vulkan for rendering?
JME does not support Vulkan currently.
At the moment I think Oreon Engine is the only one for Java !
I wish the developer had put his effort on JME instead of creating yet another game engine.
On the other hand, I feel like a vulcan version of JME is pretty much a rewrite anyway… so…
I’m no expert in either the deep internals of jME nor in Vulkan, but I’ve been putting some thought into this and I’m not sure it’s quite so bad. The scene graph and controls can certainly all be used - much of the power of the engine comes from those, and those are renderer agnostic. I think the same class hierarchy for the rendering API (renderer, textures, material, etc) could also be sensibly reused. Granted, you’re not going to get the best of Vulkan’s multithreading abilities like that, but you could at least get a Vulkan-powered renderer up and running. I’d guess a Vulkan specific render manager could do a whole lot for bridging the remaining gap between jME and canonical Vulkan architecture.
…sort of. The relationship between Material, Mesh, and Geometry as implemented in JME3 starts to get really OpenGL specific really fast.
And I think most of the breaking changes would be there or related to that. Then the question is whether or not it’s worth keeping the existing scene graph around “as is” or, since all apps will break anyway, fixing a lot of the legacy design issues in the process. (I mean, think of all of the things that break if we change Mesh or VertexBuffer at all… text, animation, blue cubes, etc.) (And believe me, I’d love to fix some things even in the OpenGL implementation of VertextBuffers… custom types anyone?)
I’m interested in the idea but it feels like the closer it gets to just “slipping in Vulkan” under the covers, the more benefits we’d lose from doing it. Like, why is that any better than a thin OpenGL wrapper/adapter on top of Vulkan (which is bound to exist, eh?)
It’s interesting and I also think it will be hard to create a backend for vulkan, and even harder to create a way to easily switch between a vulkan renderer and the opengl renderer. I’ve been reading on vulkan, with hopes of being able to write abasic rendering solution on top of lwjgl… nothing to do with integrating it with jme.
A much better option I believe would be to create a new renderer using the “new” opengl azdo techniques and cool stuff going up to opengl 4.6 (SPIR-V in opengl??) That would still require a lot of modification.
(I am not an experienced renderer developer, just learning as much as I can)
IIRC, Khronos group originally intended to build such a wrapper as standard. Currently, check out ‘GLOVE’ library.
I was worried that might be the case. I believe that a reasonable refactoring could be done to efficiently support both OpenGL and Vulkan, but would be difficult to do without breaking existing code. Worst comes to worst, the current classes could become abstract super classes and the low-level native handle management could be done via subclassing. I’ve used similar patterns in a native rendering project I did for my day job a while back, although to be completely fair it was only used with different GL backends (no DirectX/Vulkan).
I think that depends a great deal on how that’s done. If the Vulkan renderer is working more or less the same as the current OpenGL one (but dispatching render jobs in place of state transitions), there’s not a great deal of benefit. However, if there were reasonably separated Vulkan/OpenGL renderers then I think a highly performant Vulkan renderer is within reasonable grasp. I’m personally not all that interested in a codes-like-GL-renders-on-Vulkan type feature - it’s throwing away huge possible gains.
Yes, but I think those gains are only available with significant engine redesign. Whereas the “OpenGL on Vulkan” thing we essentially get for free. I suspect on modern cards that’s what we’re doing all ready inside the driver.
For multithreaded rendering, that’s definitely true - but I think we could get most of the performance boost from losing state changes and call error checking just by providing a dedicated renderer.