jMonkeyEngine 3.1 alpha 4 released

pspeed · March 28, 2016, 7:28am

The release that will live in infamy… probably.

We have just pushed the jMonkeyEngine 3.1 alpha 4 tag and the new jars are available on jcenter.

Highlights:

Breaking change converting Application class to an interface
New cloning system
Some shadow enhancements
A few other bug fixes.

THERE ARE SOME BREAKING CHANGES IN THIS RELEASE!!!

Now that I have your attention. At the very least, you will need to clean build your applications and any dependencies that refer to the Application class.

And for those who just skim, let me make that clearer:

“But why is that, Paul?”

Well, I’m glad you asked.

Sometime back it was decided that we should really refactor the Application class. SimpleApplication especially is a mess of ‘magic’ protected fields that on the one hand makes it really easy to slam some simple one-class application together, but on the other hand does new users no favors because they have no idea with ‘cam’ and ‘assetManager’ come from.

Unfortunately, lots of code refers to Application and it’s tough to change… especially the app states. Oh… the app states.

So, we hatched a plan to convert the Application class to an interface. This would give us some freedom to iterate on a new set of application base classes. The old Application concrete class becomes “LegacyApplication” as a big red sign that it’s soon to be replaced in some future version.

This means that anyone extending Application directly (hopefully very few of you) will have to change to LegacyApplication.

It also means that all applications will need to clean build because Java treats interfaces and classes differently at runtime and will complain.

That’s why:

“But why are you just getting to it now instead of a year ago?”

That is a very good question.

Before we had regular versions pumping out, it was nearly impossible for dependent libraries (like Lemur, etc.) to manage a change like this. Trying to depend on 3.1 anything was hard enough. So we had to wait for a few stable alphas to go out as maven dependencies to make it easier for the libraries to nail down theirs.

(For example, Lemur just pushed a 1.7.1 which is the last alpha3 compatible release and 1.8.1 which is the first alpha4+ compatible release… this would have been impossible before.)

“But why not wait until 3.2?”

For similar reasons, this kind of change would likely prevent anyone from ever trying out 3.2 while in development. The change is a relatively minor one now. Apps need only recompile. The dependent libraries will also need to recompile. But then everyone is on stable footing and new base application classes can evolve in 3.2 nicely. People looking forward to that can dip their toes in without any additional pain.

Also, we had a few breaking changes like this planned for 3.1 and alphas are the time to get those out. This is the last one planned (well, except the one I’m about to talk about that’s also in this release that ‘might’ be a breaking change.)

For 99.999% of you, a clean build is all you will need when you upgrade.

The New Cloning System

On the path to getting rid of the ugly that is cloneForSpatial(), we have implemented a new cloning system. All of the Spatial (and subclasses) and controls have been modified to use this new cloning system. It is similar to how objects are serialized by Java in that once an object is cloned it will not be cloned again. Therefore, shared references are automatically fixed-up and it even handles circular references. This makes the logic in cloneForSpatial() obsolete.

If you implement custom controls then you might care about this. 90% of controls probably already just extended AbstractControl and got cloning for free (or could have). If your control keeps references to other things or simply has fields it wants to clone, it can now override the new cloneFields() method and call the Cloner to clone its fields. Most use cases will then be handled automatically. I can follow-up separately for anyone curious.

So, this might be a breaking change for you if you rely on cloneForSpatial() for specific behavior in your clone subclasses. The good news is that you probably don’t have to do that anymore. The bad news is that until you fix it then cloning your control will be broken. Probably most of you don’t clone your custom controls anyway.

Note: I changed a LOT of classes and it’s quite likely I broke something even in the regular cases. I’ve tested animation and some other troublesome bits already but we may find issues and fixes will be rapidly forthcoming.

What’s next?!?

These should be the last of the breaking changes as they were the last two major to-do items on the list. From here, we are on the road to beta. Barring major complications, I’d like to have one more alpha before we branch and make beta. (I haven’t really discussed this with the team directly but this was sort of the sentiment in recent conversations.)

If there are bugs related to cloning, we may do an alpha5 sooner than two weeks. Else, I will push alpha 5 in another two weeks and we can create the 3.1 branch to prepare for betas.

Once the 3.1 branch is created master will become 3.2. At least that’s MY plan.

Anyway, here is the full changelog for alpha4 for those who care:

commit + 3c56afeae6b568d6047e59eed82fc8b3c203d4b1
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Mon Mar 28 01:47:33 2016 -0400

    Converted Application to an interface and renamed the old Application to
    LegacyApplication.  This is a breaking change for any class extending Application
    directly.
    And regardless, if you refer to Application then you will need to clean build
    your app... and any of your dependencies that also refer to Application.  Basically,
    anything using an AppState will need to be clean built against the next alpha.

M    jme3-android/src/main/java/com/jme3/app/AndroidHarness.java
M    jme3-android/src/main/java/com/jme3/app/AndroidHarnessFragment.java
M    jme3-core/src/main/java/com/jme3/app/Application.java
A    jme3-core/src/main/java/com/jme3/app/LegacyApplication.java
M    jme3-core/src/main/java/com/jme3/app/SimpleApplication.java
M    jme3-core/src/main/java/com/jme3/app/StatsAppState.java
M    jme3-desktop/src/main/java/com/jme3/app/AppletHarness.java
M    jme3-examples/src/main/java/jme3test/app/TestApplication.java
M    jme3-examples/src/main/java/jme3test/app/TestBareBonesApp.java
M    jme3-examples/src/main/java/jme3test/app/TestContextRestart.java
M    jme3-examples/src/main/java/jme3test/app/state/TestAppStates.java
M    jme3-examples/src/main/java/jme3test/awt/AppHarness.java
M    jme3-examples/src/main/java/jme3test/awt/TestApplet.java
M    jme3-examples/src/main/java/jme3test/awt/TestCanvas.java

commit + ab6fb03171589820c9b899ee77a93b0aca6da190
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sun Mar 27 06:14:52 2016 -0400

    Converted spatial over to use Cloner to do its various
    deep and semi-shallow cloning.  I'd be very surprised if nothing
    is broken as there is only so much testing I can easily do.
    Also various fixes for places I forgot to call super.cloneFields().

M    jme3-core/src/main/java/com/jme3/animation/EffectTrack.java
M    jme3-core/src/main/java/com/jme3/audio/AudioNode.java
M    jme3-core/src/main/java/com/jme3/effect/ParticleEmitter.java
M    jme3-core/src/main/java/com/jme3/effect/influencers/RadialParticleInfluencer.java
M    jme3-core/src/main/java/com/jme3/font/BitmapText.java
M    jme3-core/src/main/java/com/jme3/scene/AssetLinkNode.java
M    jme3-core/src/main/java/com/jme3/scene/BatchNode.java
M    jme3-core/src/main/java/com/jme3/scene/CameraNode.java
M    jme3-core/src/main/java/com/jme3/scene/Geometry.java
M    jme3-core/src/main/java/com/jme3/scene/LightNode.java
M    jme3-core/src/main/java/com/jme3/scene/Mesh.java
M    jme3-core/src/main/java/com/jme3/scene/Node.java
M    jme3-core/src/main/java/com/jme3/scene/Spatial.java
M    jme3-core/src/main/java/com/jme3/scene/instancing/InstancedGeometry.java
M    jme3-core/src/main/java/com/jme3/scene/instancing/InstancedNode.java
M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/NormalRecalcControl.java
M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/TerrainLodControl.java
M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/TerrainPatch.java
M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/TerrainQuad.java

commit + 0a876b04d21af0c5ebd40a805d3a9f433fcd8784
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sun Mar 27 06:11:41 2016 -0400

    Added a TestCloneSpatial example to do some basic clone testing.

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

commit + 95d5f58d68b76adff6305effd624eeebde1c2e60
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sun Mar 27 06:10:50 2016 -0400

    Modified the run task to pass through the log configurion
    settings system property.

M    jme3-examples/build.gradle

commit + f7c16e878ea5350efb8ac369a1b07116c7a88bf4
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sun Mar 27 05:38:43 2016 -0400

    Modified the clone function lookup to support inheritence.
    It's just too useful for things like Mesh which has a dozen
    or more subclasses... more useful than the limitations.

M    jme3-core/src/main/java/com/jme3/util/clone/Cloner.java

commit + 2028f3b3f864884d03d4ee9bf2b86f87688ee691
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sun Mar 27 04:53:12 2016 -0400

    Added 'finer' logging for the clone() method to provide visibility for
    debugging.
    Added a setClonedValue() method to force uncloned or precloned references
    in some specific use-cases.
    Added an isCloned() method to tell if an object has already been cloned
    in this cloner's 'session'.

M    jme3-core/src/main/java/com/jme3/util/clone/Cloner.java

commit + c6aac78f426886b7e71e7cc819678c6deae5ed8e
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sun Mar 27 04:51:31 2016 -0400

    Added a clone() method and implement Cloneable.
    Removed whitespace from the ends of lines.

M    jme3-core/src/main/java/com/jme3/util/SafeArrayList.java

commit + 7b29c58fe075ef0127ecb976d96d6e3e22655b64
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sat Mar 26 05:29:22 2016 -0400

    JmeCloneable related changes to TerrainQuad and TerrainPatch.  Fixed
    something I missed in NormalRecalcControl.

M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/NormalRecalcControl.java
M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/TerrainPatch.java
M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/TerrainQuad.java

commit + eda92656dd3f16992b7d551322514a874033e06e
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sat Mar 26 04:19:59 2016 -0400

    Updated AudioNode with a JmeCloneable cloneFields() method
    to clone its fields.  Some small change in behavior since the new
    methods will clone the filters, too, to avoid 'user surprise'.

M    jme3-core/src/main/java/com/jme3/audio/AudioNode.java

commit + 2f246b25bbd5648d9d343f75a98847695a3a3226
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sat Mar 26 04:08:51 2016 -0400

    Added cloneFields() method to BitmapText thought it's probably
    fruitless since BitmapText isn't even properly saveable and couldn't
    possibly have worked for any dynamic text with the old clone()
    method.
    Also a bunch of white space changes removing spaces at the ends of
    lines.

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

commit + 3f1c696e2674f132fe989ec171c5c041d56380e1
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sat Mar 26 03:55:58 2016 -0400

    Adding a comment about the strange shared fields in BitmapTextPage
    that I'm not going to touch with a ten foot pole.

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

commit + 7665fef2dede5703c928ec9bef0a962c44324f47
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sat Mar 26 03:46:48 2016 -0400

    ParticleEmitter and related classes (ugh) now implement JmeCloneable.
    It hasn't replaced the old clone() method yet and is still untested.

M    jme3-core/src/main/java/com/jme3/effect/ParticleEmitter.java
M    jme3-core/src/main/java/com/jme3/effect/influencers/DefaultParticleInfluencer.java
M    jme3-core/src/main/java/com/jme3/effect/influencers/EmptyParticleInfluencer.java
M    jme3-core/src/main/java/com/jme3/effect/influencers/NewtonianParticleInfluencer.java
M    jme3-core/src/main/java/com/jme3/effect/influencers/ParticleInfluencer.java
M    jme3-core/src/main/java/com/jme3/effect/influencers/RadialParticleInfluencer.java
M    jme3-core/src/main/java/com/jme3/effect/shapes/EmitterBoxShape.java
M    jme3-core/src/main/java/com/jme3/effect/shapes/EmitterMeshVertexShape.java
M    jme3-core/src/main/java/com/jme3/effect/shapes/EmitterPointShape.java
M    jme3-core/src/main/java/com/jme3/effect/shapes/EmitterShape.java
M    jme3-core/src/main/java/com/jme3/effect/shapes/EmitterSphereShape.java

commit + 6e999aa79bf3fc37e8a1d7836b0b1933db3ced81
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sat Mar 26 03:45:34 2016 -0400

    Tired of committing around the generated version.prpoerties
    file... so I'm remove it and fixing it with a .gitignore.

A    jme3-core/src/main/resources/com/jme3/system/.gitignore
D    jme3-core/src/main/resources/com/jme3/system/version.properties

commit + 07088452ffac45278fdd49abab1f8f30574fc931
Author: Nehon <remy.bouquet@gmail.com>
Date:   Fri Mar 25 23:49:07 2016 +0100

    Fixed binormal calculation in Single pass lighting

M    jme3-core/src/main/resources/Common/MatDefs/Light/SPLighting.frag
M    jme3-core/src/main/resources/Common/MatDefs/Light/SPLighting.vert
A    jme3-examples/src/main/java/jme3test/light/TestTangentSpace.java
A    jme3-testdata/src/main/resources/Models/Test/BasicCubeLow.obj
A    jme3-testdata/src/main/resources/Models/Test/Normal_pixel.png

commit + 2bdb3de2f5ff26d34219664e21398064aedd2cce
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Fri Mar 25 04:31:10 2016 -0400

    Started implementing the JmeCloneable stuff for Spatial
    and Mesh.  Still need to catch some of the outer subclasses of
    Node and Geometry.  Nothing is hooked up or tested yet.

M    jme3-core/src/main/java/com/jme3/app/StatsView.java
M    jme3-core/src/main/java/com/jme3/light/LightList.java
M    jme3-core/src/main/java/com/jme3/scene/AssetLinkNode.java
M    jme3-core/src/main/java/com/jme3/scene/BatchNode.java
M    jme3-core/src/main/java/com/jme3/scene/CameraNode.java
M    jme3-core/src/main/java/com/jme3/scene/Geometry.java
M    jme3-core/src/main/java/com/jme3/scene/LightNode.java
M    jme3-core/src/main/java/com/jme3/scene/Mesh.java
M    jme3-core/src/main/java/com/jme3/scene/Node.java
M    jme3-core/src/main/java/com/jme3/scene/Spatial.java
M    jme3-core/src/main/java/com/jme3/scene/instancing/InstancedGeometry.java
M    jme3-core/src/main/java/com/jme3/scene/instancing/InstancedNode.java
M    jme3-core/src/main/java/com/jme3/util/IntMap.java
M    jme3-core/src/main/resources/com/jme3/system/version.properties

commit + 665908cdeef516307ff124f69d001d53e60bfb3c
Author: MeFisto94 <MeFisto94@users.noreply.github.com>
Date:   Thu Mar 24 20:52:17 2016 +0100

    Improved the MotionEvent Cloning to not throw an NPE or edit constant Vectors

M    jme3-core/src/main/java/com/jme3/cinematic/events/MotionEvent.java

commit + 5970444b9c906fcdc64db38be356df869334f80b
Author: Nehon <remy.bouquet@gmail.com>
Date:   Tue Mar 22 18:07:58 2016 +0100

    Fixed an issue with previous commit on shadows, in the glsl100 shader

M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadowFilter.frag

commit + 493855bac96e20af7ec3895e40dfb5b0f99d56ec
Author: Nehon <remy.bouquet@gmail.com>
Date:   Sun Mar 20 21:36:28 2016 +0100

    LineWidth is now a RenderState parameter, One can change the lineWidth used to render a mesh wireframe or a mesh in Lines mode by using material.getAdditionalRenderState().setLineWidth(value)

M    jme3-core/src/main/java/com/jme3/material/RenderState.java
M    jme3-core/src/main/java/com/jme3/renderer/RenderContext.java
M    jme3-core/src/main/java/com/jme3/renderer/opengl/GLRenderer.java
M    jme3-core/src/main/java/com/jme3/scene/BatchNode.java
M    jme3-core/src/main/java/com/jme3/scene/Mesh.java
M    jme3-core/src/plugins/java/com/jme3/material/plugins/J3MLoader.java
M    jme3-examples/src/main/java/jme3test/collision/TestMousePick.java
M    jme3-examples/src/main/java/jme3test/light/TestTangentGenBadModels.java
M    jme3-examples/src/main/java/jme3test/model/shape/TestDebugShapes.java
A    jme3-examples/src/main/java/jme3test/scene/TestLineWidthRenderState.java
M    jme3-plugins/src/main/java/com/jme3/material/plugin/export/material/J3MRenderStateOutputCapsule.java
M    jme3-plugins/src/test/java/com/jme3/material/plugin/TestMaterialWrite.java

commit + 8477fa781b210c847e0f2845d48cb46bc518569d
Author: MeFisto94 <MeFisto94@users.noreply.github.com>
Date:   Sun Mar 20 20:25:39 2016 +0100

    Fixed another NPE when missing serialized waypoints and fixed having different names for write/read

M    jme3-core/src/main/java/com/jme3/math/Spline.java

commit + c4525aa5506a4cc74d82d264a0b077ec896035c4
Author: Nehon <remy.bouquet@gmail.com>
Date:   Sun Mar 20 18:56:19 2016 +0100

    Fixed MotionEvent clone for Spatial as it was resulting in controls added twice to the spatial. Also removed a useless line in all the constructors.

M    jme3-core/src/main/java/com/jme3/cinematic/events/MotionEvent.java

commit + 23fe0658a61df8f3fad302ae11561bf9b741a5f8
Author: MeFisto94 <MeFisto94@users.noreply.github.com>
Date:   Sun Mar 20 12:45:19 2016 +0100

    Fixed a NPE when Serializing a Spline without points. Also fixed a Typo.

M    jme3-core/src/main/java/com/jme3/math/Spline.java

commit + 15c9c083cd14b99e0460a2a8930701ff053dfac1
Author: MeFisto94 <MeFisto94@users.noreply.github.com>
Date:   Sun Mar 20 10:11:04 2016 +0100

    Allow MotionEvents to be cloned

M    jme3-core/src/main/java/com/jme3/cinematic/events/MotionEvent.java

commit + 8b1ddbe60fadb8955efbcd8cef38090d20b1bdea
Author: Paul Speed <pspeed42@users.noreply.github.com>
Date:   Sun Mar 20 02:47:16 2016 -0400

    First round of getting JmeCloneable implemented... added
    support for Cloner to the controls that implemented cloneForSpatial().
    Unused until spatial cloning is implemented.

M    jme3-bullet/src/common/java/com/jme3/bullet/control/AbstractPhysicsControl.java
M    jme3-bullet/src/common/java/com/jme3/bullet/control/BetterCharacterControl.java
M    jme3-bullet/src/common/java/com/jme3/bullet/control/CharacterControl.java
M    jme3-bullet/src/common/java/com/jme3/bullet/control/GhostControl.java
M    jme3-bullet/src/common/java/com/jme3/bullet/control/KinematicRagdollControl.java
M    jme3-bullet/src/common/java/com/jme3/bullet/control/RigidBodyControl.java
M    jme3-bullet/src/common/java/com/jme3/bullet/control/VehicleControl.java
M    jme3-core/src/main/java/com/jme3/animation/AnimControl.java
M    jme3-core/src/main/java/com/jme3/animation/Animation.java
M    jme3-core/src/main/java/com/jme3/animation/AudioTrack.java
M    jme3-core/src/main/java/com/jme3/animation/ClonableTrack.java
M    jme3-core/src/main/java/com/jme3/animation/EffectTrack.java
M    jme3-core/src/main/java/com/jme3/animation/Skeleton.java
M    jme3-core/src/main/java/com/jme3/animation/SkeletonControl.java
M    jme3-core/src/main/java/com/jme3/animation/TrackInfo.java
M    jme3-core/src/main/java/com/jme3/app/StatsView.java
M    jme3-core/src/main/java/com/jme3/cinematic/events/MotionEvent.java
M    jme3-core/src/main/java/com/jme3/effect/ParticleEmitter.java
M    jme3-core/src/main/java/com/jme3/input/ChaseCamera.java
M    jme3-core/src/main/java/com/jme3/scene/control/AbstractControl.java
M    jme3-core/src/main/java/com/jme3/scene/control/LodControl.java
M    jme3-core/src/main/java/com/jme3/scene/control/UpdateControl.java
M    jme3-core/src/main/java/com/jme3/scene/instancing/InstancedNode.java
M    jme3-examples/src/main/java/jme3test/bullet/PhysicsHoverControl.java
M    jme3-examples/src/main/java/jme3test/light/TestPssmShadow.java
M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/NormalRecalcControl.java
M    jme3-terrain/src/main/java/com/jme3/terrain/geomipmap/TerrainLodControl.java

commit + b218f4104e6cb0579931d2664f114bd72ff9abd8
Author: Nehon <remy.bouquet@gmail.com>
Date:   Thu Mar 17 18:05:53 2016 +0100

    Forgot to commit the change in the Cornell box model

M    jme3-examples/src/main/java/jme3test/light/TestPointLightShadows.java
M    jme3-testdata/src/main/resources/Models/Test/CornellBox.j3o

commit + be3dc06e28b1d2418cb902ac653d635c0e0c86e6
Author: jmekaelthas <mroguski@poczta.fm>
Date:   Thu Mar 17 18:05:27 2016 +0100

    Bugfix: fixed a bug that caused NPE during vertex groups loading when
    mesh block was saved without its parent.

M    jme3-blender/src/main/java/com/jme3/scene/plugins/blender/meshes/MeshHelper.java

commit + dff4befafb3ea75f57fadb18c94f4fd3b8edb6d1
Author: Nehon <remy.bouquet@gmail.com>
Date:   Thu Mar 17 17:58:41 2016 +0100

    Added an option to not render backfaces shadows with the shadow renderer and the shadow filter. It's the default for the renderer but not for the filter as it may have some edges artifacts.

M    jme3-core/src/main/java/com/jme3/shadow/AbstractShadowFilter.java
M    jme3-core/src/main/java/com/jme3/shadow/AbstractShadowRenderer.java
M    jme3-core/src/main/java/com/jme3/shadow/DirectionalLightShadowRenderer.java
M    jme3-core/src/main/resources/Common/MatDefs/Light/Lighting.j3md
M    jme3-core/src/main/resources/Common/MatDefs/Misc/Unshaded.j3md
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadow.frag
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadow.j3md
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadow.vert
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadowFilter.frag
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadowFilter.j3md
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadowFilter15.frag
M    jme3-examples/src/main/java/jme3test/light/TestDirectionalLightShadow.java
M    jme3-examples/src/main/java/jme3test/light/TestPointLightShadows.java

commit + 32be69f3e6221cf3c9f0955b5e5cb0079b695bca
Author: Nehon <remy.bouquet@gmail.com>
Date:   Thu Mar 17 14:34:18 2016 +0100

    Remove a lot of duplicate code for shadows

M    jme3-core/src/main/java/com/jme3/shadow/AbstractShadowRenderer.java
M    jme3-core/src/main/resources/Common/MatDefs/Light/Lighting.j3md
M    jme3-core/src/main/resources/Common/MatDefs/Misc/Unshaded.j3md
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadow.frag
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadow.j3md
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadow.vert
D    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadow15.frag
D    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadow15.vert
M    jme3-core/src/main/resources/Common/MatDefs/Shadow/PostShadowFilter15.frag
M    jme3-core/src/main/resources/Common/ShaderLib/Shadows.glsllib
D    jme3-core/src/main/resources/Common/ShaderLib/Shadows15.glsllib
M    jme3-examples/src/main/java/jme3test/light/TestSpotLightShadows.java

commit + 107123820bed1fd215566d3e3edad7cb84e1d304
Author: Nehon <remy.bouquet@gmail.com>
Date:   Thu Mar 17 14:02:12 2016 +0100

    Fixed material exporting NPE when the additionalRenderState is null

M    jme3-plugins/src/main/java/com/jme3/material/plugin/export/material/J3MRootOutputCapsule.java

commit + ef35af958b157a93b1379400706b74259a124f98
Author: iwgeric <iwgeric@gmail.com>
Date:   Thu Mar 17 08:57:21 2016 -0400

    Remove logging on touch events

M    jme3-android/src/main/java/com/jme3/input/android/AndroidTouchInput.java

commit + 13f68c623cedb7b3f8f254e4cf00741a83d9757b
Author: jmekaelthas <mroguski@poczta.fm>
Date:   Tue Mar 15 17:24:23 2016 +0100

    Bugfix: fixed small bug in face triangulation and several computations
    in the Edge class.

M    jme3-blender/src/main/java/com/jme3/scene/plugins/blender/meshes/Edge.java
M    jme3-blender/src/main/java/com/jme3/scene/plugins/blender/meshes/Face.java

commit + 26719e004709010d3ee220bf82395c0bd70bcb0c
Author: Nehon <remy.bouquet@gmail.com>
Date:   Mon Mar 14 20:29:58 2016 +0100

    Fixed sign post material and adjusted ambient lights for the spot lights tests

M    jme3-examples/src/main/java/jme3test/light/TestSpotLight.java
M    jme3-examples/src/main/java/jme3test/light/TestSpotLightShadows.java
M    jme3-examples/src/main/java/jme3test/light/TestSpotLightTerrain.java
M    jme3-testdata/src/main/resources/Models/Sign Post/Sign Post.j3m

commit + d9f489d8ddedde9620b7c9d0d773322d099598ec
Author: Dokthar <jmaselbas@gmail.com>
Date:   Sat Mar 12 13:55:39 2016 +0100

    removed unnecessary changes

M    jme3-examples/src/main/java/jme3test/bullet/PhysicsHoverControl.java
M    jme3-examples/src/main/java/jme3test/bullet/TestHoveringTank.java

commit + 3e0b838324586f123d81404924b68a728b2ddf73
Author: Dokthar <jmaselbas@gmail.com>
Date:   Sat Mar 12 13:50:26 2016 +0100

    fix NPE when launching the hovering test with native bullet

M    jme3-examples/src/main/java/jme3test/bullet/PhysicsHoverControl.java
M    jme3-examples/src/main/java/jme3test/bullet/TestHoveringTank.java

commit + 947904b71d35c45192955cbba0abc5937ec60eea
Author: InShadow <tomo.cesnik@gmail.com>
Date:   Wed Mar 9 07:49:07 2016 -0800

    Added public method getGeometry on Batch class.

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

phr00t · March 28, 2016, 1:29pm

This leaves us programmers in a rather void, doesn’t it? Application is now an interface, SimpleApplication is a mess, LegacyApplication is a big red sign it will be replaced… what are we suppose to do? Wait?

pspeed · March 28, 2016, 1:30pm

You are supposed to extend LegacyApplication until the new one is implemented in 3.2.

phr00t · March 28, 2016, 1:36pm

I read that part. I also read the part that “LegacyApplication” is a big red sign that it will be replaced, which makes it hard to take that advice. Will whatever LegacyApplication gets replaced with be “similar enough” to LegacyApplication, or will that require a bit change, or we just don’t know yet? Perhaps I’d (we’d?) be better served just waiting for a new Application class that actually will stick around, then convert to that.

pspeed · March 28, 2016, 1:45pm

But that means you are stuck at alpha3.

The sign is there whether you s/Application/LegacyApplication or not. Now it’s just visibly official. Application (the old class) is going away. It’s got lots of hard-coded stuff in it that should be app states. We are going to replace it. For most users, this is no big deal.

Mostly it will not be that similar. I mean the Application interface will stay the same. If you rely on specific protected fields and so on then you will have a conversion to do… but LegacyApplication will be around until at least 3.3. It’s name is an early reflection that it will be going away sometime post-3.2. I had to name it something.

So, users who extend Application directly, here is what you should do:
-extend LegacyApplication.
-realize that you will be fine all through 3.2 development and release… which given our timescale could be years. Likely, it will still exist in 3.3 and just be marked @Deprecated. So you could have until 3.4 to worry about it.
-start looking at ways you can convert your reliance on LegacyApplication internals to app states. (This will also make you well suited for providing advice on other things that need to be fixed in that regard.)

Else if it’s just the name holding you up… then extend it again just to change the name if it makes you feel better.

NotLegacyApplication extends LegacyApplication

…then extend that.

Otherwise, the ‘big red flag’ is more of a yellow flag that someday you will have to look into moving to something else… but that there will be plenty of time to do it.

phr00t · March 28, 2016, 1:53pm

Thank you for the long explanation. I don’t want to be stuck at alpha 3 if the timescale you are looking at is years (I hope development isn’t that slow!).

I dropped my reliance on SimpleApplication awhile back, hoping to avoid any expected mess… I suppose what I need to do is make VRApplication implement Application, and take the useful parts from LegacyApplication into it. Then I don’t have to use LegacyApplication or wait for your implementations of Application.

nehon · March 28, 2016, 2:05pm

Actually you should make that an AppState and just boot it through a classic SimpleApplication.
I did this with your lib a while back and it works fine. Though now your lib as changed a long meanwhile.
In my VR app my simpleApplcation doesn’t have any code, just a constructor that takes a bunch of AppStates, one of them being the OVRAppState.
This way… you don’t have to worry AT ALL about the application changes…

pspeed · March 28, 2016, 2:06pm

You’d be better off converting what you can to app states like the rest of JME will be doing… even if you do create your own base class. It makes you more compatible with other JME applications in the future and provides valuable feedback to us on what things we still need to fix in the main classes.

For example, I know that philosophically you think it is better for your users to extend VRApplication instead of passing a VRAppState on the constructor. But even still, your VRApplication could end up literally just being passing a handful of app states on the new BaseApplication class someday making your own application simpler to maintain with future updates. And in that case, we’d like to know that we have provided the right constructors for your use-case.

Especially since other libraries have to be recompiled against alpha4, being stuck on alpha3 would really limit you in the long run… or limit users of your VRApplication class.

We plan to produce releases more often going forward. But my “years” comment is still valid then because it just means that LegacyApplication will survive through more releases. I suspect you can count on it until at least 2018… even if we are on 3.5 by then. (Wouldn’t that be nice?)

In fact, this conversation just made me realize I forgot to copy the (AppState… initialStates) based constructor that SimpleApplication has over to LegacyApplication. So that will be in alpha5.

pspeed · March 28, 2016, 2:08pm

Actually, I think he’s fine to extend LegacyApplication and still convert to app states… because my plan is to deprecate SimpleApplication when LegacyApplication is deprecated. Or at least change it significantly. (SimpleApplication cannot continue to exist in its current form because of the reliance on protected fields.)

Obviously, SimpleApplication will have to live even longer before we remove it.

Edit: in @phr00t’s special case I mean.

phr00t · March 28, 2016, 2:15pm

I did previously consider moving jMonkeyVR to app states, but I ran into problems with control over the application (especially on initialization) that was important to virtual reality use. For example, I don’t want the settings dialog to appear if virtual reality is used (since users with a headset on won’t want to pull down combo boxes). In VRApplication, I can automatically check & skip the settings dialog. I’m also overloading the getCamera() call so any camera your application is using will play nice with the position & rotation changes of a headset. I found these things easier to do as an “Application” vs. an “AppState”. I also am pressed for time, so refactoring things into an AppState (especially if it will make some things more difficult) is hard for me to spend time on.

pspeed · March 28, 2016, 2:25pm

In the new BaseApplication, the launching of the settings dialog will be controlled by an app state. As will things like initializing input manager, etc…

Note: these are specifically the kinds of things we want to fix with the refactoring.

In the future, the main viewport of the application (and its camera) will be managed by an app state. The getCamera() call will literally be calling the app state to return the camera.
getState(ViewportState.class).getCamera() or whatever.

Well, yes… then your VRApplication slowly becomes @phr00t-game specific. Which is fine as I know some have already converted some of your work to an app state without issue. Properly supporting users at a VRApplication level implies some extra effort on the maintainer’s part. Else its users will get further and further behind, stuck in essentially the same place SimpleApplication is. But if you don’t have the time then it will have to wait for someone else to step up and fill the gap.

nehon · March 28, 2016, 2:25pm

That you can do in a static void main, you don’t need to extend Application.

The camera stuff is another question indeed though.

pspeed · March 28, 2016, 2:26pm

His point is that in a VR app you never want to do that but in a desktop app you might. So making it conditional based on where you are running is easier for VR app creators.

I get where he’s coming from. I also want to limit what I put in main().

phr00t · March 28, 2016, 2:29pm

If the VR stuff is in its own AppState, how will it then change the behavior of other AppStates (e.g. telling the launching settings AppState to not run)?

Having a VRApplication just sounds better conceptually, because it can work above the AppStates to make sure the right “set” of them is run, based on whether VR is enabled or not. I want developers to have to worry as little as possible at whether their program is in VR or not (which I think will lead to more VR apps).

pspeed · March 28, 2016, 2:33pm

It removes it or disables it. Some VR app devs may actually want to show the settings dialog so that they can tweak things before they put the helmet on.

But then some other library developer decides that they also must have a custom base class and then the two are forever incompatible.

The idea is to make is so that anything that formerly required subclassing application can now be done by overriding or adding (or excluding) app states.

phr00t · March 28, 2016, 2:42pm

Sounds like some sort of race condition, though? How can you guarantee the VR Application state will run first & disable the settings dialog before the settings dialog AppState is run? Is this responsibility pushed to the user of jMonkeyVR?

They could just extend VRApplication for custom behavior…

I will also add, I do some very specifically timed things in the Applications update routine, like updating the GUI node’s state late, updating the camera’s pose & submitting textures to the compositor. I’m scared of putting that into a random position in an AppState list throwing something off…

I feel like converting it to an AppState will be adding complexity for me & end users, to make very niche uses a little more easy (but by being niche uses, will be hard anyway).

phr00t · March 28, 2016, 2:48pm

I find it a little ironic that the argument is, “VRApplication will be restricting users”, when I feel “everything must be an AppState” is also restrictive.

I don’t particularly have the time to argue this, and I want to stay close with jMonkeyEngine updates, so I think I’m going to just implement the abstract Application class with VRApplication & try to make it as light as possible, so it will stay flexible.

pspeed · March 28, 2016, 2:52pm

But it might be a library never intended for VR… or that maintainer has no interest in that because it makes his life more difficult. If everyone takes your position then no one can proceed, basically.

But many of your use-cases are precisely the point. What if you could completely replace the default GUI node handling? You can’t do that today but you will be able to swap out your own app state in the future. Whether your users simply extend your VRApplication and it sets up its own app states or your users include a VRAppState that adds other app states.

From most users’ perspective, there is no material difference except that they get access to functionality that might otherwise not exist for them. Other advanced users can choose to include only the things that they want… maybe they don’t want your ‘both eyes in one pass’ thing or they don’t want the special GUI handling because they have their own special GUI handling.

As framework developers, we have to consider these cases. As a game developer, you normally don’t. But right now it seems you try to straddle the line.

Requiring users to extend your application base class to get VR functionality means that they potentially have to redo things if they’ve already extended Application for their own reasons. And their extensions may be similarly incompatible with yours.

Encouraging app states puts everyone on even footing and at worst the answer becomes “make sure this app state goes before that one”… instead of “well, you are out of luck, I guess.”

…we too often have to answer that second way today.

phr00t · March 28, 2016, 3:02pm

Then why would they be using jMonkeyVR & VRApplication? They wouldn’t be.

VRApplication isn’t trying to be everything for everyone. It is trying to make VR Application development easier for the most common uses. No worry about AppStates or their order… just start loading your content in & coding their behavior. VRApplication will handle the rest, automatically handing AppStates & whether VR is even attached.

If someone wants to make a more general purpose VR library that fits into the AppState philosophy, be my guest. I just don’t particularly have the time to do so (and is there even a demand for it…?).

phr00t · March 28, 2016, 3:07pm

4089 doesn’t use “bost eyes in one pass” with jMonkeyVR. Just set INSTANCE_VR_RENDERING to false. There also is a NO_GUI option to skip my GUI handling. I’ve thought of these things.