jME4 Development

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:

  1. Vulkan (or something similar) should be default, but there will still be some openGL support.
  2. The openAL for audio should be removed all together and replaced by something else.
  3. If it dosen’t happen already, @sgold’s Minie physics should completely replace bullet, assuming there is an Android version of it released.
  4. SpiderMonkey could use some work.

Let me know what you all think

AS OF APRIL 9, 2020:
Visit here for list of jobs need done: Roadmap · Issue #3 · tlf30/jme4 · GitHub

5 Likes

Looks like a good start, although I do have some questions.

  1. Why? What’s wrong with OpenAL/what would we gain by switching to another API?

  2. What candidate(s) do you have in mind as replacements?

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

Two short notes:

  • There is jmePhonon as replacement to openAL
  • There is probably a reason, Stephen created minie instead of fixing jme3-bullet-native

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.

2 Likes

Yep, maybe keep a copy of javadoc included with the engine for reference?

This is something that can even be worked on for 3.4

Javadoc JARs for most of the JMonkeyEngine libraries are available from JCenter. For instance, here are the jARs for jme3-core-3.3.0-beta1:
Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog

There are also JavaDoc links at the top of this webpage and in the sidebar, though I don’t know what version they correspond to.

And Javadoc is bundled with the SDK, though the popups only work in ANT-based projects, so I don’t use them much.

Ok, do they simply need to be better organized or do they need to be completely rewritten?

1 Like

I have a sample roadmap i put together a while back.Roadmap · Issue #3 · tlf30/jme4 · GitHub

I think BGFX will be a better option than implementing Vulkan along side opengl.

1 Like

Thanks for the roadmap.
I would be happy to contribute my work on this.
What are the advantages of bgfx vs Vulkan?

1 Like

See LWJGL BGFX - crossplatform render lib in LWJGL - #17 by danielp for BGFX. Basically it handles cross framework support via a unified interface.

Edit: that repo is very out dates right now. But the issues are relevant.

Also, base jme has already fixed some things that are in that road map. I will update it when I get home.

@ItsMike54 i would love some help on this, if you are able to contribute in any way.

I think we need a new jme4 branch based on 3.3 final (whenever it gets released)

The hard part will be keeping up to fixes in master.

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

1 Like

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.

1 Like

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.

Ill try to assemble a group that can do that, for now, I’ll be busy on fixing the issues regarding the libraries you mentioned