Introducing DynamicAnimControl

DynamicAnimControl is intended to replace KinematicRagdollControl for ragdoll animations, kinematic character physics, and inverse kinematics. I introduced it last month with a demo video:
(October 2018) Monthly WIP & Screenshot thread - #35 by sgold

While the API is still subject to change, it’s now stable enough for serious testing. It’s part of the open-source Minie library, which is part of the Jme3-utilities project:
GitHub - stephengold/jme3-utilities: Reusable code and assets for jMonkeyEngine games (code has New BSD license)

GitHub - stephengold/Minie: Integrate Bullet Physics and V-HACD into jMonkeyEngine projects. (code has New BSD license)

The latest Minie release is v0.4.4, which depends on 2 other Jme3-utilities libraries and also on v3.2.1 of jMonkeyEngine. You can find the JARs on GitHub at:
Release Minie library v0.4.4 · stephengold/jme3-utilities · GitHub
and on Bintray at:
Version Minie/0.4.4 - stephengold

If you use Gradle, your build script should include:

repositories {
    maven { url '' }
dependencies {
    compile 'jme3utilities:Minie:0.4.4'

Minie replaces both the jme3-bullet library and the jme3-bullet-native library, so DO NOT include those libraries as dependencies. It also conflicts with the jme3-jbullet library.

The TestDac application suggests how DynamicAnimControl might be used:

Minie/ at master · stephengold/Minie · GitHub

After instantiating a control, configure it using the methods defined by ConfigDynamicControl, particularly its link() method. (In TestDac, configuration is done by custom subclasses such as ElephantControl.) Linking a bone means it will have its own rigid body in the physics ragdoll. Any bones not explicitly linked will be managed, either by the BoneLink of their nearest linked ancestor, or (if no ancestor is linked) by a catchall link called the torso. When linking a bone, you also specify its mass and range of motion.

After the control is configured, add it to the same model Spatial that has the SkeletonControl. This instantiates the links and the ragdoll, including rigid bodies and joints. The control automatically generates hull collision shapes that incorporate every vertex in the model’s animated meshes. If there isn’t at least one vertex for the torso and also for each linked bone, this step will fail.

After adding the control to the model Spatial, add the control to your PhysicsSpace.

As mentioned in the demo video, each link can be independently set to dynamic or kinematic mode. You can have bone animations playing on specific bones (kinematic mode) while other bones are animated by physics collisions and forces (dynamic mode).

There’s also support for attachment nodes, freezing links, and even amputating limbs.

Configuring the range of motion for each BoneLink may be the hardest part of using DynamicAnimControl. Whereas KinematicRagdollControl attempted to provide a single preset for all humanoid models, DynamicAnimControl will likely require custom tuning for each model. Note that DynamicAnimControl specifies ranges of motion in “bone user coordinates” (relative to bind pose). The sample presets (ElephantControl, JamieControl, SinbadControl and so on) were created by hand using the TuneDac application to visualize the X, Y, and Z axes of each bone. I’m currently working to integrate DynamicAnimControl into the Maud editor. It may eventually be possible to autoconfigure ranges of motion based on bone-animation data.

I hope people will find DynamicAnimControl both useful and fun. I welcome questions and constructive feedback.


I’m pretty sure that LWJGL3 is compiled with some stuff that prevents the application from running when LWJGL2 is on the path… just don’t remember the name of the tech. You might want to have a look at it

1 Like

Is DynamicAnimControl compatible with new animation system in jme 3.3 ?

As the new system is the way to go, and new gltf pipeline is based on it already, I wish we could make the new 3.3 release happens sooner to prevent this gap become larger. So any contributions can/should go with new system.

1 Like

Currently DynamicAnimControl requires a SkeletonControl. SkeletonControl is part of the old animation system—the one that’s deprecated in the ‘master’ branch. Once the new animation system is officially released, I’ll look into adapting DynamicAnimControl to work with it. (If it’s as good as you say, there shouldn’t be any insurmountable difficulties.)

Meanwhile, there’s a glTF loader in the v3.2.1 release of jMonkeyEngine. If you want to try DynamicAnimControl on a glTF model, that’s the route I recommend.


i hope it will be officially in JME with new SkeletonControl class soon enough :slight_smile:

great work! :chimpanzee_cool: i belive it will be much better than current rigid body control. i understand i will be able to do for example half rigid and half dynamic skeleton behaviour :slight_smile: that i think i was unable to do with old rigid.

anyway inverse kinematic is something fun imo.

1 Like

Over the past 2 weeks, I’ve added some optional heuristics for generating rigid bodies for linked bones.

  • A detailed HullCollisionShape provides good accuracy for most linked bones, but for smaller bones such as fingers, it’s usually overkill. Now there are options to fit a 1-to-4 vertex MultiSphere or an 8-vertex HullCollisionShape.
  • There are also new options for locating the body’s center-of-mass (CoM). KinematicRagdollControl used the joint location, which worked surprisingly well. As of v0.4.4, DynamicAnimControl located the CoM at the sample mean of the vertex locations. Now it also has options to use the joint location or the center of the bounding box/sphere of the mesh.
  • Similarly, there is a new option for determining the mass of a linked bone. Instead of configuring its mass directly, you can simply configure its density, and DynamicAnimControl will estimate the volume of the shape and calculate an appropriate mass for you.

You can mix and match, specifying different heuristics for each linked bone in your model. Most of these heuristics can also be applied to attachments and to the torso.

Currently I’m implementing single-ended physics joints in Minie. These seem likely to prove useful for inverse kinematics (IK). And once IK is implemented, I’ll look at what changes might be needed for JME v3.3.


Minie has moved. It’s no longer a sub-project of the Jme3-utilities Project. It now has its own GitHub repo:
GitHub - stephengold/Minie: Integrate Bullet Physics and V-HACD into jMonkeyEngine projects. (code has New BSD license)

A new release and a demo video are planned for tomorrow.


Here’s a 6-minute video demo of inverse kinematics for DynamicAnimControl:

Source for the demo app is at Minie/ at master · stephengold/Minie · GitHub

As promised, this demo includes mixing kinematic and dynamic mode in the same model. Not walking yet.

I’ll cut a new release of Minie ASAP.


It’s super cool man :+1:

This video might give you some ideas

Also new animation system comes with idea of anim blending and masking which you might find them helpful as well. See

1 Like

in the video at 4:33 I can’t help but think “Stop! Hammertime!”


If you’re on JME 3.2, you can start using DynamicAnimControl any time you want. You don’t have to wait for JME 3.3 to be released.

The latest Minie release is now v0.6.2. You can find the JARs on GitHub at:
Release Minie v0.6.2 · stephengold/Minie · GitHub
and on Bintray at:
Version Minie/0.6.2 - stephengold

Inverse kinematics work got derailed by the JME 3.2.2 release. I hope to return to it soon. For a summary of recent changes, see the release notes:
Minie/ at master · stephengold/Minie · GitHub

The now includes the beginnings of a tutorial on DynamicAnimControl:
GitHub - stephengold/Minie: Integrate Bullet Physics and V-HACD into jMonkeyEngine projects. (code has New BSD license)

As ever, I welcome any constructive feedback.


This is my first post/reply and I’d like to thanks all the contributors to JMonkey. Its a lovely game engine.

I was wondering if I could ask the motivation(s) for Minie. From what I have read, it seems like its intention was to simplify or improve the interface to the physics system bypassing jbullet. Was there other motivations like licenses?

Since its still a wrapper for bullet/pybullet - does that mean it will be using native libraries ? If so what platforms will be supported?

I have just begun playing with JMonkey & Minie - I’m not sure, but using a maven dependency …


does not download the Minie jar - it does download jme3-utilities-debug & jme3-utilities-heart
I had to download load the Minie.jar manually and add it to my build.

I’ve cloned the Minie repo, and will look through the samples you have provided.
Thanks !

1 Like

i had problems myself, but when you use gradle(for netbeans/SDK its plugin) then i was very easy.

Minie is like upgrade for physics in JME. It add better functions, myself i will use it for Ragdoll/kinematic mixing. but it also add other things/fixes. The only thing i dont like is that it require additional libs.(heart / debug)

It override standard native JME physics with this(its for osx/windows/linux versions compiled):

Then it also override Java packages for bullet (there are jme-bullet, jme-jbullet and jme-bullet-native or something like this, where jbullet and bullet-native is your choice what you use by default in default JME). Minie is using own override for jme-bullet-native.

in main page of:

you will find how to add Minie project. I suggest graddle because i tried using Ant before and had a lot problem.

license is in Minie project. it is BSD 3-Clause License(good one), as i understand its same for sublibs.

1 Like

My motivation for creating Minie was to use it in applications. For my applications, neither jme3-bullet nor jme3-jbullet is satisfactory.

Licensing was not a concern.

Minie does use native libraries. It includes support for the same 6 platforms that are supported by jme3-bullet-native:

  • Linux32 (architecture ‘x86’, operatingSystem ‘linux’)
  • Linux64 (architecture ‘x86_64’, operatingSystem ‘linux’)
  • MacOSX32 (architecture ‘x86’, operatingSystem ‘osx’)
  • MacOSX64 (architecture ‘x86_64’, operatingSystem ‘osx’)
  • Windows32 (architecture ‘x86’, operatingSystem ‘windows’)
  • Windows64 (architecture ‘x86_64’, operatingSystem ‘windows’)

I don’t know enough about Maven to explain why you had to add it manually.

Note that the Bullet C++ code is licensed under the zlib license. Everything else in Minie is BSD 3-clause.

1 Like

The latest Minie release is now v0.6.5 . You can find the JARs on GitHub at:
Release Minie v0.6.5 · stephengold/Minie · GitHub
and on Bintray at:
Version Minie/0.6.5 - stephengold

Inverse kinematics is still on hold. For a summary of recent changes, see the release notes:
Minie/ at master · stephengold/Minie · GitHub

The now includes advice on choosing which collision shape to use.

As ever, I welcome any constructive feedback.


Here’s a 5-minute video demo of rope simulation using DynamicAnimControl:

Source for the demo app is at Minie/ at master · stephengold/Minie · GitHub

By the way, Minie v0.7.0 was released yesterday. You can find the JARs on GitHub at:
Release Minie v0.7.0 · stephengold/Minie · GitHub
and on Bintray at:
Version Minie/0.7.0 - stephengold

0.7.0 adds a new physics control MinieCharacterControl which is intended as a substitute for JME’s CharacterControl class.

For a summary of other recent changes to Minie, see the release notes:
Minie/ at master · stephengold/Minie · GitHub

As ever, I welcome any constructive feedback…


The code used in today’s buoyancy video is online at Minie/ at master · stephengold/Minie · GitHub

Minie v0.7.6 was released tonight. You can find the JARs on GitHub at:
Release Minie v0.7.6 · stephengold/Minie · GitHub
and on Bintray at:
Version Minie/0.7.6 - stephengold

For a summary of the recent changes, consult the release notes:
Minie/ at master · stephengold/Minie · GitHub

Also, I’ve updated Minie’s to clearly explain why you might want to use Minie instead of jme3-bullet or jme3-jbullet: Minie/ at master · stephengold/Minie · GitHub


Today I submitted a pull request to add DynamicAnimControl to jme3-bullet and jme3-jbullet.

The PR implements a very pared-down version of DynamicAnimControl, corresponding roughly to its feature set in Minie as of October 2018. It doesn’t support:

  • attachments,
  • physics links without vertices,
  • frozen dynamic links,
  • bound/amputated kinematic links,
  • link volumes and densities,
  • centering heuristics,
  • shape heuristics,
  • inverse kinematics, nor
  • footprint estimation.

Many of these features will be very difficult to add to jme3-jbullet without access to the source code.

The good news is that it seems feasible to transition Minie to the new animation system. The port will probably take place in a new branch of the Minie repo, and for a while each release of Minie will be double: one version for JME 3.2 and one for JME 3.3. Since branching implies duplication of effort, I hope to make the transition period as short as possible. I haven’t decided when this should happen.


if noone really have jme3-jbullet sourcecode (but i remember someone provied link to some old fork) then i belive we should drop support for it, or “if someone is able”, then write a new one based on some older versions.

by drop i mean at least for DynamicAnimControl, because its like dead end because of jBullet.

because it block a lot. you are physics specialist here now :wink:

1 Like