The SDK Relase v3.2.0-stable is out

Development
1

Hey fellow monkeys,
As some of you might know, we’ve had a few problems with Travis in the last few months.
These issues all revolved around exhausting the build time and disk space. Why? Because we always bundle an appropriate JDK and Blender version with each installer.
If you don’t need these, you can just download the platform independent/portable zip.

Please Note

If you downloaded v3.2-beta1-sdk or v3.2.0-stable-sdk before yesterday evening (13th January 2018), then please re-download the installer as we cannot guarantee that it works flawlessly (since travis quit in the middle of the build, producing half-finished products).

Release Notes

There is not much to say at this point about the patch notes, because there were only small fixes and additions (adjustable view panes, printing the camera location), the major feature is the new engine version.

See the release here: Release jMonkeyEngine SDK 3.2.0 Stable · jMonkeyEngine/sdk · GitHub
Feel free to collect some patch notes if you want to and I’ll include them.

Nomenclature of the SDK (Versioning Scheme)

Since some people mix up the engine version and the sdk version I’m explaining it shortly: v3.2.0-stable-sdk1 means v.3.2.0-stable as engine version and sdk1 as SDK Version, this means it’s the first SDK Release based upon v3.2.0-stable. So the next SDK Release would be v3.2.0-stable-sdk2.

Docker Images

In the next few days I will open another thread about a Docker Image I’ve created to build the SDK locally. I’ve required that to “fake” travis, in order to debug a few issues and to see which files take up what disk space during which build phase. This helped me reducing the Diskspace from 21G to 7.3G :wink:
So what I’m going to do is push it to a public repository and open up a dockerhub account, so you can too easily build each SDK Release installer.
This is helpful if you’d want your game editor to be based off the SDK or ship your engine fork with easy installers for all your team members OR: If the releases from github wont work for you, you could build them on your own.

Do note that this is not the best way to debug the SDK though, since docker won’t let you start a X11 Display Application that easy. Also the scripts are not made to build from a specific commit, instead they take specific engine tags like v3.2.0-stable.

The Most Important: Looking for Contributors.

Just like the Engine, we need contributions. These contributions can be as small as just reporting bugs (like @grizeldi always does), up to a dedicated maintainer/contact person for components like the SceneComposer, the Android Support etc.
Why the SDK and not the Engine? While I agree that Engine fixes are more important, the fixes on the SDK are easier in terms of non-programmer-skills. You don’t need profund knowledge about (Vector-) Maths, 3D Engines in general or anything.
There are easy things as fixing javadoc (missing parameter annotations) up to the SceneComposer (which does only require Java Knowledge and time to get an overview over the many interacting classes).

Just give it a try, just look at the code and see if you can find anything which interests you.

19 Likes
2

I can’t set the filter parameters any more in my filters.
filters

3

What Version did you use before and what filters are affected? All?

4

3.1 stable and all are affected.

5

Great work, @Darkchaos !! I know the release process wasn’t easy.

From my testing so far, I’d say SDK 3.2 is much better than SDK 3.1 . . . and not only because it includes version 3.2 of the Engine :wink:

1 Like
6

Great work! Any plans on updating to Netbeans 9? It seems to be in BETA still (well, BETA was just released few days ago).

1 Like
7

4 days ago Netbeans 9.0 started entering Beta it seems but don’t expect the SDK to immediately switch either, because I expect bigger changes with 9.0 as it also seems the project is now held by Apache instead of Oracle. This also means we have to check if they’re not going to release it under their APL.

2 Likes
8

Thanks for your report again.
The problem has been resolved: Allow Filters to be edited again (bugfix) and prepare to fix #133. On… · jMonkeyEngine/sdk@33b141d · GitHub

The Fix will be included in v3.2.0-stable-sdk2 which might be released this week, depending on how many other issues get found :slight_smile:

Btw: your issue led to shadows being usable in the SDK soon :wink:

6 Likes
9

Booom, Commit Bomb has dropped.
What will be new in -sdk2:

  • Filters will work again as expected (All Properties are exposed, even for custom subclass filters)
  • Update Screen shows 3.2
  • Light Probes aren’t Node only anymore but can be calculated for individual Geometries. They also don’t lead to a ConcurrentModificationException anymore.
  • More Light Properties available (I’ve only hidden the internal frustum variables). You can now name your lights etc.
  • Shadows!! It results from the filters working (and this time exposing parameters which are no fields but only getters/setters) and the ability to select a light by name

The screenshot below also shows the -sdk1 features like adjustable Clipping Panes and Camera Position/Rotation.
Note: With great power comes responsibility: Now that you can change even internal state-variables, be prepared to crash the SDK when abusing filters. These are NO BUGS then, however we might start to blacklist variables.

13 Likes
10

you are the bestest! :slight_smile:

4 Likes
11

@Darkchaos when will sdk2 be built and added to the releases?

2 Likes
12

Thanks for pinging me. I wanted to write that I’ll wait for 3.2.1 to release, but guess what… :chimpanzee_eek: That already happened :smiley:

I wanted to bring in another cool feature for the SDK but I doesn’t look like I’ll finish it before the exam phase starts, which means I’ll integrate the GLSL Plugin and then release v3.2.1-sdk1 as fast as possible.

7 Likes
13

Is it possible to get autoupdates working again?
I don’t update the SDK very often because I have to reinstall it every time, but would like to.

4 Likes