I know this a topic that won’t matter for a while, but there’s been a lot of talk on the forums about switching to a different api for rendering such as vulkan. I’ve also seen many responses about this being a jME4 thing, so I’ve decided to make a page where people could give some ideas.
Here are my ideas for jME4:
Vulkan (or something similar) should be default, but there will still be some openGL support.
The openAL for audio should be removed all together and replaced by something else.
If it dosen’t happen already, @sgold’s Minie physics should completely replace bullet, assuming there is an Android version of it released.
I think OpenAL is kinda limited as to its abilities. Its works fine now but when I look at some popular ones like WWise Api, that allows integration into unity ide to not only handle audio but also allows editing of the audio, I feel like there could maybe be a similar audio Api for jME, maybe being able to integrate into the sdk to edit audio files.
Also a side thing, OpenAL isnt open source, so its kinda limiting when it comes to the license
Editing is a pretty different concern than playback and uses a lot of functions that playback just doesn’t need. It would be important to be able to only ship the parts of the library responsible for playback with jME so that those not using it for editing at runtime don’t have to pay the cost in download sizes.
Also, jME is in a very different place than Unity in terms of editors - they have the official Unity editor, we have the SDK, a couple of command line-oriented dev tools, and for a while we had at least one separate editor.
Personally I’m not attached to OpenAL, but it’s a major change and not one that I see as worth undertaking unless there’s an alternative that gives a clear advantage in rendering audio. That said, since we’re talking about jME4 it may be worthwhile to consider keeping the audio rendering (& preferably graphics rendering also) cleanly abstracted behind interfaces that would allow swapping out OpenAL for an alternative renderer at the developer’s choice.
I mean even if it is a seperate project, it would be nice to have an audio editor in the sdk at some point, like even now it has plugin support for gui editing, 3d model editing, and probably some other tools. Unless we are using OpenAL Soft, the audio engine like OpenGL would be closed source, unlike all some of our other engines. Not very important but at least if we had like an open source one we could make it more customized for jME
JME4 should also re-write most of the JavaDoc and remove the particle system from the core library. All deprecated classes and methods should be deleted. The terrain library needs a redesign. Oh, and all the libraries should have extensive automated tests.
Ok, for now I’ll work on the basic things @sgold said needed to be done. Once I finish that I’ll upload it to github and start modifying it for a future jME
i posted about BGFX to give topic to talk about, but myself i have mixed feelings after talk with Riccardo.
Well, its next third party we need care of, not just LWJGL(that support it itself).
But what if LWJGL will suddently in next versions say “lets dtop support it”.
Then would need write own Java wrapper.
Also like Jedic said, we will have no direct access to lower APIS like Vulkan API.
Advantage is that we dont need care about writing all of this and its for almost all platforms.
But disadvantage is a “risk” that this third party could go abandoned. I would care more to see how much active it is and how its going forward. Also we dont have access to lower apis.
I don’t know enough about any rendering APIs as to decide what to put into my jME roadmap, so I think that topic must be further discussed and finalized by you all.
Some methods have no Javadoc at all. Most of what’s there needs to be checked and rewritten, I think.
I suspect Javadoc has been neglected because JMonkeyEngine is open-source: users who persist quickly learn to read the source code instead of relying on the Javadoc.