Introducing DynamicAnimControl

The physics specialist wants to drop both jme3-bullet and jme3-jbullet. Minie is the future of physics in JMonkeyEngine—unless @pspeed publishes a physics engine.

1 Like

I guess we were given the link to the modified code that JME uses and then no one did anything with it. I’m asking if I can have the link again.

jbullet still works better for me. native bullet has a weird bug with the catch-up stuff that means I always have to run it single step. It’s weird because I’ve looked through the C++ code and I can’t spot the problem.


Source code for jbullet:


It’s great that you found the source code. You’re probably right that maintaining 3 libraries will be difficult for one person.

As for which libraries should be included in JME 3.3, I think that discussion belongs in a different Forum topic.


The pull request is integrated into jMonkeyEngine’s master branch!

Quazi reminded me that DynamicAnimControl (DAC) ought to have a page in the JME Wiki. To that end, I would like a few new users—alpha testers, in other words—to help me see the software with fresh eyes. The usual deal: as long as you’re using the software and providing feedback, I’ll support you as best I can. Send me a private message if you’re interested.

I expect the main hurdle to using DynamicAnimControl at the moment is configuring it for new models. In parallel with the documentation effort, I plan to write a configuration tool. The current tool (TuneDac) is an ugly hack, not worth documenting. And while I am gradually adding DAC tuning to Maud, Maud is a general-purpose editor, which makes it unnecessarily complex for this task. (Maud is also a long way from supporting the new animation system.) I foresee an immediate need for a tuning tool that’s simple and easy-to-use and can be made to work with the new animation system.


I hope not. Some of us cannot use jbullet.


Minie have updated/fixed bullet native library(same as JME have). No need drop, just update with Minie changes into it.

As i understand @sgold added jme3-bullet package classes for a DAC, but to have more features from Minie, why not just update [jme3-bullet-native] and state that all features from “some new minie related package” require use of jme3-bullet-native and will not work with jme3-jbullet.

its like “for android use android packages”, because also non android will not work… or “dont use both native and jbullet because it will not work correctly”. So same could be here “dont use minie package with jbullet”

Because as i see, jme3-bullet-native is not updated to required changes. In Minie there were not just changes to allow use of Minie, but there also were some fixes for physics. (that even if someone will not use Minei features, it will fix some problems for physics itself)

@sgold, i will check everything later myself, because what i need are ragdolls(half ragdolls, legs positioning and some nice features) as you already know, but after i will finish what i started.


Please take your discussion of physics libraries to another topic. This topic is about DynamicAnimControl.

A first draft of the DacWizard tuning tool is available from GitHub:
Minie/DacWizard at master · stephengold/Minie · GitHub

Current status: a cute toy. The “easy” parts are done: load a model from the filesystem, select which bones to link, configure the links, and write (Java) configuration code to a file.

Now comes the “interesting” part: automatically estimate range-of-motion from animation data…


I solved the interesting part. DacWizard is now ready for use.

I uploaded a walk-through video to YouTube. Take a look:

Puppet model was created by Nathan Vegdahl
and is © Copyright Blender Foundation

The Blender Foundation released Puppet under a Creative Commons Attribution 3.0


re: your video: two forearm bones help simulate arm twist more cleanly, the low bone is usually constrained to only rotate with the hand on one axis to allow arm twist…long and short of it, the upper bone is the controller


That makes sense.

1 Like


I have been experimenting with this lately and I noticed that in the required Minie physics replacement library the update method of PhysicsSpace has no access modifier anymore (see Minie Source) where it was public before (JME Bullet Source).

 * Update this space. Invoked (by the Bullet app state) once per frame while
 * the app state is attached and enabled.
 * @param time time-per-frame multiplied by speed (in seconds, ≥0)
void update(float time) {
    assert time >= 0f : time;
    update(time, maxSubSteps);

This will make this method accessible only by classes in the same package (like BulletAppState) but not by user code. So it is essentially not possible anymore to step your own physics space without using a Bullet app state.

Why has this been changed and could this be made public again?

1 Like

Thank you for trying Minie and for getting in touch regarding this issue.

I changed the scope back in August, at 7f04d261. I did so because (at that time) I believed update() should only ever be invoked by BulletAppState and I wanted to avoid unnecessarily exposing library methods to application code.

However, as you point out, it’s very useful to be able to single-step a PhysicsSpace. Doing so from application code seems unlikely to cause issues. I’ll change the scope back to public.

Also essential from a server that doesn’t bother to run “all of JME” just to get app states.


Done. The change is in the newly released v0.9.0 of Minie.

1 Like

Awesome, thanks a lot! :beers:

Being able to step my own physics space is specifically useful for me because I roll my own app state management.

By the way your Dynamic Anim Control works well so far on my side, at least with the pre-configured models :+1:t3:

I think having a working Inverse Kinematics solution should be a large benefit for JME for stuff like putting feet on the ground, make characters grab onto things etc.

Keep up the good work!

1 Like