The Minie physics library

From roughly Minie v0.9.5 (July) on, there have been 2 branches in the Minie repo:

  1. for_jME3.2 targeting JME v3.2 and
  2. master targeting JME v3.3.

The recent releases have all been double: one build from each branch. The main difference between them is that the master branch supports the new (com.jme3.anim) animation system in addition to the old (com.jme3.animation) one.

In addition, the 3.3-alpha5 introduced a breaking change to the AppState interface. So it’s unsurprising that Minie v0.9.1 doesn’t work with jME 3.3-alpha5.

1 Like

Yes, the issue was with the breaking AppState changes.

1 Like

The 1st “stable” release of Minie is available. (One less excuse for avoiding Minie!)
There are 2 builds:

Please give them a try.

Next task: flesh out the README and tutorials.
Then: add Minie to the JMonkeyStore.
Then: back to work on the “desert fortress” game scenario.


Cool, thank you so much @sgold. :slightly_smiling_face:

1 Like

Minie v1.0 is now listed at JMonkeyStore:


In case you want to beta-test JME 3.3 on an application that uses Minie, I’ve released a version of Minie that works with 3.3.0-beta1:


Or should I say “that works with v3.3.0-beta1”.

Not anymore. The incorrectly named version has been removed until we can get the build working correctly and publish a proper 3.3.0 beta1

Everything I built on Sunday night and Monday morning is now broken. No more beta testing for me! :frowning:

I warned you when you did it that it wasn’t right and was better to wait.

The problem with v3.3.0-beta1 is that it would supersede all future 3.anything releases for the end of time. So if someone in the future had a project that was depending on jme 3.9.9 and somehow was still linking to this version of minie, they’d automatically be back-rev’ed to v3.3.0-beta1 because in the versioning scheme it looks “newer”.

Rather than deal with this sort of odd pain forever, I chose to deal with a tiny bit of pain for 2-3 days from a very few people by deleting the versions. Only life issues prevented me from the 500 clicks it took to do it right away when you found the issue.

1 Like

I hope everything is all ok. You’re handling of everything is inspiring to us all. :heart:


I’ve released v1.2 of Minie. There are 2 builds:

The main feature of this release is New6Dof, a new type of 6-degree-of-freedom PhysicsJoint based on Bullet’s btGeneric6DofSpring2Constraint. It provides functionality similar to the familiar SixDofJoint and SixDofSpringJoint classes (which are based on btGeneric6DofConstraint and btGeneric6DofSpringConstraint, respectively).

The Bullet Manual (page 25) recommends using btGeneric6DofSpring2Constraint over btGeneric6DofConstraint or btGeneric6DofSpringConstraint.

I tested New6Dof simulating both ragdolls and robots, and it worked fine. I expect it to eventually supplant both SixDofJoint and SixDofSpringJoint in 99% of applications.


i like this black magic, even if i dont know what it exactly do :innocent: (hope for video)

1 Like

Really great contribution, Stephen. Literally a drop-in replacement for bullet with enhancements and extras. I have been using this for just over a month myself. It’s exactly what the physics side needs.

Great work indeed :slight_smile:


A physics joint connects one physics object to another (or to a fixed point in space), constraining how it can move.

For instance, a door might swing on its hinges. In a physics simulation, the hinges would be represented by a joint with a single degree of freedom (DOF): rotation around the axis of the hinges.

Or the door might slide along a track. In that case, the track would be represented by a joint that’s free only to translate along the axis of the track.

Or you might have a robot arm mounted on a ball-and-socket: it can freely turn and twist to any imaginable orientation, but can’t leave its socket. (This requires 3 degrees of freedom.)

A 6-DOF joint is a very flexible joint with 3 rotation DOFs and 3 translation DOFs. It can rotate or slide on any axis. This makes it useful for simulating other kinds of joints.

  • To simulate a swinging door, you’d lock all 3 translation DOFs and all but one of the rotation DOFs.
  • To simulate a sliding door, you’d lock all 3 rotation DOFs and all but one of the translation DOFs.
  • To simulate a ball-and-socket, you’d disable all 3 of the translation DOFs.

In addition to locking DOFs, Bullet’s 6-DOF joints also implement limits, springs, motors, and servos for each DOF:

  • Using a limit, you can keep a door from sliding/swinging past certain points.
  • Using a spring, you can make a door automatically return to the closed position when you release it.
  • Using a motor, you can control the rate at which a door opens and closes.
  • Using a servo, you can make a robot arm turn smoothly from one orientation to another.

oh ok, so its like All-in-one that can be “adjusted” to what is needed. :slight_smile:

it was odd for me since 3-DOF as 3 degrees was certain for me, now i understand 6 mean is 3 rotations and 3 translations. I will need to learn how this all joint types work anyway.

IDK why, Somehow it reminds me robot arena game, where was multiple motor joint types.

1 Like


Erwin Coumans (who manages the Bullet Project) seems to be involved with robotics, so it’s not surprising the terminology is similar.

1 Like

I’ve released v1.3 of Minie. There are still 2 builds:


  • new collision shapes optimized for static 2-D objects: Box2dShape and Convex2dShape
  • many more options in the DropTest demo, both for the static platform and the falling bodies
  • The README has been expanded and improved, particularly the “Choosing a collision shape” section.
  • added getters for the braking, engine force, and steering angle of a VehicleWheel
  • determine which wheels of a PhysicsVehicle/VehicleControl are off the ground
  • implemented debug visualization for PlaneCollisionShape

I’ve released version 1.4.0 of Minie. As usual, there are 2 versions: 1.4.0for32 (for JME 3.2.4-stable) and 1.4.0for33 (for JME 3.3.0-beta1).

Note that Minie’s Maven groupId has changed from “jme3utilities” to “com.github.stephengold”. This change was necessary in order for Minie to be included in JCenter; your build scripts no longer need to reference my personal Maven repositories.

Other highlights:

  • fixed some nasty scaling bugs involving CompoundCollisionShape and Convex2dShape
  • V-HACD support is now built into Minie, including progress listeners
  • based on Bullet version 2.89
  • ray tests and sweep tests now return info (for some shapes) to pinpoint which part and/or triangle was hit
  • debug visualization can now be used to color the children of a CompoundCollisionShape
  • the DropTest demo has been massively enhanced with many cool shapes

Behind the scenes, automated tests were added to Libbulletjme (the native-library project that Minie depends on). A spin-off of this effort is that Libbulletjme can now be used to provide physics simulation and V-HACD to Java applications that don’t use JMonkeyEngine.

Don’t ask me why anyone would want to use physics for anything other than JMonkeyEngine games! But there it is … :wink:


Am I correct in saying that minie can now be used as a drop-in replacement for native bullet - with the benefit of it using a more up-to-date bullet build and additional functionality?