Silk.NET VS Bullet

A couple other options than what has been suggested so far: - TerraFX.Interop.Windows. Raw, blittable, 1:1 bindings for all Win32, D2D/D3D11/D3D12 APIs (there's also a version with Vulkan bindings). As close to doing #include as you can get in C#. This is my personal favorite, I use it in my own ComputeSharp library, and transitively we use it in the Microsoft Store too 🙂 - Silk.NET another version of high-performance bindings, more opinionated than TerraFX and with some additional helpers to make it a bit easier to use.

Here is an example of using "releases" in GitHub: https://github.com/dotnet/Silk.NET/releases. Most repositories use releases and releases seem like they wpuld be appropriate for your repository too.

I've been looking at this. Is this similar to the UrhoSharp project you talk about? https://github.com/dotnet/Silk.NET

Have you looked at Silk.NET before?

Take a look at https://github.com/dotnet/Silk.NET . You should be able to use your existing rendering context with it. So you could use something like imgui (They have bindings for that) to render your UI. Or if you just start writing your rendering code, you could consider writing the whole rendering engine with it. I used it in the past for a game engine and performance is no problem for most of the usecases.

If you want something more ".NET like", check out Silk.NET instead. It's also community maintained and in the .NET Foundation, but does name remappings, friendly API overloads, and other things that make it feel more ".NET like": https://github.com/dotnet/Silk.NET

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.