Next release of the Engine

I wonder whether it’s time to start working toward a v3.5 release of JMonkeyEngine early in 2022, so I’m requesting input from the JME community:

  • What features and fixes do you hope to see in v3.5?
  • If a 3.5-alpha release were available today, would you use it?
  • Would you rather see a maintenance release, in other words v3.4.1, and if so, what low-risk bug fixes should v3.4.1 include?
  • Will you have time during the coming months to contribute to development, testing, and documentation of JMonkeyEngine?

May be documenting files that still lack java docs & some elaboration, at least java docs, other ideas may be creating a roadmap(uml diagrams) for the engine for the new contributors…but those aren’t new features.


I hope to see a fix for the BitmapText RTL line wrapping bug #1158. :slightly_smiling_face:

I can help with testing.

  • What features and fixes do you hope to see in v3.5?

Totally implausible and not going to happen, but my “genie level” wishlist item would be a double precision scene graph. I have a lot of complexity (and bugs) introduced into my game trying to translate a double precision world into an offset float precision graphics (i.e. physics engine says you’re at 10011m from origin, but rendered as if it’s at 11m because the offset is 10000)

I know this is fairly niche.

  • Will you have time during the coming months to contribute to development, testing, and documentation of JMonkeyEngine?

Historically I’ve not found much I feel qualified to fix, but if I were to be able to then yes. As before I can also plug in the alpha and run it through my games test suite


I would rather see the wiki updated for the new animation system than a new release, this is just on the top of my wish list.


Just a thought : I think if we have managed to fill the gaps of java docs inside the new animation system classes (+ some jme utility classes as well + native android code lacks docs) & provided a good roadmap for the new contributors (to understand the aspects of the engine easily), then we may have more number of people working on the wiki.

The contributions pages on wiki & github still not active yet.

  • extraction of the inner class Layer -contained in the AnimComposer- in a separate class, with getter/setter methods for AnimationMask #1566

  • Add the screePointToRay method to the Camera class #1538

I could run it with my game demos and provide feedback like I did for iteration 3.4.0.


The contributions pages on wiki & github still not active yet.

I’m unsure what you mean by this. Which pages are you referring to, and what would it mean for them to be active? Please clarify.


I would like an easier way to access glscissors. The only option to be able to use scissors is through the camera clipping. or create your own previewport and render everything to that texture so things outside the texture gets dropped.

Opengl has a very easy option for glscissors and it is not related on anything. It would be great you could attach clip to the material or something.


I mean issues like these :

And I hope I see a design paradigm in UML or something for the engine within here :

I mean how core things work, which is not code, it’s a design pattern for the engine aspects, so contributors can find solutions for problems as easy as possible, and I am sorry for my language, it seems sometimes I mis-elaborate things.

The contribution tutorial is good, but I see it does not talk to me more about the engine, currently for me, it talks about workflow & github PRs(which is good but not specific), if we can redirect it more towards the engine itself(like engine lifecycle - how core classes composite to work together through diagrams), that would be great !


As a consumer of JME the most important part for me is a quality ecosystem.
MavLib is a good example.
Lemur is a good example.
A Cameras library with some enhanced cameras will be great to have.
The demo game which was discussed here would be great to start.
A collection of Gradle based starter projects
Open the store for uploading JME based non opensource / commercial projects
Maybe an enhanced character control

All of these are not features in the core engine but I think that they will convince new programmers to work with JME rather than Godot or LibGdx.
In general, I think we should always ask ourselves what problems can we solve for our users rather than what new cool features can we add to the engine.

Unfortunately I don’t have enough knowledge to help with the developing the engine. I think I can contribute in testing…


i will use alpha versions, yes, and will help report/diagnose issues. Currently no time for anything else.

about features, i would love to see:

  • new/updated filters along with some better render pipeline system.
  • some animation system -improvements.

Dropped support of LWJGL2. I’ll make a more exhaustive post later, but the main problem is: LWJGL2 input support is “good enough” for many but “not good enough” for me;
LWJGL3 instead is “good”, but requires some incompatible changes.

Oh, and also BC7 texture compression support would be nice…


Maybe good, but there are still so many issues with LWJGL 3 left unresolved… Also it would mean the death of the SDK as we know it. Dunno if TestCanvas crashes with LWJGL3 · Issue #1192 · jMonkeyEngine/jmonkeyengine · GitHub would resolve it.

Then there is the Mac thing… I’m not sure that even when implemented, does it destroy Mac support? Although at least this library (GitHub - LWJGLX/lwjgl3-awt: AWT support for LWJGL3) says it has a Mac support… so there is hope


By the way, maybe it will be nice to make a poll for bugs/feature requests/documentation requests, then select the top-voted ones, and make a bug bounty list using the donations from the opencollective. (a very shortlist for the start)

Or instead of a poll, engine leaders themselves can pick a list of bugs/features they think are important.

This is just a suggestion, I don’t know if this will be successful or not as there are other factors to consider, like manpower and time. Sorry if I went offtopic!


BC7 texture compression support would be nice…

What’s the advantage of BC7 over, say, JPEG XL?

BC7 hardware acceleration is part of DirectX 11 capabilities, so most modern GPU from the last decade can handle them and benefit over the obsolete DXT5…

1 Like

Are you suggesting JMonkeyEngine should support BC7 texture compression using the GPU? Or would a CPU-based implementation be fine?

Both coding and decoding?

It should work the same way the DXT5 works: you load the asset and then is managed by the GPU. So only decoding should be fine.
Not sure if a CPU implementation would work… it needs to leverage the DirectX11 hardware to be useful for games.

1 Like

What I have read, it would be too slow to be of any use really. BC7 GPU solution is doable to my understanding. OpenGL 4.x feature.

1 Like