Next release(s) of the Engine


I’ve created an issue:


I’ve been thinking about creating a 3.2.3 release of the JME libraries:

  • in the March-April timeframe,
  • assuming 3.3.0 isn’t released before then.

Motivation might come from the following issues recently fixed in the master branch:

Especially issue 1003, since it seems likely to have a major impact if the glTF asset pipeline ever becomes popular.

A JME 3.2.3 release might also incorporate newer versions of LWJGL3, Bullet Physics, and NiftyGUI.


No champion for JME 3.3 has emerged, so I’ve started tagging issues and pull requests that I think should be included in JME 3.2.3:✓&q=milestone%3A"v3.2.3"

I propose inclusion criteria similar to 3.2.2:

Assuming I’m driving this release, the process will be similar to that for 3.2.2, only without a beta release.

I’ve set a cutoff of 17 March for all changes destined for this release to be integrated into the master branch. Pull requests should allow extra time for discussion and integration.

Expect more details as the cutoff date approaches.


Will this commit make it in? @TheLeo has made an amazing library (SevenSky) that is unfortunately difficult to use at the moment due to this commit not being in any current releases.


That looks like a new feature to me, so I think it must wait for JME 3.3


I don’t know… missing 32-bit single channel floating point textures sounds like a bug to me. :wink:


I’m open to persuasion. Does anyone else have an opinion on this matter?


what’s the difference between this and luminance 32f ?


Not trying to be hard-sell, although I would like to see this in a release sooner rather than later (lots more use for something like this than just SevenSky).

Couldn’t tell you off the top of my head, although I am under the very possibly mistaken impression that luminance values might be treated specially by drivers. In any case, even if they are functionally identical there’s value in having a more obvious/familiar representation of intent (luminance means something very specific, but color channels are often repurposed for other values). In any case this exposes 16 and 32 bit single or double channel floating point textures, which strike me as quite useful in general (in fact, adding RGB/RGBA 16/32 bit textures would probably be a good idea at some point if there’s well-defined support for these - don’t recall what the GL spec says about those off the top of my head).


Well don’t get me wrong, for what it is worth i would agree to add every supported format, but i want to point out that if you use core profile (and you should) Luminance32f is actually GL_R32F since luminance textures are deprecated.

RGB(A) 16 32 are already supported.


My mistake (probably should stop relying on memory about this stuff!)

Good to know, although this is a subtle enough point that I think it definitely merits its own constant.


Per Khronos, They have been removed in OpenGL 3.1, and some driver providers (OSx and the mesa team) are moving toward non-support for older versions of the spec, if they have not already removed it.


The commit was merged to master 9 months ago. I didn’t realize it made the library hard to use atm. On other hand, I am definitely for including the commit. Its very small and low-risk. It consists of just 8 lines of code and rest is Javadoc I think. And yes, as Riccardo said, Luminance is deprecated.

Ps: thank you danielp, for the compliment :slight_smile:


Since this commit hasn’t made it to a release, SevenSky can’t be used without building the engine from master. For those of us who prefer to develop against a released version this isn’t the best state of affairs. Not a showstopper - in my case I probably should have a local build anyway, so that’s what I ended up doing. On the other hand I could definitely see this being a deal breaker to some other folks.

Since this is a low/zero risk commit it would be great to have released.

Thanks for making SevenSky! Really looking forward to trying it out. I read your thesis and downloaded a copy to my must-read collection of papers.


Not hearing any objections, I’ve tagged PR #839 for inclusion in v3.2.3.


Awesome! Thanks @sgold! (And thanks for all your hard work getting this next release out!)


The v3.2.3 release is shaping up nicely.

I plan to publish a preliminary cherry-pick list to Google Docs this weekend. Interested parties will then have 2 weeks in which to comment. It’ll be a living document, since new commits to master branch will be considered right up until the 17 March cutoff.


Here’s the cherry-pick list:

You can’t edit this document directly. However, I welcome constructive feedback, particularly regarding the following commits whose inclusion status is currently “to be determined” (TBD):


Sunday (17 March) is still the cutoff, and I’m still looking for help deciding which commits should go into the 3.2.3 release.

As soon as 3.2.3 is done, I’d like to discuss a possible 3.3 release.


@pspeed: I’ll pay for your cola. Just let me know how much.