Following up on Topic 47732, I’m working on a replacement for the Minie physics library, which was itself a replacement for both of JMonkeyEngine’s legacy physics libraries: jme3-bullet and jme3-jbullet.
The working name for the new library is “jme3-jolt”.
I believe JME will eventually need a new physics library, not because the existing ones are slow or lack features, but because they are based on Bullet Physics. As far as I know, Bullet is no longer maintained.
As the name implies, jme3-jolt will be based on Jolt Physics. Although I haven’t published any code yet, it will be an open-source project. However, I don’t foresee it becoming an official part of JME. Like Lemur and Minie, it will live in a separate repository, and its release schedule will be independent of JME.
For access to native code, jme3-jolt will use the Jolt-JNI library, which is nearly a year old and is preparing for a v2.0 release.
The difference between jme3-jolt and the KK Physics project I started last June, is that jme3-jolt won’t attempt to replicate the APIs and serialization formats of previous libraries. (Once you get away from simple rigid bodies, the physics concepts of Bullet and Jolt quickly diverge.) As a result, the cost of switching from Minie to jme3-jolt will be high. I anticipate many projects will continue to use Minie, and that’s fine.
The creation of a new API comes with an opportunity/obligation to reach out to stakeholders, establish consistent/intuitive nomenclature, and (re-)consider use cases, error handling, debugging, performance, and extensibility.
In follow-up posts, I’ll reach out and present my latest design.
Let’s start by discussing what’s good and not-so-good about the Minie API.
Minie started out as a fork of jme3-bullet, and its API grew from there. So it has 13+ years of history baked into it. I look forward to making a fresh start with jme3-jolt.
On the plus side, Minie integrates nicely into JMonkeyEngine, making effective use of basic JME concepts such as appstates, scene-graph controls, terrain, smart assets, the animation systems, and user data.
On the minus side, Minie presents an overly complicated API, exposing too much of its Bullet internals. The library sprawls across 15 packages, forcing a lot of internal-use classes and methods to be public and thus cluttering up the API. Exotic features of Bullet (such as alternative constraint solvers) were exposed in the hope they might prove useful.
I’ve heard complaints because Minie lacks simple getters for most matrix/quaternion/vector properties. This was intended to reduce garbage, but it adds complexity in contexts that expect all properties to have simple getters and setters.
A quirk of jme3-bullet’s API (that was carried forward into Minie) is that some physics controls are derived from physics objects (RigidBodyControl extends PhysicsRigidBody) while others are derived from scene-graph controls (BetterCharacterControl extends AbstractPhysicsControl). When I started out with jme3-bullet, I had to create an inheritance diagram to get everything straight in my mind.
Anyone else care to comment on what’s good/not-so-good about the Minie API?
I know you inherited this from jme3-bullet, but one of the things i’ve found problematic is that jme3-bullet and minie have the jme logic and glue code mixed together with the bindings.
When i tried to port jme to javascript, it wasn’t just a matter of rebinding the code to the javascript port of bullet, like you do eg. to implement the rendering by rewriting the jme3-lwjgl3 module, but it was a painstakingly process of going through all the jme3-bullet code and rewriting the native functions.
But i think you already resolved that since the bindings are their own library.
I think that could be solved by providing a build for WebAsm through the Emscripten tools. I guess that could be highly successful if carried out during the initial development phases of native libraries. I don’t know if it’s too late for Jolt-Jni to achieve this, but I guess @sgold could try compiling Jolt-Physics and Jolt-Jni against emc tools…
i think you’d still have to bind the wasm bindings with teavm jsobjects or something, since afaik there isn’t a jvm that builds to wasm and brings the jni with it (like a graalvm that target wasm, even though i’ve seen discussion on this regard).
jme logic and glue code mixed together with the bindings
As you point out, the Jolt-JNI bindings are a separate project from Jme3-jolt, which ought to minimize this issue.
could be solved by providing a build for WebAsm
The creator of Jolt Physics is already developing WebAssembly builds. I haven’t studied them closely, but I suspect they’re what you want for your Javascript port.
And while I won’t discourage use of Jolt JNI with engines other than JMonkeyEngine (Minecraft, LibGDX, Ardor 3D, Java 3D, DimensioneX, …) or with languages other than Java (Kotlin, Groovy, Clojure, GraalJS, …) I’ve got my hands full just dealing with JME and Java.