Next release(s) of the Engine

I know it shouldn’t count but monkanim would also require efforts on the SDK side of things to be supported (because I feel that people who are unable to use something like jitpack or building the engine will almost ONLY be the people who use the SDK).
The Problem starts with Properties and continue with a visual representation of the Tweens I guess.
But we should really evaluate the state of Monkanim v2, everything else is wildly guessing/thinking for now. If Monkanim isn’t ready, we can’t push v3.3. And in theory all the importers would need an upgrade to Monkanim as well

2 Likes

Oops, Yes agree with you, I haven’t thought from that point. :roll_eyes:
I think I have rushed a bit :slightly_smiling_face:

1 Like

It’s possible that we push new engine versions and the SDK falls behind. The whole point of splitting the two was so that the engine development wasn’t dragged down by SDK lag… we drag it down by enough other things already.

And if there were some critical ‘possibly breaking’ changes that we really wanted to get out then we could make a 3.3 without monkanim.

Personally, for gradle-based projects, building and including the latest master for my projects is so easy that I don’t strongly care about ‘real’ releases for my own stuff. I do recognize the need.

2 Likes

Personally I only use the SDK for model imports, and only because I can’t be bothered to make an intellij plugin. Gradle support is minimal at best and the tools that are there are prone to a lot of issues. I fully support an SDK, but I just can’t see any future for the current state of it.

Changing to intellij isnt an option because tomorrow it will be some other IDE. I don’t know what happened to SPIX, but it would be nice to have an uncoupled state/bridge like that. Is there any news or information regarding SPIX? Is it unfeasible/dropped/forgotten/lacked dev time?

1 Like

Just lack of time. It’s missing one core feature that is caught in a design loop… but nehon took it pretty far even despite that. It would be a while before it would be an SDK replacement, though.

I’m not trying to be down on the SDK. Just saying that we decoupled things for exactly this exact very exact reason. It was the number one reason with a bullet… and there aren’t too many number 1+ reasons that I can even think of right now. At the time it was “Hey, we have some new engine features and it would be nice to cut a release” …3 years later SDK catches up.

Edit: and as far as this goes:

I always thought it would be nice to have a command line tool to do this… something easily integrated with gradle, for example.

1 Like

Yesterday I created a list of master commits since January and began deciding which ones should be cherry-picked into v3.2. The list is proving a lot longer (and more work) than I anticipated. It’s not ready for review yet.

Most of the master commits since January fall into neat categories:

  1. Clearly related to a GitHub issue that’s impacting JME 3.2.1 . These will be picked if-and-only-if the issue bears the v3.2.2 milestone.
  2. Already integrated into v3.2 branch. (Nothing to see here; move along.)
  3. Clearly related to new features. These will be skipped.
  4. Comment-only commits. Not a priority for users accustomed to reading JME’s source code. However they’re very low-risk, so I hope to include most of them.
  5. Automatic native-library updates by AppVeyor and Travis. No need to cherry-pick these unless continuous integration (CI) is broken.
  6. Fixes to CI and the build process.

Re #6: I believe both AppVeyor and Travis take their orders from the YML scripts in the master branch; if so, YML changes won’t need to be cherry-picked.

I plan to push a commit or 2 to v3.2 branch as a test, to find out how well CI is currently working. I’ve already edited the YML to enable (I hope) CI on v3.2.

Bottom line: don’t be alarmed if you see commits to v3.2. Cherry-picking hasn’t started yet.

1 Like

Troubleshooting CI issues.

Progress. Looks like we need PR 888 in v3.2.

That reminded me that I needed to finish reviewing pull requests. Most of these (but not all) are associated with GitHub issues that I already looked at.

I’ve begun marking PRs I think are OK for 3.2.2. Here’s a link to the latest list:

Pull requests · jMonkeyEngine/jmonkeyengine · GitHub

It might be nice to get LWJGL v3.2.1 (PR 974) in JME 3.2.2 . In order to do so, however, the PR must first be integrated into master (ground rule 5). I don’t feel comfortable doing that myself.

Would someone (other than Ali-RS) who’s familiar with LWJGL please review PR 974 ASAP?

FYI: in your list you have: add a test for JME issue #877 by stephengold · Pull Request #882 · jMonkeyEngine/jmonkeyengine · GitHub
…which is only a test case. No harm done to include it but maybe save you some time cherry-picking something that technically doesn’t matter.

1 Like

Good point. I think I added the v3.2.2 milestone so it’d be easy to test JME 3.2.2 for issue 877, which was fixed by pull request 962.

I hope the cherry-picking step proves easier than deciding which commits to cherry-pick!

1 Like

I think I’ve reviewed all the PRs that might be relevant. Now there are 39 with the v3.2.2 milestone. Most ofAbout half of them relate to GitHub issues with the v3.2.2 milestone. The exceptions are:

968 Added a (hacky) fix for a Java Swing/AWT + GLFW interaction issue… 
951 Android native physics 
930 Particle tile number/UV calculation change 
926 Load animated cursor NPE 
907 jme3-bullet: add and improve comments, mostly JavaDoc 
905 jme3-bullet: add and improve comments, mostly JavaDoc 
904 Remove JVM arguments for OSX when running examples 
890 rm auto-generated C++ headers from repo and rm them during "build clean" 
888 use Gradle v4.10, android tools v3.1.4, bintray plugin v1.8.4 
885 avoid JDK10 so Travis CI can succeed on OSX 
875 Fix AudioNode issues when using velocityFromTranslation and small refactoring 
862 Update GLImageFormats to fix framebuffer exceptions in android 
855 replace addState() with attach() in the javadoc 
853 Fix a typo which makes pbr shader fail to compile when glossiness is enabled 
850 Updated deprecation documentation
830 simplify track cloning
827 make TerrainTestCollision more user-friendly 
824 Refactoring upgrading lwjgl3 v.3
819 Fixed settings of shadow render2 
812 resolve deprecation warnings in jme3-niftygui 
811 Added link to the wiki readme. 

If you have time, please consider whether any of these PRs are too risky for JME 3.2.2 and also whether I’ve missed any.

Can we squeeze in making then next release in Python?

I don’t know Python very well but it will help to translate over blender plugins.

cool beans, thanks :+1:

https://i.imgur.com/1ToeSBW.png

P.S.: Who here can tell I’m dragging my feet putting off guitar practice???

Maybe you should put together 3.2.2 SDK using the jdk 8.192.

Many bug fixes in 192 and the SDK runs better now.

Fixes that “component must be showing on the screen to determine its location” exception.

Edit:
You could also bring blender to to 2.79b, 2.8 beta is now out so this would be a good release imo. You will be at last point before jme 3.3, blender 2.8 and the first netbeans stable release by apache.

It might be necessary to check this on windows, *nix, mac and android. They each have their own quirks and issues.

1 Like

Here’s a link to the cherry-pick list:

v3.2.2 cherry-pick list - Google Docs

I’m double-checking it now.

The commit list is so long that I don’t plan to post it here. Instead, I will enumerate some particularly interesting commits: those to be cherry-picked that (a) don’t consist entirely of comments and (b) aren’t connected with a GitHub issue or PR. I think these deserve special scrutiny.

Modified the J3M loader to be a little less like a 1980s text adventure. · jMonkeyEngine/jmonkeyengine@d5bfe1e · GitHub
Modified the J3M loader to be a little less like a 1980s text adventure.

Uses a HashSet for variable names in ShaderNodeLoaderDelegate instead… · jMonkeyEngine/jmonkeyengine@302e746 · GitHub
Uses a HashSet for variable names in ShaderNodeLoaderDelegate instead of a String

Fixes an issue where light probes were used in phong lighting · jMonkeyEngine/jmonkeyengine@db48b98 · GitHub
Fixes an issue where light probes were used in phong lighting

Fixed an NPE in getNumElements() if the data field was null. · jMonkeyEngine/jmonkeyengine@0fb5eed · GitHub
Fixed an NPE in getNumElements() if the data field was null.

Fix typo in logger · jMonkeyEngine/jmonkeyengine@319656a · GitHub
Fix typo in logger.
Change “WeakRefAssetCache” to “WeakRefCloneAssetCache”

We’re now at step 5 in the plan of action:

1 Like

Note: these would be easier to check out with clickable links. I know it’s a pain, though. (Just that I’d have already looked if they were clickable but it will have to wait until late tonight for me to look as is.)

…just wanted you to know you aren’t being ignored.

2 Likes

Thanks for the suggestion. I’ve converted the hashes to URLs.

1 Like