Porting tips - jME 3.0 to jME 3.1

In the absence of useful release notes for 3.1, perhaps it’s time for us to pool our experience. What changes have you found necessary when porting projects from jME3.0 to jME 3.1?

Here’s my list so far:

  1. Libraries: the libraries you need depend on your platform and the features you use. For my projects, I find I need ten libraries in 3.1 (jme3-core, -bullet, -bullet-native, -blender, -desktop, -effects, -jogg, -lwjgl, -plugins, and -terrain) where in 3.0 I used three (jme3, jme3-libraries, and -libraries-blender). Omission of some libraries results in a crash, in other cases, you may just get a warning.

  2. Interpolation methods: in 3.0 the Vector2f, Vector3f, Vector4f, and ColorRGBA classes defined “interpolate()” methods. These were renamed to “interpolateLocal()” in 3.1.

  3. Importing models from Blender3D: if the model contains polygons with >3 sides, the import usually generates warnings from “Face.triangulate()”. These can be avoided by triangulating in Blender3D prior to import.

  4. Bone animations default to hardware skinning in 3.1, whereas in 3.0 they defaulted to CPU skinning. If this doesn’t work for your app, override this using SkeletonControl.setHardwareSkinningPreferred(false)

  5. Filter post-processors default to R11G11B10 texture format in 3.1, whereas in 3.0 they defaulted to RGBA8. If your filters need an alpha channel, override this using FilterPostProcessor.setFrameBufferFormat()

  6. NiftyGUI upreved from 1.3.3 to 1.4.2, which required:
    (a) in XML definitions changing

<nifty xmlns="http://nifty-gui.sourceforge.net/nifty-1.3.xsd"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://nifty-gui.sourceforge.net/nifty-1.3.xsd">
   to
<nifty xmlns="http://nifty-gui.lessvoid.com/nifty-gui">

(b) taking greater care not to refer to non-existent elements or redefine styles or apply styles
to elements not yet bound to any screen – 1.4.2 is a lot fussier than 1.3.3
© specify text or width for all labels – default width changed (to 0?) for labels with no text specified

I’m also seeing different physics behaviors, which I am still trying to pin down.

Does anyone else have 3.0 → 3.1 porting tips to share?

9 Likes

I’m still on 3.0 so this is so useful for me, thank you!

Since I haven’t done it I can’t say for sure, but SimpleApplication is dead and for now we have LegacyApplication, but the way forward is to extend application. See here: jMonkeyEngine 3.1 alpha 4 released

I also had to re-create some of my .j3md files when I briefly tested a 3.1 alpha many months ago since some stuff has been removed but netbeans or java or w/e got all bitchy about it.

SimpleApplication still works in 3.1, at least for me. From reading pspeed’s old post, I gather it’s Application that’s being phased out.

No, you misunderstood. SimpleApplication is still there and if you were using it, you’re fine.
Application is now an interface and LegacyApplication is what was Application before. So basically you only have to care if you were extending directly Application before, which was not and is still not the recommended way, and all you have to do is to extend LegacyApplication instead of Application.
But all in all very few people should be impacted by this.

2 Likes

Ah ok cool.

Our project issues, mainly related to Nifty:

1 Like

I recently remembered another porting issue: in jME 3.0 wireframes, point size and line width were properties of the Mesh. In jME 3.1 wireframes, they’re determined by the Material.

1 Like

Which, by the way, anyone who ever tried to show wireframe overlayed on top of your regular models will love this change. :slight_smile:

1 Like

Some contribution-libs do not work in 3.1 becaurse the Application is now an Interface.
Such as Cube, AI, Tonegodgui, SkyControl, etc.
Dont use jars, use the source.

1 Like

I just discovered that in jME 3.1 AbstractControl implements an additional interface JmeClonable. This interface seems to be used (very indirectly) by DesktopAssetManager.loadAsset() to clone custom controls that implement it. Which may explain why I’m having difficulty de-serializing custom controls (such as SkyControl) based on AbstractControl.

…which entirely depends on the unknown trouble you are having.

In general, this should not affect anyone unless they had a lot of custom cloning stuff. But I guess it’s good to point that out.

Now you can do a bunch of stuff easily that was either impossible or extremely code-verbose before.

1 Like

I realize all these changes were all made for very good reasons. I’m not complaining about them, just trying to alert other users in the transition.

As a rule of thumb, I’d say that any control based on AbstractControl which overrode cloneForSpatial() in 3.0 should override cloneFields() in 3.1. Would you agree?

Yes,… though they probably don’t have to override cloneForSpatial() at all. It’s such an extremely rare thing to need.

1 Like

How about change SkyControl to SkyAppState, like what ChaseCamAppState did?

A bit off-topic, but okay. If I were starting from scratch, I’d probably design SkyControl as an app state. Only … I’m not starting from scratch, so it isn’t happening.

PS: SkyControl contains a reference to a Spatial other than the one it controls. Therefore it needed to override cloneForSpatial() in 3.0. It (indirectly) extends AbstractControl, so it must override cloneFields() in 3.1. My failure to do so in version 0.9.1_for31 broke de-serialization of SkyControl. I will correct my oversight in version 0.9.2.

Another pitfall to watch for: unspecified GLSL version in shader.

Yes, and note that the 3.0 behavior pretty much guaranteed that your shaders would only work properly on your own machine the first time… until you got bug reports from users. With the new way, you find locally the problems they’d have found after you released something.

3 Likes