In regards to JBullet, you can find several threads here talking about it, but to summarize, it does not support all the features of native bullet, has several major bugs that need to get fixed, and no one is likely to fix them because we have other physics engines that do work. (Also considering that many of us are now using Minie, I personally would like to see bullet removed from JME4 altogether and make Minie the official third party physics engine, but I know there will be a lot of people against that)
As for OpenGL and Vulkan. There are many things that work very differently in Vulkan than OpenGL. Vulkan is much better suited to multi-threaded environments. It also has a unified environment where there are no differences between mobile and desktop (in theory).
As for implementing both:
I think that it is possible to do. The major things that we use in jme are objects such as Nodes, Spatials, Geometries, and Lights for organizing the scene graph. We already have an opengl engine for doing this. If we create an abstraction layer between ‘our’ side of jme and the ‘rendering’ side of jme then in theory we could have both. With that said, it is not as simple as just having vulkan calls instead of opengl calls. The vulkan layer would have many moving components to take advantage of its power. I am not very familiar with the inner-workings of vulkan, and I am hoping we have someone here who is, or can get someone.
Ideally we do not cut opengl support, at least not in JME4 (perhaps 5?). I see no reason to remove something that works and is still widely used. But by supporting Vulkan we can gain access to new technology that is not getting supported in opengl (I will use my favorite example of ray tracing shaders).
Again, I know very little about how Vulkan actually works, and I am by no means an expert on opengl. It would be great if someone with experience in opengl can give us a opinion on if we can abstract the rendering system away from jme-core and break out rendering support into jme-opengl and jme-vulkan.
It also has a unified environment where there are no differences between mobile and desktop (in theory).
That is in fact great, and i will be on the front line to promote vulkan, once this will become a reality. But for now, we don’t even have full desktop coverage, since older gpus aren’t getting vulkan support. And in fact we are talking about keeping opengl as an alternative renderer…
Vulkan is much better suited to multi-threaded environments.
Yes, but vulkan won’t manage the multithreading for you. OpenGL will internally choose when to run your commands and will make assumptions while in vulkan you can have multiple threads sending commands to multiple queues and you will decide when and what to wait , but, how are we supposed to implement this in jme, where we don’t have a programmable pipeline?
And do you really need that?
There are many things that we can do to improve the current opengl renderer, and i would rather invest time doing that.
Sure, vulkan would be great for marketing. But nobody is making money from jme’s popularity, and for my personally needs i would choose a stable old weird opengl renderer over an alpha vulkan renderer any day. Until we can make a full switch to vulkan and drop opengl, at least.
@RiccardoBlb that is why I would rather see OpenGL support stay in JME4. As it stands, no matter what we do, the initial Vulkan implementation will not be perfect. But we need to start the transition at some point, and it would be best to start the transition now so that when Vulkan has universal support, we have support for it.
As far as mobile devices go, widespread support is going to hit before desktop, just due to the shorter lifespans of phones in the market. And my understanding for desktop is that many driver updates are providing Vulkan support to GPUs.
As for improving our current OpenGL implementation, I think we have a great implementation currently, but there is always room for improvement. This would be as good of a time as any to make any major improvements to our OpenGL implementation in the engine, and it will be easier to do so once it is decoupled from the rest of jme.
If there were a person here that had the credentials to take the helm For vulkan I’d say hell yes, but we don’t. And if one of us decides to become that person they would need to go do the groundwork first before deciding that road should be taken. Right now the blind is leading the blind.
I’m sure you also realize that the existing workflows are capable of producing Triple A games. The majority of us are developers, though, not artists or modelers. Our community is bound together by the engines strengths. The engine is very programmer-centric and not a modeler/artist environment. That’s why you don’t see the “wow” factor images and videos.
In my opinion, in addition to improving the engine, the SDK really really needs some love. That is where the effort should be directed until such time someone is in the position of being very experienced with Vulkan.
Stuff like terrain generators and vehicle creators, particle builders, etc. are all available already but are programmer based. People these days are demanding a GUI environment. It makes for rapid development and tweak heaven.
If you want to see this engine shine, give it a front end.
Off the top of my head, useful things that we don’t have or the engine is not using:
VAO
UBO
PBO
SSBO
Indirect Rendering
Occlusion Queries
Compute Shaders
I’m not saying that all the other engines are using them, but those are some features that “modern” or “less modern” opengl provide and that we are just ignoring.
I’m not sure why we’d resist replacing jme3-bullet with Minie at this point. It’s a one to one replacement (i.e. you’re still using Native).
JBullet is a little less obvious to me - native stuff tends to come with both good and bad. There’s something to be said for the simplicity and reliability of a pure-Java solution (OGL dependencies aside). But I understand where you and others are coming from. There’s also something to be said for supporting fewer options to keep things maintainable.
One thing to mention in the context of Multithreading is that you require the engine to be built around it, and at least jme3 isn’t at all.
Actually if the engine would be built around it, even openGL supports multithreading.
It would be interesting to investigate CS:GO and other Source Engine Games as they leverage Multi-Core Rendering on OpenGL and I think I read a paper about that specifically where they claimed that Multi Threading is easy, because most accesses to the scene graph are simultaneous reads, which can be “cached”.
OTOH, from a 10,000 ft/meter distance, the current (complex) multiple-subproject structure seems to have been a consequence of not having the module system available.
Part of the point of the Module system was to make it easier to construct collections of packages for custom deployment, Which in jme seems to be mostly done by the SDK, or complex custom build scripts.
A Vulkan version of JME needs to be designed from the ground up to take advantage of the totally new way to do things. If OpenGL compatibility can be fit into that then great.
If you just shoe-horn Vulkan in underneath the OpenGL-facing renderer abstraction then you’ve done nothing important. On modern cards, regular OpenGL support is basically already doing that.
For a proper Vulkan engine that’s anything but “We GeT to InCluDe tHe BulLet in The List” it needs a proper design that checks all of the existing assumptions. Else, just add the bullet to the list anyway with a little asterisk that say “where modern cards are already implementing OpenGL on top of Vulkan”.
I see it this way as well. Many things could be improved in the existing engine and front end side (the sdk or any other scene builders that have pooped up over the years).
I think it’s pretty important to have some flashy graphics in videos to really show off the engine and attract (and keep) a larger community. Many shaders, effects, etc exist in research papers and other engines already, and can basically be implemented without too much work.
As others have said, the engine isn’t taking advantage of many modern OpenGL functions and paradigms, and there’s totally a lot of room for improvement in there. The difficult part is falling back to older OpenGL when the card doesn’t support it, and keeping these two parts in somewhat feature parity. If there’s a vulkan renderer as well, you’d have that same work to do… but worse.
Sounds like an argument if your hypothesis here is correct… That also makes it seem that if JME were made into a modular library, it should include simplification & review of the Gradle configs.
It would be nice if the Gradle builds were simpler, but I assume they’re about as simple as was possible (at the time).