godot-jolt VS Bullet

Some other Rust game engines ship with their own physics engine. Fyrox, for example, has advanced 2D/3D physics, supporting rigid bodies, joints, ray casting and more. Godot too, which has community-led Rust bindings also has an in-built physics engine as well as a Godot-native extension using the Jolt physics engine. In fact, which is reported to be more performant than the official physics engine.

When the performance of Godot's physics engine has been mentioned before I've seen https://github.com/godot-jolt/godot-jolt pointed to as a drop in more performant solution.

Haven't tried it in a project yet myself

No idea if this will solve your problems, but with Godot 4 Physics being a bit undercooked you might want to try a different physics engine. Like Godot-Jolt: https://github.com/godot-jolt/godot-jolt

Godot 4 itself is actually fairly good about diving to its C/C++ base for the nasty stuff. Like its Physics. The reimplementation for Jolt physics into Godot 4 is again C/C++ calculation library.

If you'd like to try out Godot Jolt for yourself, you can find the latest release, as well as important gotchas, on the project's GitHub page. Just bear in mind that the extension is still in development and will likely have a couple of bugs that have yet to be found. C# support for GDExtension is also not in a great place right now, so there are some issues there as well.

Try a different physics engine: https://github.com/godot-jolt/godot-jolt

Your comment made me do a bit of research and I found this: https://github.com/godot-jolt/godot-jolt

It's possible to create a GDExtension for it (similar to what was done for Jolt), but I haven't seen any for Bullet yet. There's a lot of hype going around Jolt, so it's understandably where most of the community effort is going :)

Or godot-jolt (linked in that Tweeter thread respones).

For typical game physics engines... not that much. Math libraries like Eigen or Blaze use lots of template metaprogramming techniques under the hood that can help when you're doing large batched matrix multiplications (since it can remove temporary allocations at compile-time and can also fuse operations efficiently, as well as applying various SIMD optimizations), but it doesn't really help when you need lots of small operations (with mat3 / mat4 / vec3 / quat / etc.). Typical game physics engines tend to use iterative algorithms for their solvers (Gauss-Seidel, PBD, etc...) instead of batched "matrix"-oriented ones, so you'll get less benefits out of Eigen / Blaze compared to what you typically see in deep learning / scientific computing workloads.

The codebases I've seen in many game physics engines seem to all roll their own math libraries for these stuff, or even just use SIMD (SSE / AVX) intrinsics directly. Examples: PhysX (https://github.com/NVIDIA-Omniverse/PhysX), Box2D (https://github.com/erincatto/box2d), Bullet (https://github.com/bulletphysics/bullet3)...

I suspect most C++ physics libraries like Box2D (https://github.com/erincatto/box2d) or Bullet3 (https://github.com/bulletphysics/bullet3) could really benefit a lot from SIMD.

No, they replaced Bullet with Jolt. That is considerably more than "some adjustment", regardless of what you think of the result.

Vulkan graphics via Intel GVK, and physics via Bullet

The first two have a bunch of great examples, and I’m tying them together by refactoring some of the THREE examples to fit the ECS paradigm defined in AFrame. then upping the ante by adding physics using AMMO, which is more challenging since it’s only a partial implementation of Bullet, and already poorly documented (yet popular) physics engine.

Plus, SM uses a system called bullet physics, I imagine this would be rather complex to rework into a modern engine such as Unreal or Unity (after all, the majority of performance issues come from the physics engine rather than the graphics engine)

The physics in HDT-SMP are actually being calculated outside of Skyrim's engine with Bullet, an open-source physics engine. So this isn't some limitation of Skyrim's engine.