Hello JME Community !!
I have found Two new Physics Engines. One is Jolt which is faster and it is now widely used. Its the engine used in Horizon forbidden west.
Java Binding: GitHub - aecsocket/jolt-java: Java bindings for JoltPhysics
If you mean “directly as part of the core engine”… then probably around 2058… maybe 2095.
Seriously, Bullet is pretty separate from the engine. Pretty easy to tack on different physics engines. And there probably isn’t a lot of common ground for some super-API to combine them.
Hi @JavaFor3dGames. There are plenty of physics engines out there, and that’s great. I’m open to investigating new ones, but my time is finite, and it’s difficult to choose!
A non-Bullet physics engine would surely entail a new API, so existing projects would be unlikely to switch.
It would also mean replacing 10+ years worth of build scripts, supporting tools, tests, documentation, tutorials, examples, and troubleshooting/tuning expertise. Someone would have to maintain all that baggage in addition to the library itself. Not a small undertaking!
Performance is your motivation, but the GitHub repos you pointed us to don’t discuss performance. Are there measurements that compare their performance to Bullet? What workloads and platforms were used in the comparisons? Who made the measurements, using what software releases, and what was their goal?
And if Jolt and Rapier are faster than Bullet, why is that? Do they use newer algorithms? Do they make different approximations? Are they better at exploiting parallelism? Do they run on GPUs?
I was waiting for your response.
First of all thanks for your efforts for Jmonkeyengine development and its
community.
I have gone through a research paper and in that paper, there was a detailed comparison of Jolt, Nvidia physx and Bullet physics.
Jolt was faster than bullet in almost all cases and close to physx.
Rapier physics is also tested in bevy engine and also in Godot. I have tested bullet with few engines and it was slow.
But bullet is a great engine and used widely till now.
Paper link: Jolt Physics Multicore Scaling - jrouwe.nl https://jrouwe.nl/jolt/JoltPhysicsMulticoreScaling.pdf
To be honest you can use any physic lib with Java bindings, you definitely don’t need to go with bullet. I use dyn4j (might not be the fastest, but simple to use and for my 2D cases just good enough) in combination with ECS and that works fine, I can actually easily replace it bc I use ECS so it is just integrate another physic engine into an ECS system using the same components like the actual one and it is done (well probably a bit more than that as I use some in-physic-engine stuff which is outside of ECS).
Given that JMonkeyEngine doesn’t have a current roadmap, the question came across as rhetorical, if not sarcastic. Perhaps you didn’t understand the situation. Mocking of my choice of words further discouraged substantive dialog. Now you know.
JME is a mature project, at least 15 years old. While it remains open to new technology, its preference is for major additions to be developed as loosely-coupled 3rd-party add-ons (like Lemur and Minie) with their own release schedules. Due to resource constraints, add-on libraries are unlikely to get integrated into the Engine until they are stable. Hence Paul’s (sarcastic) comment about 2058 or 2095.
As Paul said, it wouldn’t be difficult to tack a new physics engine onto JMonkeyEngine. A Physx or Jolt integration would make a nice 3rd-party library; it shouldn’t require any changes to the JME core. If you cared enough, you could probably write one yourself, with the support and encouragement of this Forum. However, your original post gave the impression you were expecting someone else to do all the work. Not a great attitude to bring to an all-volunteer project!
What do you guys think
Personally, if I were to switch physics engines, it wouldn’t be for performance. It would be because Erwin Coumans (the guiding force behind Bullet) seems to have abandoned that project. There’s been very little activity in Bullet’s public repo during the last 12 months. Last I heard, Erwin had left Robotics at Google and taken a job at NVIDIA, so I don’t expect the Bullet situation to change soon.
Regarding the paper, Jorrit clearly put some care and effort into taking measurements and documenting the results. Given that, I was disappointed at how shallow their analysis was. Apparently they didn’t put much effort into understanding why the 3 engines performed so differently. For instance, no profiling results were reported. That leaves me wondering what it would take to boost Bullet’s performance to the level of Jolt and Physx on Jorrit’s test scenes.
I’m curious … what’s your best guess as to why Jolt and Physx tested so much faster than Bullet?
Was it because Jorrit used 2 scenes specifically designed to test Jolt?
Was it because the tests weren’t tuned for Bullet?
Was it because Jolt and Physx employed better algorithms? And if so, which algorithms would those be?
Something else, such as data structures, compiler technology, or static optimizations?
In recent months Godot 4 contributors tried to integrate bullet physics. But they also tried Jolt, jolt was faster and stable. So, they shifted to Jolt. They also didn’t tested bullet as your saying. Bullet is a mature engine.
I will try both and will tell you about the results. In 2024.
