Related to Alternative ways to fix the performance there’s actually a decision to make on what physics engine Thrive should use.
Anyone have any recent experiences? I’ve used Newton Dynamics and Bullet before. Right now Bullet is used through Godot.
The choices I think we could make are:
Out of these the least surprising and safest choice would be to use Bullet, but using something else might have benefits for the future. For example chrono might have more advanced physics simulation features that bullet doesn’t have. And Jolt might have a lot better performance and features related to allowing multithreaded operations to further optimize things. However Jolt currently doesn’t have softbody physics (not that despite years of talking about it no one has made any effort to add this to Thrive). Quickly looking it seems that in Bullet also softbody physics are a different feature from rigid body simulation.
So anyone have any experiences / thoughts on what to use?
I actually can’t find a direct speed comparison between them. While jolt seems a good choice, I don’t think we can get away without soft bodies, so that’s out.
Chrono: Highly accurate, More features, Often but not always slower than bullet.
Bullet: Used before, fast, easy
Well unless Bullet documentation has become a lot more comprehensive in the past few years, it is not actually that easy to use. The only reason why I’d pick it is that I’ve done it before so I can just use it based on the class reference, but using the non-python version of Bullet was not fun to figure out how it works. I actually can’t fully believe how bad their documentation was (it’s been a few years since I’ve used) compared to how big and popular the project is.
I just looked at it, ouch. That’s really bad.
Yeah, it’s more of a joke really. They have super well hidden the info on how to get started with C++. It’s in an old manual pdf file that has outdated info but the getting started part + the class reference allowed me to get things working.
Jolt may get soft body physics, but similarly to Bullet it seems it’ll be like a different feature set than rigid body (which actually seems to be quite common now that I look into it, it is probably for performance reasons that softbody features are distinct from rigid bodies):
Chrono may have more integrated softbody simulations, but their description is so technical math term ridden that I can’t tell.
One more physics engine I’ve used and know about is Newton:
Which is a bit surprising to me to see it still being updated and maintained. Even that had so much better getting started tutorials than Bullet that it is like a joke how bad the more popular library is in terms of documentation. The reason I stopped using that was that there was a really serious bug in that physics system that took like months for the library developer to eventually fix (it was months and months after I had rewritten everything in Bullet after experiencing problems for a long time). But the experience of using that library was pretty good when not running into any bugs. So that could kind of also be an option.
I started looking into it, and I think I dismissed Jolt too quickly. I really quite like it. The lack of soft body physics is the biggest detractor, but like you said thrive currently doesn’t have any (Though it really should), so that’s not an immediate problem. Jolt seems fast and stable, and the docs don’t make me want to die. (Room for improvement, but I think even I a relative c++ noob could get something working.)
This might be a nice reference to look at if you so choose to use jolt: GitHub - godot-jolt/godot-jolt: Godot Jolt – Godot extension that integrates the Jolt physics engine
It also has c# bindings.
Just a slight problem with the Jolt C# bindings:
Cross platform modern .netstandard2.0, .netstandard2.1, .net6.0 and .net7.0 bindings for JoltPhysics.
Which we might not be able to use as Godot 3.x C# is only net472 level support.
I’ve been kind of coming to the conclusion that probably the best way to use any physics engine is to write a small C++ native code wrapper around it which exposes just the exact stuff we need to C# to make swapping physics easier. Also the same module could have a bunch of performance intensive code eventually moved to it. What I’m not sure about is if that module would be worth it to try to make as a Godot module (Godot 4 has much different extension interface). Or maybe two libraries? One with the core C++ code and another native library that then is a Godot extension. Though how those are loaded and referenced from C# might be a bit tricky in that case.
Edit: the jolt developer said on one of their Youtube videos a month ago:
So I think jolt might be the most promising option. At least it seems to have pretty good trajectory right now.