We should just use those engines then, I guess.
What I have in my project is something as simple as this. If we could use something at least like this, we would likely be set.
if (rendererAPI == "Vulkan") {
initVulkan();
// Start
} else {
initOpenGL();
// Start
}and be “clickers” instead “developers” ? ;p (or this damn C issues… that anyway happen even here)
Well i agree VertexBuffer / Mesh is nice, since its OpenGL directly related and its easy to manipulate them. Its beauty in this meaning.
But again if would override same for Vulkan API, others would be unhappy that there is no more OpenGL.
Then we would stay on what you said “wait years Vulkan to be more popular/supported on older machines/etc”. But anyway doing Vulkan will take years, so… looks like you are against wrapper, but just doing Vulkan API only.
And what mesh data will pass around?
Is there a way to have vertex data that works with both? Not being facetious, I honestly don’t know.
But when folks speak of “wrapper” they talk about supporting things like Metal also… which is pretty impossible to share buffers between all of these different APIs, I guess.
I’m against a wrapper for a few reasons.
- Modern OpenGL is already a Vulkan wrapper on new hardware.
- “Dumbing down” the API to support both misses an opportunity to make something great.
- Trying to keep low level things compatible between both is going to be a pain at best and impossible at worst. And JME really shines here.
Edit: but all that being said, I feel like there is a JME4 that is still OpenGL-only, too.
BREAKING NEWS:
jME Engine Leader Paul Speed Officially Kills Wrapper Idea For A Possible jME4.
LOL. Nah, I’ve said those exact things already. It will probably come up again… and again… and again. 
yes i feel it, but i hate that OpenGL gonna be deprecated after time, not just this damn MacX…
If we blame MacX / ios / android / consoles(that anyway none works) / etc and just stick Windows/Linux, can survive to 10-20 years using it, but anyway what after. Somehow i dont feel like Linux would deprecate it, but who knows What Windows will do…
So i thought doing wrapper is fine, but if you say we could not make VulkanBuffer/OpenGLBuffer and superclass(or an wrapper) for them to have both, then i agree its problematic. Its just because i dont have Vulkan knowledge and i dont know what is possible.
Thats why we gotta get more devs for Android//VR
In a similar topic to this, @RiccardoBlb said we would need 2 cores, one for Vulkan, the other for OpenGL. I’m starting to think he might be right regarding this situation.
then jme3-bullet or Minie that use VertexBuffer might be dupplicated too?
or maybe other packages like android one too? (or it would just work for opengl core version)
i dont see it well. Well, maybe if @sgold would create physics for both cores.
(at least i seen Minie features like softbody that require VertexBuffer i assume, sgold would need tell here.) Not sure about default JME Armature, but i feel like its also using directly VertexBuffer. (and its not jme-core package but jme-bullet i belive)
Yea, well I really hate to say this, but we might just have to kill the wrapper option. Because I’m working on a Vulkan based core, I’m programming it so all the high level code remains the exact same, but low level stuff is all for Vulkan.
In other words, it could be a drop in replacement for current jme3 lib, but it can’t coexist with OpenGL, its one or the other.
And I just know that nobody wants 2 cores,.
I want to take this problem on with the pro/cons of each.
Thereby we should look at BGFX and decide if it remains an option or if we should kill it too.
And to replace the wrapper is just what @pspeed said, just make jme4 the best engine out there just using OpenGL. Jme5 we cut out all OpenGL support
well, you can do jme-core-vulkan replacement for jme-core for now.
It anyway will take a lot of time and everything will not be done in same time. (but its a good start point that can evolve)
Later jme-android or jme-bullet or jme-desktop(if it use any VertexBuffer) could be replaced too. (wrapper or not wrapper, this packages will need to be replaced anyway)
Well if that really is for jme5 things, according to @pspeed, I won’t be able to put my code to use for about 15 years . But by then I bet it would be about perfect then too.
you might be right.(and Ricc too) jme-core-vulkan is the way. then you dont need wait this 15 years 
(because well… its optional package)
I’m… Really getting confused here. What about core must be changed/duplicated to support Vulkan?
Surely, even with changes to the API/pipeline options, you’ll still need:
- A list of vertices
- A list of triangle indices
- optionally, per vertex:
- normal
- UV coordinates
- maybe other parameters
- texture maps
Is the Vulkan API so different that you cannot pass in the (already extant) byte buffers that jme keeps for these things?
JME “byte buffers” are VertexBuffers with OpenGL allocated IDs, etc… The shader binding name is right in the VertexBuffer.Type. It’s not clear to me if these are even compatible with Vulkan.
And if you change VertexBuffer, you change almost everything of significance in jme3-core.
But that’s handled at the shader level. With the exception of gl_position (which Vulkan does use) all of these are arbitrary names, as far as I can tell.
The scarier bit would be Vertex.Format (and likewise Image.Format - Vulkan combines these two into a single concept) These format types are supported.
As long as the underlying buffers are allocated correctly by the rendering backend, why would the Java-side API care if they are openGL or Vulkan?
For me, I’m not much into the Vulkan-thingy. Why? Well, openGL is More Than Enough to create a game. So why use something else? Will vulkan-thingy speed up my development? After seeing the 700+ lines of code to render triangle with Vulkan, I saw enough. Maybe in XXX years Vulkan will be a thing or maybe not.
In any case, I’d rather create something that would benefit game development.
1 Like
Well at first, I was pretty intimidated by those 700 lines of code just in an example.
But once I took a closer look at the different methods, I realised how little of that is the actual rendering part. A lot of it is handling the platforms, for example.
Now when I work with Vulkan, I don’t mess with about 690 lines of the current code, hence my point, so its pretty easy once you get to the renderer methods, and I already said:
In fact to allow rendering the BasicGame application I posted earlier, I dealt with very little of the very low Vulkan code.
Only alternative besides just staying like we are now is bgfx, which is definitely not good solution.
1 Like