Next release(s) of the Engine

How I love that :frowning:

Neither can I imagine any reason for such an Exception nor does it make any sense: new File() cannot return null, File#listFiles() should not return null but an empty array and pure iterating over an array shouldn’t cause any trouble at all.

Can you try backupping and then deleting your contents in C:\Users\James\AppData\Local.jmonkeyplatform (-installer)?

That’s the only thing I could imagine, apart from that maybe sdk/reporting_issues.md at master · jMonkeyEngine/sdk · GitHub and hoping for the best

1 Like

Unforunately, File.listFiles() can return null in some cases. From the javadoc:
“Returns null if this abstract pathname does not denote a directory, or if an I/O error occurs.”

I’ve seen this in my day job from time to time and it’s a pain. For us it was always file permission issues.

2 Likes

I’ve created an issue: v3.2.2-stable-sdk1 installation fails with NullPointerException in ConfigurationLogic · Issue #186 · jMonkeyEngine/sdk · GitHub

1 Like

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.

10 Likes

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:
Issues · jMonkeyEngine/jmonkeyengine · GitHub

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.

7 Likes

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.

2 Likes

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:

1 Like

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

1 Like

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

1 Like

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.

1 Like

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

4 Likes

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

1 Like

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.

7 Likes

Here’s the cherry-pick list:
v3.2.3 cherry-pick list - Google Docs

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):

4 Likes