jME4 Development

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

Regarding the terrain library, I’m off to work on doing some cleanup, should I add the jME license at the start of each file? Most of them don’t have such a header.

1 Like

That’s issue 1001. It’s a tricky issue, in my opinion.

I’m uncomfortable slapping new licenses on files I didn’t create. If we can determine the author, I think we should at least attempt to contact them to ask their intent. In cases where the author is unknown, the person who submitted the PR and/or integrated it might have some insight.


im happy you work on it. :slight_smile:

Just as a note, i might be wrong, but if someone push a code file without ANY license, imo he agreed this files to be under project general license, because he pushed it and didnt specify own one.

Each file should anyway have license, true.

The most important anyway is to have everything new BSD there. if you seen GPL it should really be get rid of.

1 Like

Agreed. The only problematic cases are when there IS a separate license in the file… and it’s not the same or incompatible.


Don’t you agree to that in any case? Like I can’t just commit code and say “this is my proprietary license, every download costs 10$”. But I guess it’s an attorneys job to discuss whether the repo owner would have to reject such commits or whether the code automatically falls under the repositories ownership/licensing.

It’s actually tricky, because iirc you don’t loose ownership over your code and thus can re-release it under a different license for a different project.


yes, you are right.

It’s actually tricky, because iirc you don’t loose ownership over your code and thus can re-release it under a different license for a different project.

I remember there already were situations where same code were under 2 licenses. It were just going different changes from basecode.

simple example is that someone take JME and rebrand it and push as “general” different license, because well… he can. Fact that noone will use it, but still… he change some file under new-bsd and add own methods and rebrand it to GPL for example. (since GPL is over new-bsd, cant be done other way - cant be changed from GPL to new-bsd). So if any GPL file exist in JME, should be removed and written own way. (i hope there are none) So idk how it would refer to 10$ license like you said. All i know that JME is marked as new-bsd, it means user should not look whats inside, because he already receive general information. its just more about “stick” to this information really. Lets now assume Unity have its license, but its partially closed-source (not all open) then how you could even know if all files in closed-source are same license?(since some licensed dont affect just a code) you dont know, but you have general note only. All of this is very hard and require attorneys job like you said.

What i dont like myself in GPL is that someone who is GPL file owner can ask you for a sourcecode of your published project. That is unacceptable. Ofc, not every GPL owner do that(its tricky), but they can.
And ofc GPL is like coronavirus that infect other projects that use it also need to be GPL…

What about work done in PR 1078 ?
It includes:

  • Adds BufferObject to correspond to BufferObject
  • VertexBuffer now extends BufferObject

This change I did after a brief discussion with @pspeed on discord 10 months ago. Now, I do not know if this is how you envisioned it, or if you hold a different opinion now, but it would be nice to hear your current opinion on this matter.


  • QueryObject is added to support queries
  • RasterizerDiscard option
  • TransformFeedback is implemented using all of the above
  • finally, the changes were done so as not to break backward compability
1 Like

Ultimately, I defer to ric on stuff like that. I’ll take a look again this weekend to see if I have a “java code” opinion on it.