yes, but then no need worry that for example MacX will deprecate something, Even Metal is supported in it
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.
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
what if you will need something that is not supported by bgfx?
im not specialist here , and im not sure what can be needed,
so i ask for overall your opinion 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.
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
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
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.
From my point of view - if I were to offer my opinion on how to manage this situation, you need to focus on a few things:
For all intent and interest, there needs to be “the one” that will be the captain of the ship. That person needs to have a clear understanding of what they’re doing. That may mean a 3-6 month hiatus readying themselves if they are not already proficient in the said field. They are also going to need a lot of experience with the existing engine to understand how it works - and how a rendering engine works. So far as I am aware this role is still very much open for grabs. Somebody needs to put themselves in this spot. It will not be delegated.
My management of this situation would not be to modify the existing engine but to build this pipeline independently - as a project in its own right - and then bring in the areas you need from JME as you need them. It strikes me as a far easier way - especially considering a lot of things want refactoring and removing. There are areas that are likely to want to be re-written, too, such as the Post Processing pipeline.
You need coordination. At the very least a to-do list to remind those invloved routinely. A final outline of exactly what it is you’re doing and what you’re NOT doing. Do NOT discuss on discord. Discuss on the forum where it is well documented and on-point. Nobody needs to read 6 hours of ramble to find a single response.
Do not forget that you already have a very strong and reliable codebase to work from. Try to understand it’s strengths and weaknesses. It would be madness to ignore it. It’s like a book of the journey you are about to make. Learn.
Start making concrete steps. Make it happen.
Just a note:
There are areas that are likely to want to be re-written, too, such as the Post Processing pipeline
Riccardo already work on it based on current 3.3