I Compared Jmonkeyengine 3.6 with Godot 4.2

[JavaFor3dGames]

@sgold

report the measured range of boxes at 30 FPS (2790 to 2831) over 3 separate runs. 2800 boxes seems to me like a plausible baseline for physics performance (though of course I wish it were higher).

I have re-created the project from scratch and Now I’m getting 2700 Cubes with setmaxSteps(1);
That project may had a problem. Now I’m getting good performance. 3000 Cubes @ 20 FPS

[sgold]

@Simon_Brooke

I ran the performance monitor, and noted that when slowdown occurred the process was saturating one processor core, while the remaining three were lightly loaded. This implies the physics engine is not parallelising its operations at all.
[…]
So clearly a physics engine which did parallelise better could do better. As you can see from the screenshot, I’m currently using the jbullet physics engine. @sgold, does Minie parallelise better?

jme3-jbullet limits apps to one thread per physics space. By default, jme3-jbullet simulates physics on the render/update thread, but there’s an option (BulletAppState.ThreadingType.PARALLEL) to simulate physics on a separate thread.
For the option to have much performance benefit, each thread would have to fully utilize a CPU. For most apps, the headaches of ensuring thread safety outweigh the performance benefits.

Minie also offers the ThreadingType.PARALLEL option, with similar caveats. But it also provides a multi-threaded library that allows multiple worker threads per physics space. The two kinds of multi-threading can be used separately or combined.

Minie’s default library (“8.1.0”) is one thread per physics space. The multi-threaded library flavor (“8.1.0+mt”) implements multiple worker threads per physics space, but only for Linux and Windows—no macOS or Android. The number of worker threads per space is limited to 2.

Back in 2021, I ran some performance measurements and profiling of multi-threaded Minie. For the workload and systems I studied, there was no performance gain beyond 2 worker threads. I suspected a memory-bandwidth bottleneck:

Multithreading Minie

My August project is to add multithreaded physics spaces to Minie. Currently, I’m stuck. This post provides background. My next post will be status report and a plea for help/advice. As the complexity of a Minie physics simulation increases, it tends to become CPU-bound. Modern computers provide multiple CPU threads, allowing software threads (lightweight processes) to execute multiple tasks in parallel. The Bullet software that underlies Minie already includes code to exploit task-level parall…

I’d welcome further investigations of multi-threaded Minie.

[Simon_Brooke]

OK, I’ve forked your github repo, and I’m not seeing a 8.1.0+mt tag. Could you document what I need to do to enable the multi-threading? I’d certainly be very happy to look at this, but it’s ten years since I last wrote Java for a living.

One of the things Jolt does (see their presentation) is do a fast single threaded pass over all the objects in play to very roughly check which ones might be in collision with which others, thus dividing the potentially colliding objects into spatial groups, and then do a second pass with one thread per spatial group to do the detail check (if I understand correctly, they also don’t block the rendering thread during the first pass).

I think in Bullet terminology this would be creating one PhysicsSpace for each spatial group? Are PhysicsSpace objects lightweight, in the sense that one could create them on the fly during the physics loop?

My own prejudice, coming from a pure functional background, would be that if you took a pure functional approach to this you would get parallelism essentially for free and additionally wouldn’t need to interrupt the rendering thread at all except momentarily once each pass through the loop to swap in the pointer to the newly computed data.

However,

1. Writing a whole new physics engine is a big deal, and
2. A pure functional style inevitably generates a lot more garbage, so there is a performance penalty in garbage collection.

So it seems (probably) better use of time to make best use of the physics engines other people have already written!

[sgold]

@Simon_Brooke

Continuing on from this discussion, there’s Java bindings project wrapping Jolt

I’m wondering whether it would be interesting and good learning to try to build bridge code to allow jMonkeyEngine projects to be switched relatively easily to use Jolt. Obviously this depends a lot on how similar the Jolt API is to the Bullet API, which I haven’t yet investigated.

Today I studied jolt-java. It’s a good start, but a long way from what I would like:

• There are no published releases.
• There have been no commits to the public repo since April 2023, while Jolt continues to evolve.
• According to the README file, single-body constraints, characters, vehicles, and ragdolls are all unfinished.

On the other hand, after sketching the skeletons of 4 Java classes (BulletAppState, PhysicsSpace, RigidBodyControl, and BoxCollisionShape) I was able to run the “fountain of boxes” test in JMonkeyEngine v3.6.1, and the performance seemed excellent. In fact, I can’t report the maximum number of boxes because I grew bored waiting for the FPS to fall below 30!

I’ve decided it’s worth spending some effort toward integrating Jolt Physics into JMonkeyEngine. I don’t think it will ever be a drop-in replacement for jme3-jbullet or Minie, but if the performance differential is big enough, many developers will make the switch.

I’ve forked jolt-java from GitHub - aecsocket/jolt-java: Java bindings for JoltPhysics and will continue working with it unless someone finds me a better JVM library for Jolt Physics.

OK, I’ve forked your github repo, and I’m not seeing a 8.1.0+mt tag. Could you document what I need to do to enable the multi-threading?

There’s no need for you to build Minie from source. Pre-built JARs and other artifacts can be downloaded from GitHub and MavenCentral.

But if you insist, here is the build procedure for “8.1.0+mt” artifacts:

1. Install a JDK, set “JAVA_HOME”, and clone the source code per the “standard build” instructions.
2. Run the Gradle wrapper with the “-Pmt” option:

• using Bash or Fish or PowerShell or Zsh: ./gradlew build -Pmt
• using Windows Command Prompt: .\gradlew build -Pmt

[Simon_Brooke]

Thanks for all this. The reason I’d prefer to build from source is I want to get a deeper understanding of how all this works, and be able to dig about and explore ways to improve performance.

In general, are the four classes you mention the core of what is needed to integrate a new physics engine into JMonkeyEngine?

[sgold]

I want to get a deeper understanding of how all this works, and be able to dig about and explore ways to improve performance.

Sure. For instance, it might be possible to tack a better broadphase accelerator onto Bullet.

In general, are the four classes you mention the core of what is needed to integrate a new physics engine into JMonkeyEngine?

No! Four classes are sufficient to run this particular app. To run all the physics apps in jme3-examples (as Minie does) will require dozens more.

I hope to have a new physics library worth sharing in about a week. It will doubtless have major limitations. Right now I’m thinking about what to call it.

UPDATE: For those who are curious, development of the new library is taking place in a public repository at GitHub:

GitHub - stephengold/kk-physics: Integrate Jolt Physics into jMonkeyEngine...

• In my mind, “KK” is an initialism for King Kong.
• I released verison 0.1.0 of jolt-java to GitHub and Maven Central.

More concerns regarding jolt-java:

• Currently it only builds Linux natives, so it doesn’t support Android, macOS, or Windows platforms.
• It uses preview features of JDK 19, so it doesn’t work with any other version of Java. In particular, it doesn’t work with any LTS version of Java. I imagine this would also prevent it from being used with Clojure, Groovy, or Kotlin.
• Due to my ignorance of many tools it uses, I’m finding it difficult to modify.

I’ll see how far I can get with jolt-java. If sufficiently motivated, I might eventually write new Java bindings for Jolt Physics.

[sgold]

Discussion of KK Physics can take place here.