Let's discuss jMonkeyEngine 3.3!

Well I’ve only spent maybe 5 days or so on this (plus a few days of in-head-planning), but here’s the checklist.

  • database for storage
  • spring for endpoints
  • a skeleton JSON API
  • login/logout/sessions
  • user control panel
  • avatars
  • admin control panel
  • Assets
    – asset creation (with markdown support)
    – editing
    – tags
    – staff approval for new assets
    – staff approval for amendments to existing assets
  • image uploading/serving
  • youtube videos
  • endless javascript…

It’s starting to look a bit like the part. Still a long way to go I guess.

In its current state you can only put the following external links:

  • git repository
  • documentation page
  • publisher website

but adding published dependencies is obviously possible. I wrote a prototype before that used a custom protocol (i think it was jme://) to open links - which could be hooked up to the “auto-pull-build” local maven repository. Anyway. One step at a time. I’m writing the website at the minute. The “add-on” apps are for another day if they every come to light.


That could work when you just search for the jme3-darkmonkey.nbm from your sdk install and try to install it on a regular netbeans as module.

The problem there would be the gradle dependencies, I could at most only copy in the jars but then trouble starts with people trying to use it: Which version do you run? SDK! :smiley:

Another thing I guess is the problem that I could not find a simple “gradle template for jme”, because there is nehon’s tool which I guess had to download and execute, there is stephen’s template, which I had to edit for some reason etc.

So there wasn’t some “just download this repo as zip and extract to see the blue quad”.

That is AWESOME! (Especially for 5 days work.) What toolkit are you using for the frontend UI?

1 Like

Travis gave me that “this is not a tagged commit” BS again. Hang on.

This was my simple gradle game template:

For what it’s worth.

It’s semantic-ui - first time I’ve used it and it’s pretty cool. It’s not often I get the chance to choose the artistic ingredients. I usually just put things where they go and an artist does the rest.

1 Like

v3.3.0-alpha1 is deployed. When you have a moment, @pspeed, please push the button.


166 new files will be publicly available shortly


Going to try the new animation system.


Ragdoll physics and inverse kinematics are known gaps in the new animation system. I expect DynamicAnimControl will fill those gaps—for native Bullet, at least.

I plan to add DynamicAnimControl without adding a new branch to the repo, simply integrating it one piece at a time into jMonkeyEngine’s master. I think this can be done without breaking anything.


great idea, but you would need go depper to understand new animation system. like @Ali_RS said there are now Tweens. quote:

Action : An action is a composition of Tweens. It can be a single tween, a sequence of tweens, or tweens called in parallel way or a mix of all this. An Action is also a Tween, so it can be composed as part of another action and so on. An action can be provided with a Mask that will define a subset of targets on which it applies (a subset of Joints in an Armature or a subset of spatials for spatial animations)
Notables built in actions : (this may change a bit)
BaseAction : An action that wraps a Tween
ClipAction : an Action that plays an AnimClip
BlendAction : an Action that allows you to blend AnimClip together (think half walk / run animation varying depending on the forward speed)
That’s basically it. Note that Tweens can be basically anything, so the base action already provides virtually endless possibilities:
Stock Tweens that I plan to provide:

  • SoundTween : play a sound
  • EffectTween : fire a particle emitter
  • MaterialTween: animate material’s properties
  • ChangeActionTween: tells the AnimComposer to change the current Action

Stock Tweens available in Lemur (will probably be ported to jme’s core):

  • Sequence tween: a tween that plays tweens in sequence.
  • Parallel tween: a tween that plays tweens in parallel.
  • Delay tween : a tween that just waits…
  • Stretch tween: a tween that wraps another tween and change its duration.
  • Camera tween: moves the camera…

so i think DynamicAnimControl would need some integration to have both working properly. i belive there will be a lot conflicts. im not sure if you already analyzed this code or not, but looks like much more different system.

1 Like

The 1st 2 pieces don’t involve animation, merely porting over Minie’s EmptyShape and MultiSphere collision shapes. After that, the integration will get more complicated. It seems prudent to plan ahead.

DynamicAnimControl interacts with the old animation system by interposing itself between the AnimControl and the SkeletonControl and reading/modifying Bone transforms on the fly. I haven’t gone deep, but I’m hoping there’s a similar opportunity in the new animation system.

How does the new system communicate Joint transforms from the AnimComposer to the SkinningControl?

Another problem is: I guess for now only GLTF uses the new animation system after import. Consistency has to be built there, but fortunately there seems to be a utility class which converts the old system structure to the new one.

1 Like

Answering my own question: just as every SkeletonControl has a Skeleton, every SkinningControl has an Armature. DynamicAnimControl should have no difficulty reading and modifying the Joint transforms in the Armature before any skinning matrices are computed.

Tweening and blending seem to happen entirely in the AnimComposer, where they’re invisible to DynamicAnimControl.

So good news: the class names have all changed, but as far as DynamicAnimControl cares, the new animation system isn’t much different from the old one.


In case anyone is confused about my role here:

  1. I have low interest in jMonkeyEngine 3.3. I’m not using it in my projects yet. I’m neither its architect nor its release manager nor its lead developer. Neither will I review every pull request.

  2. I’m willing to cut alpha releases as desired, with the necessary help from @pspeed.

  3. I will continue to report issues I find and fix them when I feel like it.

  4. I will attempt to support any code I have contributed to jMonkeyEngine, including DynamicAnimControl.


So is there a lead developer or release manager / project overlord? I’ve always wondered.

1 Like

Someone usually takes it upon themselves… which used to be easier when there were a lot of core devs.

Looks like I will be the stuckee this time.


Is it time for 3.3-alpha2?

Some notable changes since alpha1 (as I remember):

  • Some bugfixes in physics and adding of new DynamicAnimControl
  • Java 11 support
  • Bugfix and improvement in AnimComposer
  • Updates to joystick support
  • Bug fix in joystick connection/disconnection in game. (this one is not merged yet, is waiting for @pspeed approval :wink:)
  • Support for AmbientLight in PBRLighting
  • Support for adding substeps in profiler

Support for TF would be nice PR #1078. :slightly_smiling_face:
I also wonder who are the main contributors who can review/merge such PR. It also contains the change that VertexBuffer now extends BufferObject, which I briefly discussed with @pspeed, thus I can hardly imagine someone else reviewing the code. This can be separately viewed at (refactor base class buffer object · TehLeo/jmonkeyengine@0037e13 · GitHub) .

I know reviewing PRs can take considerate amount of time. I do not expect anything soon.

But even thou the PR is a bit bigger, with 50 hours spent on developing it I can say it was written carefully. :slightly_smiling_face:


Anyone can review a pull request, but only the Owners and Members (of the jMonkeyEngine’s GitHub organization) can merge a PR. There are 32 of us: People · jMonkeyEngine · GitHub but most of those are inactive.

Reviewing PRs is the bottleneck. Due to human nature, shared responsibilities tend to suffer neglect. Sometimes it helps to ask a specific person. Sometimes I merge my own PRs without any outside review.