That would be dumb. Got to be a better way to do it…
I don’t believe there will be any issue with shader nodes or runtime compilation of shaders.
1 Like
I don’t like bringing up old topics again too much, but here it is important.
Unless I’m really missing the bigger picture, the people developing games with jME will not be dealing with any of the low level stuff like the rendering APIs and I can’t think of any exceptions. So in my opinion, simply dropping OpenGL won’t have any detrimental effect at all on the game developer.
If @pspeed is talking about the engine developers having to get used to Vulkan, it shouldn’t be too hard to get a lot of Vulkan developers onboard because even now we have a lot of people throughout the community including me trying to help in someway to at least add Vulkan support.
So far I have not seen many cons at all concerning just switching to Vulkan completely.
After all, this is a very distant jME4, so by then OpenGL might be dead. So my point is what negative effect would it have on the engine to just at least deprecate OpenGL?
If someone does give a very good reason to keep it, then we should keep it. But if not, I’m not too sure why to keep it.
Let me know what you all think
This is the problem with dropping OpenGL support - many of the game developers working with jME do work with the lower-level APIs. You have to work with them anytime you want to do advanced features that the engine doesn’t support already, and you often have to know (or are at least benefited by knowing) what’s happening when you’re working on custom shaders. Game developers often work with low-level APIs when developing advanced graphics.
It’s highly unlikely that OpenGL is going to die anytime soon. Attention is shifting to Vulkan for sure, but there is a lot of OpenGL code in the world. The negative of shifting to Vulkan only is that (a) we artificially restrict developers who want to develop against OpenGL, and (b) we lose options for platforms that do support OpenGL but don’t support Vulkan (some monkeys have done partial ports to the web platform via WebGL, which is out the window without OpenGL support).
OpenGL support already works. All it needs is some refactoring for internal API changes when Vulkan support is added, so there’s nothing to gain and a lot to lose by throwing it away.
2 Likes
I like your points, but my overall point for just removing OpenGL was definately something brought up earlier, shader support. It needs to be render agnostic like you said previously, but again somebody needs to work on that project which will probably be a big challenge. Also, maybe we should add support for something like WebGL in jme4, if the plan is still to build upon OpenGL
The biggest issues with shaders are just supporting the same set of rendering backends (which in the absolute worst case means separate copies of the same shader, one per backend) - if we support any rendering backends apart from Vulkan (like WebGL) we have the same problem. The only way around this is if all internal shaders are implemented via shader nodes and all rendering backends implement full shader node support - then the rendering backed specifics may be able to be handled by the shader node “compiler” and not in the actual nodes themselves.
Well for certain if worst does does come to worst, having 2 rendering backends, Vulkan and OpenGL, should definitely be the maximum. I think you’ve laid out the most best plan so far, so next challenge for anyone developing jME4 needs to be the shader support.
1 Like
Well, we may need to consider Metal at some point. I do think keeping engine shaders in shader nodes as much as possible will help with these issues a great deal.
Edit: As attractive as keeping rendering to one or two backends for all platforms sounds, the unfortunate reality of graphics programming these days is that that approach is limited in practice. If you keep to one or two backends, you have to deal with platform compatibility issues and/or adapter layers that bring their own problems with them. If you don’t, you have to write a renderer for each supported backend with the upside that you probably have to deal with fewer platform limitations and compatibility quirks. Either way you pay in code for the platforms you support - you just have to choose which set of problems you want to deal with.
Well it seems that since Apple hasnt completely pulled the plug for OpenGL support, so that is still an option. And also Vulkan though not natively supported on Mac has an extension for Metal, MoltenVK, which allows Vulkan code to be used on Mac iirc.
If we were to actually do many different platforms, it seems like bgfx would be the solution, but I know it is criticized a lot, especially by core developers for not having direct access to the native APIs. But I’m not really into the idea of using Bgfx in the first place.
My point was that if you want players to PLAY your game then you need to target hardware that is not the latest and greatest.
The GAMERS that will play your indie game or not the ones buying water cooled souped up 9-GPU monster machines. Vulkan still has a limited market penetration in the group that will actually play your game.
If you are just making the game for yourself then sure, use whatever you want.
Edit: and sure, if you are imagining that JME4 won’t be ready for 5-6 years, I’m on board. I’ve been saying that from the beginning: a vulkan-only engine should be targeting like 6 years from now. And I’m a big fan of dropping openGL support in a Vulkan engine. My argument has been that it’s not JME 4. But maybe JME 5.
3 Likes
Apple has not removed OpenGL, but it’s officially deprecated (likely no further attention from them, including bug fixes) and is capped at OpenGL 3.2, which is an 11 year old version. The newest OpenGL spec is 4.6. MoltenVK is great, but it only supports the Vulkan 1.0 spec, and the newest spec is 1.2. Unfortunately, MoltenVK does not seem to be getting much attention towards supporting the 1.1 or 1.2 specs yet, and there’s no guarantee that Vulkan and Metal will continue forward with enough similarity to maintain 1 <-> 1 feature parity. For jME to continue to support Mac well, it may ultimately be necessary to target Metal. We’re not there yet, but I think it’s likely we’ll end up there at some point.
The trouble with BGFX is that it’s even a bit worse than cutting support for low-level APIs - when developers need to go beyond what we support out of the box, they need direct access to the native API. With BGFX, jME would be a wrapper over the top of another wrapper with all the trouble that brings. At that point we don’t even control the rendering API or feature set, which is not a great place to be in for a game engine.
1 Like
Metal will be a tricky mostly because it is exclusive to Apple devices, which I don’t use, and I don’t know how many people here actually have Mac machines to develop on. And we would have to write our own bindings unless LWJGL gets one out, but as far as I know, they don’t have any plans for one yet.
How many folks here are developing on Mac is definitely relevant, but it’s more about how many want to target Mac as a release target.
LWJGL not having a wrapper is a large downside - if we end up at the point where targeting Metal directly becomes a direction the community wishes to move toward we’ll have to hope LWJGL either supports Metal already or will accept a Metal wrapper as a contribution. It’s also possible that by then MoltenVK will support the newer Vulkan specs and targeting Metal directly is a moot point. If we could get up-to-date Vulkan support on Mac via MoltenVK I definitely do favor that over targeting Metal directly unless there are other overriding concerns that make it a necessity.
Sorta similar to what @pspeed is saying regarding OpenGL
@pspeed if you want players to PLAY your game then you need to target hardware that is not the latest and greatest.The GAMERS that will play your indie game or not the ones buying water cooled souped up 9-GPU monster machines. Vulkan still has a limited market penetration in the group that will actually play your game.
In this case, having an out of date MoltenVK wrapper sets in stone that no matter how old the Vulkan capable machine, it will be able to run just fine.
True - we need to balance maintaining support for older machines with adding support for newer hardware capabilities.
As far as native Metal, thats an example of why I’m not the biggest fan of relying on LWJGL for the core backends, because at some point or another we need bindings that they don’t even have plans for like Metals. So I’m pretty sure that will definitely need a community contribution.
And then in three years, Apple decides to drop metal and go with something else.
2 Likes
Well I think I’ll embark on the journey of adding Vulkan to the core lib. But before I get too deep into that. I’ve heard about all the cool projects that the dev team is working on right now, and I’m sorta still wondering about just working with 3.2.4 or wait for these new features to be added?
If it would be better to wait, then when will these approximately be released?
As there is a lot to do, i would prefer to use 3.2.4, specifically start with @tlf30’s jme4 project, as he has already gotten some work done. But I’m open for opinions.
At last! Something I have an opinion on.
Any new development should start from the current master branch.
4 Likes
agree, but have in mind all new features (even the one Riccardo is doing)
but, when core devs will not be involved in this, i dont see much sense. I see in some posts lack of JME knowledge, so if there will be no mentor, i dont see it well.
@ItsMike54
in my opinion you should seriously listen what Riccardo have to say since he is Shader Core Dev and its directly involved with rendering backend.
He said Vulkan direct integration is required, and that there are many things to change.
Also i agree what Paul said, but i belive in that time you could learn things first. Because knowledge here is key to make it properly.
so in my opinion in general you can start, but take it as lesson first before doing “real code”. (because we want well-coded engine right? - at least vulkan core core code) and like Paul said, but something can be started now.
So in short: its not that easy like you think(there are much more to re-code than was mentioned), but i belive in you and anyone who want achieve it.(if someone really want, its possible)
2 Likes