i think thats general problem why Vulkan was still not “in progress”
There are many to change related to OpenGL that might require to be done much different way in Vulkan. But here are you, and it depends if you gonna learn all of it. Because me as developer, i would love to see Vulkan, but still maintain all features JME3 give me + more if possible. Ofc i dont mean deprecated things here(but it also would be nice for indie devs that use them).
So what i mean is that if you would “write most from scratch” i would probably just dont use it until it would be same “big” as jme3 is and working same fast or faster. And no users = no beta testers.
So best option would be write Vulkan maintaining most of features(not deprecated ones).
ofc i speak here only about Vulkan, because its a main problem here. cleaning up deprecated repos is not a problem. (most of us know what is deprecated anyway - yes it is problem for new members).
As a Engine user i can just tell im Happy with current engine - Minie physics, 3.3 animation system, the pbr (that was long waiting for), GLTF exporter(work perfectly). Maybe just a lack of SDK for 3.3 working properly might be problem ;p.
But here Vulkan would be same nice as when PBR and GLTF was added. (not to mention that PBR shader/etc would need to be adjusted too when change to Vulkan)
so i hope you will be brave enough to spend this years to learn and make it
I mean a great help for future developers would just be keeping everything better organised in the core. And something @sgold mentioned waaaaayyyyy earlier in this topic is definitely
just as crucial.
Edit: And as far as keeping at least all of jme3’s current GREAT features, I was definately planning on doing that.
Really dont get it wrong (sometimes im angry that he demotivate much, but well, he say what he think)
Paul is almost always right, but it refer to “current state”, so it dont mean you cant success after years.
And anyway he meant it when you would write most from scratch not using existing code. ( so if Paul dont said Fail for this condition, it sounds optimistic ;p )
Well, I am definitely not likely to outsmart an Engine Leader when it comes to pretty much anything jme related so I didn’t bring anything else up. But I’ll continue my work. If I can figure out how to work with just implementing it into current core code, I’ll do that. But until then, hopefully soon, I’ll be writing a new renderer, which I’m making VERY similar to current jme3, because I know changing up top level stuff thats been de facto standard for years isn’t going to go well.
Yes, that’s what I meant. It sounded like he was starting out already ignoring everything that came before as “bad”… which was a recipe for failure for sure.
My fault if I didn’t make that clear enough.
I’m just working on a jme4 core, filled with javadoc, no deprecated anything, and hopefully smaller. When I finish, it should be able to be a drop in replacement for current jme3, so I’m pretty much changing nothing up front.
Edit: Only the “low level, deep stuff” will be changed, but likely with some significance to allow Vulkan to work.
just please note you will anyway need change some of “not-core” things.
Lets say Utilities like batching, if im not wrong its using OpenGL prepared buffer, that would need to be Vulkan adjusted(i belive? - because im not sure if same buffer can be used) so then this Utility also need changes and maaany more things buffer related. (even my custom voxel code)
And it might refer to more classes, but its fine, just a lot work to be done.
Yes, in fact thats kinda where I need the most help at, the JME-LJWGL3 lib.
Thats where all the low level stuff happens at, but I really don’t know what the method calls are that lead to those of the jme-lwjgl lib.
Honestly, I might be able to work on this pretty easily if only I knew how that works.
@tlf30 were working on it, but he tried “make wrapper for both OpenGL and Vulkan”
maybe if this is so much problematic, then trully he should skip doing wrapper, but just make Vulkan Api only… (that Riccardo suggested earlier anyway)
i think you should look at his repo(if he done this work there) and talk with him.
Yea I’m trying to follow @tlf30, but its just way too based on OpenGL, but there is too much disagreement mainly from @pspeed and @danielp about removing OpenGL in a jme4 as people are still going to have not so great computers.
and generally i agree, its perfect solution to have wrapper, thats why i also suggested BGFX.
but:
BGFX - most of devs disagree to use it, reasons: its next third party that need care and can be abandoned.
Wrapper for both OpenGL and Vulkan - Best option, but @tlf30 had a lot of issues writing it.
Just Vulkan API - most easy solution, but well, like the quoted you provided have much disadvantages in support developers.
My hope is that there is a JME4 that may be based on what work Riccardo is doing for a reconfigurable pipeline.
cant Ricc pipeline be used in Vulkan too? i belive it could. Would just require some shader adjustments? Anyway as i seen Riccardo already almost done it. so its more like JME 3.4
At this rate we are going around and around and around, again and again and again about which method to use for develpoing jme4 because there is too much disagreement from everyone regarding BGFX vs Wrapper Vs Just Vulkan, each one stating their own key arguments that must be accounted for.
I’m trying to go Wrapper route, but not much luck.
Well all sides are going to have to give something no matter what.
But if we are bringing this up again, something is wrong, because we can’t make a decision.
One of the really nice things about JME is how “to the metal” it is. The Mesh object is literally just the parameters that will be passed to the draw call. It’s beautiful, simple, and as fast as you can get.
Any “layering” you add on top of that detracts from performance in some way… either in how you marshal it to the native layer or in how you interact with it at runtime.
Edit: but that means that a Mesh, VertexBuffers, etc. are “OpenGL”.
(sometimes im angry that he demotivate much, but well, he say what he think)
when it comes to pretty much anything jme related so I didn’t bring anything else up. But I’ll continue my work. If I can figure out how to work with just implementing it into current core code, I’ll do that. But until then, hopefully soon, I’ll be writing a new renderer, which I’m making VERY similar to current jme3, because I know changing up top level stuff thats been de facto standard for years isn’t going to go well.