Do you have an up to date roadmap of your jme4 progress? I know you have on at your github project, but you havn’t updated it.
At this point, my repo is very out dated, and it would be more work to rebase it than rebuild it from scratch.
I am at work right now. When I get off I will do some cleanup on the repo and get it ready. I will give you access to it.
I work 12 hour days remote in the artic circle two weeks at a time. (I’m just North West from Deadhorse Alaska) I do not get home until March 11th. So I may not be a lot of help until then. I have internet but not much. When I get off shift tonight at 6 I’ll make the changes to the repo.
1 Like
Ok. I’ve been working on cleanup of some of the smaller libs, but I’ve paused my work as I am worried that they require a rewrite (in addition to the core lib) to support Vulkan. I chose to wait till you finish the Vulkan project before I get too involved in reworking the others. Thereby I was curious
So I’ve been looking, and I finally found a Vulkan tutorial for Java that would be of a good use as reference for development of a Vulkan powered jME4. It appears to have everything, from drawing basic shapes in a GLFW window to loading OBJ models.
2 Likes
Wait, so you have to compile Vulcan shaders as well? That was one of my big concerns with bgfx. Either way the jME shader process is going to need some major changes since it depends on runtime shader compilation at the moment because of all the defines.
Vulkan doesn’t have runtime shader compilation?
That’s SUUUPPPER dumb, if true.
It looks like lwjgl has a util to let you compile at runtime and there are other libs that let you do it. However, it looks like there is a performance hit to do it at then and isn’t recommended for production applications.
Is there an intermediate byte code at least? I’d imagine each driver is going to want its own crack at optimizing for its platform. So there must be “some” intermediate representation.
The intermediate format is SPIR-V.
https://vulkan.lunarg.com/doc/sdk/1.1.92.1/windows/spirv_toolchain.html
So before we start making big decisions, what are the pros/cons of keeping OpenGL and Vulkan, or just completely switching to Vulkan?
Big con is that right now dropping OpenGL support cuts out most of the indie game market, I suspect.
…these aren’t the folks who buy the latest gear. Even requiring OpenGL2 minimum was pretty controversial when we did it.
2 Likes
For the shaders, it’s source (GLSL, now apparently HLSL too) → SPIR-V (bytecode) → Vulkan (internal final compile to GPU-specific binary). LWJGL has bindings to libshaderc, which provides runtime support for the source - SPIR-V stage. I would not expect compilation to be much more expensive than standard OpenGL shader compilation - in any case, the performance implications are severe so shaders should only be compiled as rarely as possible. There’s no way around this with Vulkan, and frankly it’s the least of the support issues - that compilation will all happen behind the scenes just as it does in the OpenGL implementation.
As far as maintaining OpenGL support, that’s a must - and it shouldn’t be that difficult to do. Lots of projects still depend on it.
1 Like
Hmm…
If I am right, GLSL supports both and if so, one would simply need to specify Vulkan or OpenGL in appSettings, if not then some sort of compatibility if possible needs to be implemented so both are supported with only one shader.
The thing is, iirc, openGL can also parse SPIR-V, so we could have a gradle task to convert all shaders to SPIR-V.
But:
This breaks quite a big chunk of the engine, starting with all of our conditional compilation, glslcompat (glslibs in general) and all of the others (unless I am mistaken).
Yep, basically a rewrite of all shaders from the ground up, no more shader nodes, etc…
Runtime compilation shouldn’t be a big deal. On the official sites, the only down side stated was related to ‘including the source’… but SPIR-V can be trivially decompiled into glsl anyway.
1 Like
Do you spend a lot of time working on shaders? If not, who does? Because unless @tlf30 has already handled the shader compatibility issues for jME4, there should be somebody to work on it.
Would that be the case? I’d expect them to stick around as a developer tool, and then compile down to a single SPIR-V shader as part of the project build…
I have not. Shaders are one of my weakest areas.
Would you consider uploading to gh any Vulkan work you currently have done? No matter how much is completed, a bet a lot more people would then be able to chime in on this project. 
One of the points of dynamic shaders was the ability to compose things at runtime so that you could turn on/off options. The same is true for a bunch of JME’s shader features.
So the alternative with statically compiled shaders is to send 500 different precompiled versions with a giant property tree to decide which one to use based on user options, platform capabilities, etc…
It’s dumb. Runtime shader support has to continue being a thing or its a non-starter for me.
4 Likes