As many of you know, I’ve been working for the past year on an improved physics library for jMonkeyEngine, to replace jme3-bullet. Like 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.
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.
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.
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)
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
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
A 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 jme3-bullet:
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.
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
