jMonkeyEngine 3.1.0 Beta 3+4 Released (engine)

pspeed · January 29, 2017, 2:56pm

Finally a beta 3. This is an incremental bug fix over beta 2. If there are no obvious issues with this release then it will probably be the official final version of 3.1.0 and we can start doing any future bug fixes on 3.1.1.

The jars are up on jcenter and the release is up on github: Release jMonkeyEngine 3.1.0 Beta 3 · jMonkeyEngine/jmonkeyengine · GitHub

Highlights

SpiderMonkey’s Serializer gets an initialize() method
Cloning bug fixes, especially BitmapText-related and animation-related
MikktSpaceTangentGenerator crash fix
Various other fixes

Here is the full change log between beta2 and beta3:

commit + 69cd160956c67709e8a67f483d63949fe88628bb
Author: Nehon
Date:   Thu Jan 26 21:09:02 2017 +0100

    Fixed an issue where ParticleEmitter had NaN bounds during the first update when added to the scene graph during the update loop

M	jme3-core/src/main/java/com/jme3/effect/ParticleEmitter.java

commit + 789daa62958573738fa6561e57c5956068d1710c
Author: Nehon
Date:   Tue Jan 24 20:17:19 2017 +0100

    Fixed warning that were coming out of the particle.j3md. Also fixed the preshadow technique

M	jme3-core/src/main/resources/Common/MatDefs/Misc/Particle.j3md

commit + f3e2925bd8f57d7c33a23a59499a833f31827bbf
Author: Stephen Gold
Date:   Fri Jan 20 13:08:28 2017 -0800

    fix errors in how vector projection is calculated

M	jme3-core/src/main/java/com/jme3/math/Vector3f.java
M	jme3-core/src/main/java/com/jme3/math/Vector4f.java

commit + ac8eb4d40a61c819f316a152da991aeb5837f466
Author: Stephen Gold
Date:   Tue Jan 17 11:42:21 2017 -0800

    CapsuleCollisionShape: warn about scaling only if it's not identity
    same diff riccardobl committed to 'master' on Jun 20, 2016

M	jme3-bullet/src/main/java/com/jme3/bullet/collision/shapes/CylinderCollisionShape.java
M	jme3-jbullet/src/main/java/com/jme3/bullet/collision/shapes/CylinderCollisionShape.java

commit + aae6170cc5a3cc991330bd0c93716cdb229920e6
Author: Nehon
Date:   Fri Dec 30 10:08:21 2016 +0100

    Fixed MikktSpaceTangentGenerator that was not replacing existing Tangent buffers on the mesh. That could cause crashes when the old tangent buffer did not have the same amount of components

M	jme3-core/src/main/java/com/jme3/util/mikktspace/MikkTSpaceImpl.java
M	jme3-core/src/main/java/com/jme3/util/mikktspace/MikktspaceTangentGenerator.java

commit + 7ecb81c2303b73ef7c4bf388e5dd1b5d0e598d64
Author: iwgeric
Date:   Mon May 2 23:14:26 2016 -0400

    Update AndroidLocator to allow assets to be stored in Android assets, drawable, or mipmap directories.
    Texture assets can now be stored in Android Drawable and Mipmap directories.  Allows Android to automatically select the closest matching image asset for the actual device configuration (ie. lower resolution textures for lower-end devices).  Search order is:  assets -> drawable -> mipmap.  First match found is returned.

    (cherry picked from commit c219ce1)

M	jme3-android/src/main/java/com/jme3/asset/plugins/AndroidLocator.java

commit + 63e8c9c485508f246f4c6c868511f79953158425
Author: Paul Speed
Date:   Tue Dec 13 06:03:43 2016 -0500

    Convert Skeleton and Bone over to use the JME cloner system for cloning...
    this should do automatic fix-up and hopefully make bones attachments work
    properly again in clones.

M	jme3-core/src/main/java/com/jme3/animation/Bone.java
M	jme3-core/src/main/java/com/jme3/animation/Skeleton.java

commit + 92b5d40003e3c99059f8b2025ed028af19548a1e
Author: Paul Speed
Date:   Sun Dec 4 20:35:49 2016 -0500

    Modified BitmapTextPage to always deep clone its mesh since otherwise
    BitmapText objects end up sharing them and that's bad.

M	jme3-core/src/main/java/com/jme3/font/BitmapTextPage.java

commit + 4952ad0cb55f12bbe0fc0731d11859196ff8377b
Author: Paul Speed
Date:   Sun Dec 4 16:28:12 2016 -0500

    Broke out the Serializer's static initializer into a separate initialize()
    static method.  This allows servers to completely reset the Serializer's
    registry when restarting the server in the same JVM instance.

M	jme3-networking/src/main/java/com/jme3/network/serializing/Serializer.java

commit + a13a3a7f093ec596cf1086001980a06440a9db10
Author: Paul Speed
Date:   Sun Dec 4 15:49:51 2016 -0500

    Another bitmap text clone fix.  The text pages array (the list of the actual geometry of
    the bitmap text) wasn't really being cloned... only the elements were.  This meant that
    that a cloned BitmapText object would continue to share the meshes from the original.

M	jme3-core/src/main/java/com/jme3/font/BitmapText.java

commit + 735397f16e30476fa8ba5f643030643bfb6d80ea
Author: Paul Speed
Date:   Sun Dec 4 15:31:30 2016 -0500

    Another fix for BitmapText cloning where the regular clone() was
    completely bypassing the JME cloner framework... and making a bad
    clone.

M	jme3-core/src/main/java/com/jme3/font/BitmapText.java

commit + c1764bc42524cccec305dcf8dd5d1e8bfc8c6880
Author: Paul Speed
Date:   Sun Dec 4 14:24:34 2016 -0500

    Fixed the cloned Letters to use the cloned StringBlock instead of the
    original reference.

M	jme3-core/src/main/java/com/jme3/font/BitmapText.java

commit + da1b7da329dd5864a4c67a6b12350cace78edf2c
Author: Paul Speed
Date:   Sun Dec 4 04:26:41 2016 -0500

    Added a test for cloning BitmapText.

M	jme3-examples/src/main/java/jme3test/app/TestCloneSpatial.java

commit + e879a0e14295da6d19f9bd95f3053becd4017340
Author: Paul Speed
Date:   Sun Dec 4 04:20:55 2016 -0500

    Fix for issue #577  StringBlock cannot be cloned with the cloner because
    it is package private and the cloner cannot instantiate one directly.
    Since it is extremely unlikely (read: impossible) that there would ever
    be shared StringBlock references between BitmapText objects then it is safe
    to just clone it directly.
    It is important to note that BitmapText never really did support clone
    before and only pretended to... so this wasn't really a regression.

M	jme3-core/src/main/java/com/jme3/font/BitmapText.java

commit + e3bd12251985e24a5530ee2829e16c2411c71a0a
Author: Fadorico
Date:   Thu Nov 24 15:54:36 2016 -0500

    Write/read the width and height of the quad

M	jme3-core/src/main/java/com/jme3/scene/shape/Quad.java

commit + 72b9f186edbc2a24e8ccd6301c18e7383969508d
Author: Kirill Vainer
Date:   Thu Nov 24 13:31:59 2016 -0500

    fix broken bullet native source url

M	gradle.properties

commit + 8c4b44941ecc582f24a0b5e6fd0a04bcb36f77bb
Author: Kirill Vainer
Date:   Wed Nov 23 21:05:20 2016 -0500

    Fix #550

M	jme3-core/src/main/java/com/jme3/scene/GeometryGroupNode.java

pspeed · January 29, 2017, 3:08pm

I figure I’ll give this release a week or so to “burn in” so to speak. If no one finds anything major than I’ll just tag it again as the final 3.1.0 release. Any bugs that don’t make this cut can go into 3.1.1.

Ev1lbl0w · January 29, 2017, 5:27pm

So, after this update, is it necessary to update any code that serializes the messages?

pspeed · January 29, 2017, 6:08pm

No. But if you want to run your server instance twice within the same process then you can now.

danielp · January 29, 2017, 7:52pm

Not sure if this is the right place for this or not… feel free to move this if you’d rather it was in a different thread.

When running jME 3.1.0-beta3 with LWJGL3 (gradle artifact: ‘org.jmonkeyengine:jme3-lwjgl3:3.1.0-beta3’), I get a crash when starting with all default settings, but only if the settings are NOT loaded from a file. When my application starts, it looks in the user’s home directory for its settings directory. If it does not find it, it creates the default jME settings like so:

private static AppSettings defaultSettings(){
     AppSettings settings = new AppSettings(true);
     try {
	settings.save(System.out);
     } catch (IOException e) {
	// TODO Auto-generated catch block
	e.printStackTrace();
     }
		
     settings.putString("uistyle", "glass");
		
     return settings;
}

… and then it displays the jME settings window:

if(!Files.exists(settingsFile)){
   settings = defaultSettings();
   app.setShowSettings(true);
   ... save settings and here and continue with startup
}

Here are the settings that are dumped to System.out when only default settings are used (only clicked ‘Continue’ on the jME settings window)

#jME3 AppSettings
#Sun Jan 29 11:42:29 PST 2017
Renderer(string)=LWJGL-OpenGL2
Width(int)=640
DisableJoysticks(bool)=true
SettingsDialogImage(string)=/com/jme3/app/Monkey.png
Height(int)=480
Title(string)=jMonkeyEngine 3.1-beta3
Samples(int)=0
Resizable(bool)=false
BitsPerPixel(int)=24
UseInput(bool)=true
GammaCorrection(bool)=false
Frequency(int)=60
DepthBits(int)=24
Fullscreen(bool)=false
AudioRenderer(string)=LWJGL
StencilBits(int)=0
VSync(bool)=false
FrameRate(int)=-1
MinHeight(int)=0
MinWidth(int)=0
SwapBuffers(bool)=true

Here are the settings that are loaded from the file:

#jME3 AppSettings
#Sun Jan 29 11:42:56 PST 2017
Renderer(string)=LWJGL-OpenGL2
Width(int)=640
DisableJoysticks(bool)=true
SettingsDialogImage(string)=/com/jme3/app/Monkey.png
Height(int)=480
Title(string)=jMonkeyEngine 3.1-beta3
Samples(int)=0
Resizable(bool)=false
BitsPerPixel(int)=24
UseInput(bool)=true
GammaCorrection(bool)=false
Frequency(int)=60
DepthBits(int)=24
Fullscreen(bool)=false
AudioRenderer(string)=LWJGL
StencilBits(int)=0
VSync(bool)=false
FrameRate(int)=-1
MinHeight(int)=0
MinWidth(int)=0
SwapBuffers(bool)=true
uistyle(string)=glass

Both sets of settings are identical with the exception of the uistyle line, which is only because the uistyle is added after the newly created default settings are dumped to System.out. In short: both sets of settings are identical. However, if my application starts with the settings that are created on the fly (not loaded from file), my application crashes with the following:

(java:9812): Gtk-WARNING **: Unable to locate theme engine in module_path: "oxygen-gtk",
Jan 29, 2017 11:42:35 AM com.jme3.system.JmeDesktopSystem initialize
INFO: Running on jMonkeyEngine 3.1-beta3
 * Branch: HEAD
 * Git Hash: 69cd160
 * Build Date: 2017-01-29
Jan 29, 2017 11:42:35 AM com.jme3.system.lwjgl.LwjglContext printContextInitInfo
INFO: LWJGL 3.0.0b SNAPSHOT context running on thread main
 * Graphics Adapter: GLFW 3.2.0 X11 GLX clock_gettime /dev/js XI Xf86vm shared
X Error of failed request:  RenderBadPicture (invalid Picture parameter)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  7 (RenderFreePicture)
  Picture id in failed request: 0x3e00021
  Serial number of failed request:  803
  Current serial number in output stream:  813

This only happens with LWJGL3 - if I run against LWJGL2 it all starts up fine whether the settings are freshly created or loaded from file.

EDIT: started a new thread for this at LWJGL3 startup crash

pspeed · January 29, 2017, 8:13pm

This probably deserves to be its own thread then. I don’t know anything about lwjgl3.

I will point out that you are manually duplicating in a file everything already provided by AppSettings and its built in usage of the preferences API. Is that on purpose for your game or just for debugging this issue?

danielp · January 29, 2017, 8:22pm

Sure thing. I’ll move this to a new thread. Just wanted to bring this up in case LWJGL3 stability was considered critical for this release.

Yes, the reason I do that is that later as the game develops there will be a significant number of custom settings that the user can set, including a great deal of control over the graphics settings. If someone sets something that borks up their game and causes it to crash before starting, I’d like the settings to be in a file where they be easily edited manually and/or be posted to forums for a developer to look over.

pspeed · January 29, 2017, 8:44pm

…don’t save the settings until the game comes up. That’s what I do. Even when the settings change in game, I don’t save the settings until the next update.

As I recall, AppSettings lets you set your own settings also but it’s very crude, in my opinion. I also do my own settings but I use the preferences API, too, and I piggy-back on the JME preferences key. I’ve used command line options to reset them, too, before.

danielp · January 29, 2017, 9:08pm

Next update as in the next tick of the update loop?

Vortex · January 29, 2017, 9:31pm

Congratulations with the new release.

It’s nice to see that jME 3.1 final is nearing a release.

pspeed · January 30, 2017, 12:32am

Yes.

danielp · January 30, 2017, 5:06pm

Wow, clever, very clever. I might steal that idea sometime.

pspeed · February 11, 2017, 5:14am

Just released beta4 with the fix for the crash related to saving/loading native collision shapes with scaling.

It’s up on bintray/jcenter, etc, too.

I’ll once again let this one “burn in” for a little while and maybe cut the final 3.1.0 release in 4-5 days.

Edit: actually since this was already ramping up to final, I may just do it on Sunday night if a few folks confirm this release is working ok. I’ll tag it again as 3.1.0-release or whatever.