Another quick update on the Minie project:
150 commits in the past 16 days, not counting C++ code. A couple important bug fixes. Most of the demo/test apps now have UI hints to help users get started. Soft-body joints are implemented; there’ll be a v0.9.4 release as soon I convince myself they actually work. Then, perhaps, I’ll port Minie to JME 3.3.
I’m convinced that soft-body joints work, but I’ve had difficulty writing a convincing demo for them. (Bullet’s demo for soft-body joints is a bunny rabbit on wheels bouncing down a staircase.)
Even if you don’t care about soft-body joints, there’s plenty of goodness in the new v0.9.4 release. See the release notes for details.
I’ve asked JFrog to boost Minie (and jme3-utilities-heart) from BinTray up to JCenter, which should make it even easier to use—in Gradle builds, at least.
I was unsuccessful getting Minie boosted up to JCenter. I believe that, in order to do it properly, I’d need to purchase an Internet domain. I’m not convinced it’s worth the hassle.
The port to JME 3.3 is complete. (One less excuse for avoiding Minie!) Two new builds are available:
Please give them a try.
Thank you so much @sgold. I am going to migrate to Minie 0.9.5 for 3.3 today.
btw, I also noticed Minie collision shapes have some extra functionalities, like generating AaBb from the collision shape which I am going to need at the server side.
I look forward to your feedback.
A caveat about the CollisionShape.boundingBox() method: I added it mainly for debugging purposes. It returns the bounds used in Bullet’s broadphase collision detection. This might be the minimal axis-aligned bounding box for the shape, but in practice it’s usually larger. Depending on your needs, this might or might not work for you.
thanks, i will check it for sure! so i understand new animation system will cooperate with Minie 
now i imagine character using soft body cloak, and new animation blending and ragdolls, or some critter with half-body ragdoll will need verify everything.
Oh, yeah. Soon! Until then, you’ll have to learn by studying the demo apps:
reading Chapter 9 of the Bullet Manual and the soft-body section of the JME wiki, and asking questions.
PS: Come to think of it, I want people to ask questions. Questions will help me figure out what to put in the README. Either ask them here or send me private messages.
Thanks
I’ve added a couple tutorial apps for soft bodies, including one that demonstrates collisions between 2 soft bodies. For links, see the Introduction to soft-body physics section of the readme.
2 new releases of Minie are available: v0.9.6for32 and v0.9.6for33.
About a page worth of TODOs remain, including:
… but none of these seem urgent.
As long as there are no questions or issues, I’ll take a break from Minie to work on my game.
@sgold I noticed there is a double-precision release for Libbulletjme.
If I am understanding it right, it is for native side calculations and the result is converted to float to be used in Minie, Yes?
So far all the released versions of Minie use single-precision native physics. However, it’s not difficult to construct your own Minie with double-precision native physics. Simply edit the MinieLibrary/build.gradle to change
btfLinux32 = 'ReleaseSp'
btfLinux64 = 'ReleaseSp'
btfMacOSX32 = 'ReleaseSp'
btfMacOSX64 = 'ReleaseSp'
btfWindows32 = 'ReleaseSp'
btfWindows64 = 'ReleaseSp'
to
btfLinux32 = 'ReleaseDp'
btfLinux64 = 'ReleaseDp'
btfMacOSX32 = 'ReleaseDp'
btfMacOSX64 = 'ReleaseDp'
btfWindows32 = 'ReleaseDp'
btfWindows64 = 'ReleaseDp'
and do a clean rebuild.
You can also build using the debug natives:
btfLinux32 = 'DebugSp'
btfLinux64 = 'DebugSp'
btfMacOSX32 = 'DebugSp'
btfMacOSX64 = 'DebugSp'
btfWindows32 = 'DebugSp'
btfWindows64 = 'DebugSp'
or omit natives you don’t need:
btfLinux32 = ''
btfLinux64 = 'ReleaseSp'
btfMacOSX32 = ''
btfMacOSX64 = ''
btfWindows32 = ''
btfWindows64 = ''
Thanks. 
And yes, the native doubles get converted back to floats on the Java side.
And one more question, in jme-bullet I was updating physics space using
/**
* Bullet doc: stepSimulation proceeds the simulation over
* 'timeStep', units in preferably in seconds. By default,
* Bullet will subdivide the timestep in constant substeps of
* each 'fixedTimeStep'. in order to keep the simulation
* real-time, the maximum number of substeps can be clamped to
* 'maxSubSteps'. You can disable subdividing the
* timestep/substepping by passing maxSubSteps=0 as second
* argument to stepSimulation, but in that case you have to keep
* the timeStep constant.
*/
pSpace.update(1 / 60f, 0);
seems configuration is changed in Minie?
I see beside the maxSubSteps a new maxTimeStep introduced in Minie.
I guess following settings should be enough to use the fixed time step, Yes?
pSpace.setMaxSubSteps(0);
pSpace.update(1 / 60f);
Sorry if my question is noob, just wanted to get sure if I do not need to set anything else. 
And one suggestion,
Can you please re-add these methods to DebugShapeFactory in Minie:
I need them in my PhysicsEditor at the client-side to create debug mesh from CollisionShape which I load directly from disk without having a PhysicsCollisionObject.
Edit:
Okay, I just tried it by adding the collision shape to a dummy PhysicsRigidBody and seems it fixed my issue.
DebugShapeFactory.getDebugShape(new PhysicsRigidBody(shape));
Yet I guess it would be more convenient to have those methods in Minie DebugShapeFactory, I might be wrong anyway.
Unless you’ve modified maxTimeStep (defaults to 1/10 second), that code should suffice.