The Minie physics library

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?


I wouldn’t say that. There are still incompatibilities between Minie and jme3-bullet:

(1) Minie doesn’t support any Android or ARM platforms.

(2) Minie’s character control has a different name.

(3) Minie lacks KinematicRagdollControl.

(4) There are other incompatibilities in seldom-used areas (such as PhysicsSpace.addAll() and debug visualization) where I believe jme3-bullet was poorly designed.

I regard jme3-bullet and jme3-jbullet as legacy code. People shouldn’t use them without a good reason. But then, I’m a guy who still uses Java 1.8 and Windows 7, so who am I to judge?

By the way, do you have any suggestions on how to accelerate adoption of Minie?

It would be a great idea to write a blog entry about it - which would be picked up b google and therefore any physics + jmonkeyengine search would yield the blog page. It would also be included in the front-page since it will be the latest blog entry.

1 Like

I assume you’re referring to the JME blog at

How do I post to it?

Details are here.

Or if you prefer just write a markdown based post and I can do the rest.

1 Like

Wrote a post in the style of a press release and committed it to the repo, but I don’t see it yet, even after pressing Ctrl-F5. How often is the website updated?

1 Like

You have to build the html and push it to the github pages repo. Details are in the readme here.

1 Like

The blog post announcing Minie v1.4 is now live:
jMonkeyEngine | Minie Physics Library Version 1.4 Released!


nice, this is first post there (except Jayfella one).

I thought there will be more posts, but if there is problem people write it, then i think @jayfella should put something automatic there too, like Monthly topics or something.


Exciting developments in Minieville this month:

  • CharacterControl class and additional PhysicsSpace constructors (for compatibility with jme3-bullet)
  • bug fixes, including issue 1283
  • Linux-on-ARM64 support
  • new classes CollisionSpace, ConvexShape, MultiBody, MultiBodySpace
  • allow use of New6Dof joints in ragdolls
  • continuous integration

Expect a new release in early March…


Version 1.5 of Minie has been released. As usual, there are 2 versions: 1.5.0for32 (for JME 3.2.4-stable) and 1.5.0for33 (for JME 3.3.0-beta1).

The new release improves compatibility with jme3-bullet by adding:

  • a CharacterControl class (not 100% compatible, but suitable for most purposes)
  • 2 missing PhysicsSpace constructors

It also introduces some important new capabilities:

  • utilize New6Dof joints in a DynamicAnimControl
  • collision detection without dynamics (in a CollisionSpace)
  • 4 alternative contact-and-constraint solvers for physics spaces
  • 3 additional tuning parameters for contact-and-constraint solvers
  • support for “multibody” physics (see below)

It also fixes several known bugs in version 1.4.0:

  • JMonkeyEngine issue 1283: continuous collision detection doesn’t respect collision groups
  • Minie issue 3: crash at the peak of a character’s jump (with debug libraries)
  • a NullPointerException in the DacWizard application
  • compound shapes read from J3O assets always get the default margin
  • meshes returned by DebugShapeFactory.getDebugMesh() have incorrect bounds

Multibodies are a feature of Bullet that isn’t accessible via jme3-bullet. A multibody represents a hierarchy of rigid colliders connected by joints, similar to a DynamicAnimControl. For an example of their use, see Hoping that multibodies might provide more efficient simulation of ragdolls, I added support to Minie, but as of this release, the feature is EXPERIMENTAL.

Linux-on-ARM support was also planned for this release. However, there were a couple hitches:

  1. The native assemble-and-test process relied on a Linux-on-ARM environment at that stopped working (for me) sometime around 18 February.
  2. JMonkeyEngine issue 1286, which is fixed in JMonkeyEngine’s master branch but not yet in any release

nice work! :+1:

You have added many new joint types/etc/fixed a lot issues and soon i will upgade and rebuild character again, so i got a questions:

idea: make character receive point physics force when hit, not breaking played 3.3 animation.
(character get shot in some part, and it have some recoil in this place while 3.3 animation is still playing (blending))
for example when someone get shoot in shoulder, he have visual effect of it.(torso go back and rotate)
for a leg same, but i also planned for a moment make ragdoll.

how solve idea:
when character shoot in for example left shoulder, create physics based pose(calculated in 1 frame)(idk if do via IK or just ragdoll based) and blend it with current 3.3 animation (so blend would give effect like character took physics force into left shoulder).

how solve idea 2:
just make partial ragdoll of bones near hitplace for 1 second, then blend again to animation. (and just switch DAC between kinematic/ragdoll for a moment)

Could you please suggest me best solution you would see here? Maybe there is some simple solution i dont know about, so i would prefer know it before start doing it.

when i will success with doing what i plan, will show video result later.

1 Like

also i wrote PM to you, but i removed it, so dont even look.

I had one issue before. Seems like Minie for 3.3 package require(in deps) JME-core beta1, is this possible make one that require 3.3 (no subversion) ? so i could use alpha5?

it was crazy for me, because im my deps i use alpha5, so when added Minie for 3.3, it changed jme-core package to beta1 for me.(Shape keys issue => will be fixed in beta2 and dont exist in alpha5)

1 Like

You can exclude the jme3-core module from coming with Minie in Gradle:

compile ("com.github.stephengold:Minie:$minieVersion") {
    exclude group: 'org.jmonkeyengine', module: 'jme3-core'
1 Like