As many of you know, I’ve been working for the past year on an improved physics library for jMonkeyEngine, to replace
jme3-bullet, the Minie library is based on the Bullet real-time physics library. Minie is named after after Claude-Étienne Minié, who developed an improved rifle bullet in 1846.
The DynamicAnimControl class for ragdoll simulation was developed for Minie. I’m currently adding soft-body physics, based on Dokthar’s fork.
Minie is open-source software. Most of the native code is under a zlib license; the rest of the native code and all of the Java is under a New BSD license.
The main repo is at GitHub: GitHub - stephengold/Minie: Integrate Bullet Physics and V-HACD into jMonkeyEngine projects. (code has New BSD license)
Version 0.9.0 was released on Tuesday. It’s available from GitHub, BinTray, and JitPack:
Really glad to see physics getting some love! One question I have (and maybe you’ve looked at this already) is what the trade offs are with using SWIG to auto generate bullet bindings. My understanding is that is what libGDX is doing for their Bullet support. (Not that it’s something to be done because they’re doing it, and if your current workflow works well for you then there’s no point to switching things up - but it may provide some nice time savings.)
Thanks for pointing me to this. Though it looks useful, I haven’t tried it yet. I wonder how well it’d work with Gradle and Netbeans.
As you hypothesized, my current workflow (writing JNI “glue code” by hand) is working for me, so I don’t see a compelling reason to change at the moment. But I’ll keep it in mind.
Perhaps the folks (if any) working on
jme3-vr could benefit from SWIG.
That’s a long list of bugfixes.
I assume this is still using float rather than double precision?
Yeah, I guess different Bullet natives would need to be compiled for a double precision option… (Hey, you didn’t constrain what you wanted to ultimately improve above, so I had to put it out there!)
There aren’t plans to remove jbullet, are there? (just curious)
@sgold does Minie support android?
afaik, JME has a native bullet android build, so what about having android builds for Minie too?
Yes. I’ve thought about creating double-precision libraries. It ought to be straightforward, but it’s not high on my priorities … yet.
Not that I’m aware of. Back when the source code was missing, I suggested removal and encountered resistance. Now I’m less adamant.
At the moment, Minie is desktop-only.
It’s true that jMonkeyEngine provides a native Bullet library for Android. However, it’s not updated as often as the desktop version. Reason: the desktop version is built automatically (by our continuous integration process) and the Android version is not.
based on your ragdoll video in the other thread it looks like this maybe able to work well for character that engage in a fair bit of dynamic movement, you know rolls, dives, slides…I tried with what already exists but always seemed to literally hit upon issues because the shapes wouldn’t always fit the character or be in the right place, so would this always “fit” the character during animation could there still be collision issues depending on the character body shape
That sounds about right, though I wonder what you mean exactly by “collision issues”. Care to elaborate?
I just want to confirm that the colllision objects will conform to the model pose most if not all the time. So if for example a model should be able prone under a low table that the collision shapes won’t prevent that due to size and orientation
DynamicAnimControl in purely kinematic mode will conform its collision objects to match the model, even if that model has bone animations.
In practice, the collision shapes are simplified and physics ticks are asynchronous with rendered frames, so the conformity is imperfect. But it should suffice to allow characters to crawl under obstructions.
One other question does minie have an interface for detecting bone on bone collision between two ragdolls, that’s another thing I never got going with what exists now, e.g ragdoll1 hand hits ragdoll2 chest,
Minie has collision-detection interfaces similar to
- You can add collision listeners to the
PhysicsSpace to be notified about up to 4 collision contacts per colliding object, including references to both objects. (Each bone in a ragdoll has its own collision object.)
- You can add collision-group listeners to the
PhysicsSpace to be notified about collisions involving particular groups.
- You can add ragdoll-collision listeners to any
DynamicAnimControl to be notified about collision contacts involving its ragdoll where the applied impulse exceeds a certain threshold. (This is built atop interface #1.)
- You can invoke
getOverlappingObjects() on any
PhysicsGhostObject to enumerate all collision objects that overlap with it, based on axis-aligned bounding boxes.
TestBoneRagdoll example uses interface #3 to detect when the projectile hits Sinbad:
yeah I know that projectile collisions will work my concern is character on character contact, never got it to work in jme3 even though I was told it would, for some reason both dolls would only register bone on bone contact on ragdoll A for both ragdoll A and B and not even accurately, I ended using added geometry and mesh contacts to detect hand to hand strikes, but it was kinda wonky will dig in during the weekend though can’t touch it now.
A question though, I’m trying for fairly fleshed out melee combat: strikes and tackles some grappling , where the hit zone determines both damage and reaction animation, is using ragdoll collisions good for this or should I take a different approach, not a high level coder by any stretch so some advice would be good
I haven’t actually tested ragdoll-vs-ragdoll collisions, but I expect they’ll work in Minie.
Fully fleshed-out melee combat sounds very complex. If you’re not confident in your abilities, perhaps you should focus on simpler projects until you gain more confidence.
trust me I’m working in baby step increments with this…my “game” right now are just a bunch of “idea” tests…“I wanna try to do this” research it…write test…“I wanna try to do that” research it…write test, it works yay, not work…back to the drawing board…literally trying everything I want to achieve in a sandbox sort of thing and when I’m satisfied with the components I’ll slap it all together…but yeah bite size bits
If your tests find any issues with Minie, let me know.
any news about implementing more Minie features into JME basecode?