Jolt JNI isn’t quite production-ready. As often happens, I discovered rough spots and gaps while writing tutorials. However, a v0.9.9 has been released, and I estimate v1.0.0 is less than a month away.
KK Physics remains a long way from being production-ready. It’s still a prototype, and I may abandon it entirely. If I do, I’ll probably launch a less-ambitious project to simplify using Jolt JNI with JMonkeyEngine. (JME projects can already use Jolt JNI directly; it’s just a tad inconvenient.)
Up till now, I haven’t had any difficulty getting 3rd-party libraries added to the JMonkeyEngine SDK. However, I’m not directly involved in the SDK, and I can’t predict its releases.
Thanks !!
Just make some tutorials so, it will be easy to use for people like me. its ok if you are completely stop working on KK physics.
No problem !!
The Jolt-JNI tutorial is about 50% done, with pages on rigid and soft bodies, constraints, characters, and vehicles, but nothing yet on collision queries or ragdolls or performance tuning. I plan to continue improving the tutorial, but not very intensely.
With Jolt JNI v1.0 in the jar, I’ve been thinking more about integrating Jolt Physics into JMonkeyEngine.
First, I’m having second thoughts about the name “KK Physics”. It’s short, creative, and easy to remember. However, “jme3-jolt” would be more self-explanatory.
More importantly, a lot of code needs to be written to make Jolt JNI convenient for use in “real games” as opposed to sample apps, performance tests, and demos:
Integrate physics into game assets at runtime. This implies:
standard scene-graph controls to associate spatials with physics objects such as bodies, characters, vehicles, and ragdolls
debug visualization. For this, I envision an AppState with access to both the PhysicsSystem and also any ragdolls and bodyless virtual characters.
Integrate physics into game assets prior to runtime. This implies:
The physics scene-graph controls should implement both Savable and JmeClonable. This implies the settings objects should also implement those interfaces.
Serialization is tricky to do correctly, that is to say, with portability between platforms and to future software releases. For instance, Bullet implements serialization at the native level, but Minie doesn’t use Bullet serialization except in one case, where it has caused a lot of trouble.
If I can rely on Jolt Physics to serialize settings objects, that will make JME integration a lot easier.
The Jolt-JNI API wasn’t as stable as I hoped it would be. Five days after I released Jolt JNI v1.0.0, the author of Jolt Physics made a minor breaking change to the Jolt Physics API, requiring a corresponding change to the Jolt-JNI API.
The Jolt JNI v2.0.0 release failed due to a process issue: I misunderstood how the new “Portal OSSRH Staging API” works for releases staged from CI hosts. That’s good news, actually, because it should save me from making the same mistake on the JMonkeyEngine project!
I ran a quick performance test using TestManyBoxes, and the result was acceptable.
EDIT: Something went wrong with the v2.0.1 release, and MacOSX_ARM64 artifacts were not published. I am investigating.
EDIT^2: The missing artifacts have now been published. Sorry for the confusion and delay.
It’s been exactly a year since I wrote, “I regard KK Physics as potentially a 3-year project.” That prediction still seems accurate.
My plan to promote Jolt JNI at the LWJGL Discord server is on hold since I discovered how attached the LWJGL community is to PhysX. Before I can articulate the advantages of Jolt over PhysX, I need to learn more about the latter!
My current focus:
designing and prototyping the jme3-jolt library
improving the Jolt-JNI documentation and sample code
