LWJGL BGFX - crossplatform render lib in LWJGL

Hello, some time ago, was talk about migration to Vulkan.

im not specialist here in this Category.

But i noticed that BGFX lib is almost well supported in LWJGL 3.
It allow even more than just Vulkan, and it seems to be nice wrapper.

if im correct this is based on:

Supported rendering backends:

  • Direct3D 9
  • Direct3D 11
  • Direct3D 12
  • Metal
  • OpenGL 2.1
  • OpenGL 3.1+
  • OpenGL ES 2
  • OpenGL ES 3.1
  • Vulkan
  • WebGL 1.0
  • WebGL 2.0

Supported platforms:

  • Android (14+, ARM, x86, MIPS)
  • asm.js/Emscripten (1.25.0)
  • FreeBSD
  • iOS (iPhone, iPad, AppleTV)
  • Linux
  • MIPS Creator CI20
  • OSX (10.12+)
  • RaspberryPi
  • SteamLink
  • Windows (XP, Vista, 7, 8, 10)
  • UWP (Universal Windows, Xbox One)

As i seen there is also Universal shader language(for each rendering backends) compiler:
or linux:

I write because of 2 reasons, i need to know if you know about this(that is supported in LWJGL3) and why there were talk about support Vulkan(and that we require some specialist to know it and write) while here no need to write that support(because vulkan support is already written there).

So i wanted to let you know and hear what do you think about it overall. (@RiccardoBlb, @pspeed)
I know OpenGL change is distant future anyway.

Only seen @glh3586 (Jedic) mentioned about it on HUB, but was not mentioned that its supported in LWJGL3.

some links:


1 Like

I am not sure, this adds another abstraction layer.

yes, but then no need worry that for example MacX will deprecate something, Even Metal is supported in it :slight_smile:

This would be a total rewrite of all things JME rendering. It’s VERY tied to OpenGL.

Good time to even change the name if you like, it would be so different.

1 Like

yes, i understand its a total rewrite. (and like i said i know its distant future)

i just thought, if someone will, it will be better use this instead of just Vulkan? Because here dont even need Vulkan knowledge?

because i remember when you told something similar like “we need someone with good Vulkan knowledge”

until you need to do something vulkan specific, and now you need to worry about the abstraction layer and backward compatibility for all the other apis

and now you need to worry about the abstraction layer and backward compatibility for all the other apis

what do you mean? itsnt BGFX already manage it? if you mean JME classes, it would need total rewrite so backward compatibility is like impossible.

anyway i wrote this topic, so if something gonna be done in future, it could help a lot. i thought it is good news :slight_smile:

what if you will need something that is not supported by bgfx?

im not specialist here :frowning: , and im not sure what can be needed,

so i ask for overall your opinion :slight_smile: if there could be something we need but we cant. (i understand you also might not know not looking at it more deeply, but maybe you have idea now)

I’ve spent some time working with BGFX both in c++ as well as the java api. The shading language they use is basically glsl but with some of the keywords changed, but the big gotcha is that it doesn’t compile the intermediate shading language into the platform specific ones automatically (IE opengl, metal, vulkan, etc). There is a command line tool you need to use before the application runs and it generates the compiled shader code for each of those backends. It isn’t a huge deal, but it does require some work arounds and build magic to work if you are doing something cross platform since you can’t compile directx shaders on osx for example.

Overall it has been pretty easy to work with and they have a pretty large example list. I’m pretty sure the java version runs on top of glfw just like lwjgl3. As you said, it would require a rewrite but it would also alleviate the need to run and maintain different back ends for opengl / vulkan / directx. I haven’t run into anything that’s missing at the moment, but I haven’t done anything super complicated with it yet either.


I have been working on the JME4/vulkan integration. And no matter what it will require a rewrite to do anything other than opengl.

I have to say, this would be much simpler. The amount of abstraction that I have been adding to the engine to get support for both vulkan and opengl it a headache, then maintaining two different render platforms with all of their bugs would be a nigh mare once it is all working.

Honestly, I think this is a good solution. I have not looked into it before, but can it do vulkan specific extensions like RT? Can we take advantage of the vulkan multithreading capabilities.

I would be interested in performance. How much performance is lots in the abstraction.

@oxplay2 thank you for the information.

1 Like

i knew you were working on it, but i thought you dropped it after it lost interest of others.

good to know you did try much more. Yes since this abstraction layers is already written by someone and injected into LWJGL, it would be much easier for you i think and i hope :slight_smile:

Yes, I have been loosing interest, but I have been chipping away at it.

When going to BGFX instead, if nothing else, I think it would be good to remove the ‘3’ from ‘jme3’ in the package name when we do the swap over, even if we still give it a 3 version, like 3.5 or something, it will make changing version much simpler in the future.

@glh3586 since you have experience with BGFX would you like to help work on the conversion?

Perhaps we can build a new JME4 repo and start getting organized for the transition to BGFX, it would be good if we could get it inside of the jmonkeyengine organization. Or we could just build a jme4 branch for now and work in the main jme repo.


So I spent some time this weekend going over BGFX again. I still have some more research and testing I would have to try, but these are some sticking points at the moment.

  • Shaders have to be compiled ahead of time using stock BGFX. There are extensions out there to do them at runtime but it would require compiling bgfx from scratch along with the lwjgl lib. It’s probably possible to move that functionality to it’s own jar which could then be removed from production builds to reduce file size.
  • BGFX is a higher level library so I don’t think you could break out raw access to something like vulkan by default so it would limit you from using extensions from the various graphics libraries. From what i’ve seen, I don’t think there is anything JME currently supports that BGFX doesn’t give you access to, but if there is something bleeding edge that people want to do it would require changes to BGFX.
  • I don’t have enough experience in compiling java to other platforms so I don’t know how well the bgfx lib will work if you want to say compile to say IOS or the web from java. I wasn’t able to find any examples and there is very little info about the bgfx wrapper that lwjgl provides. I know it works great on the c++ side but I don’t know about the java side. I’m not sure if it would be worth it to switch if this part wasn’t ironed out since pretty much all modern game engines work on at least the PC platform and mobile.

Overall there are a lot of edge cases that need to be considered before a serious attempt at this is made.

I faced the same problem when trying to work with lwjgl’s OpenVR wrapper. I guess they don’t bother providing documentation for their less commonly used wrappers :confused:

Yea, they only ported like 2 of the 40 something examples that bgfx ships with too which is a bummer. I was hoping to run their stress test to get an idea of the performance differences.

I don’t have the level of experience with BGFX that @glh3586 and others here have, but I’m concerned by the prospect - using it may well lock us out of accessing lower-level API features, which is a substantial downside. It’s not that terribly hard to design and implement usable abstractions over lower-level APIs - I’ve done them before. It’s certainly not a cakewalk, but it’s not prohibitively difficult either. As @oxplay2 mentioned in another thread, there’s the additional downside of relying on another dependency in addition to LWJGL, which adds about 4x more ways for jME to be negatively impacted by another project dropping or lagging support. I believe jME would be far better served moving forward by keeping our rendering in-house rather than outsourcing to another project.

What kind of low level stuff are you looking to have access to? As far as I know bgfx supports everything jme currently supports and then some. I added that to my list since it was a concern but I admittedly don’t know how big of a deal it is.

Keeping the rendering in house is all well in good if someone wants to do all of that work to keep it current as well as support new platforms. Given the community size, something like bgfx would offload some of that support and maintenance.

It would be like writing an engine on top of another engine.


the only problem persist, is that someone from JME community will need write it in future.
Maybe its worth then for this person to look at BGFX solutions and do own more light-weight solution.

It’s not that terribly hard to design and implement usable abstractions over lower-level APIs - I’ve done them before. It’s certainly not a cakewalk

Well, nothing is terribly hard if you have knowledge to know how exactly write it.