I have spent the last couple of days looking for a 3D physics engine that plays nicely with MonoGame.
To save you some time, these are my results so far.
BepuPhysics
There are two versions, 1.1 seems like it may work with MonoGame, but it looks very slow for collision checking.
1.2 I cannot get to compile. Looks like it uses a new C# spec that is only available with pro versions of Visual Studio.
Henge3D
This was written for XNA and sadly uses a custom content processor to add physics variables to meshes. I tried working around that to make it more useful, but a simple cube kills performance. Spheres are fine you can have millions of them. In the end though I decided it was more trouble than it is worth.
Bullet
I went through BulletSharp, couldn’t get it to compile. However I found BulletXNA which someone wrote some time ago.
This also was written in a very strange way, though the class library itself looks ok. I have ported it to MonoGame and reworked all the demos so you can run them from a single windows app.
At the moment this looks the favorite for my use, though I am pretty sure there is a memory leak in it somewhere.
Anyway, to save you time if you are in the same position as I am, I have published the code on my website.
summoned bepuguy here:
v2 does indeed require C# 7.3, but the free VS Community supports it. It just requires version 15.7 or higher.
A bigger concern is runtime support- it uses numerics JIT intrinsics for performance, so any runtime that doesn’t support them will be an order of magnitude slower. RyuJIT handles it just fine, but I haven’t looked into the state of the mono runtime lately.
(And while v1 certainly is slow relative to v2, I dunno if I’d call it slow in absolute terms )
V1 will be incredibly slow when you start having more than a 1000 collidable objects in the world. I have even seen demos which prove that. I am not saying that is terminal for it, it is possible to add code to speed up the collision detection, it’s just that I wouldn’t start with a physics engine knowing I had to do that work.
I have many versions of visual studio installed, v2 will not compile on any of them. My 2017 is only version 15.0 , so that matches what you expect to happen.
I will be interested to see what you end up doing with it. Will you have time to see if you can drop it into MonoGame again and provide some analytics ?
[quote=“StainlessTobii, post:3, topic:11065”]
V1 will be incredibly slow when you start having more than a 1000 collidable objects in the world. I have even seen demos which prove that.[/quote]
There may be shenanigans afoot- that doesn’t sound like expected behavior unless running on an old phone or something. On a 3770K in v1 with multithreading enabled and default settings, 1000 active dynamic boxes arranged in a big wall should take about 4-7ms per frame. 4096 characters running around on a world composed of 1600 static instanced meshes should take about 15-17ms per frame. Do you see wildly different numbers on comparable hardware?
[quote=“StainlessTobii, post:3, topic:11065”]
I will be interested to see what you end up doing with it. Will you have time to see if you can drop it into MonoGame again and provide some analytics ?[/quote]
I won’t be making a monogame specific version of the demos, but I will probably look into the mono runtime in more detail in the next few months if it has re-enabled the vector JIT intrinsics since I last tried.
Just to avoid possible confusion, v1 and the native version of Bullet tend to have pretty similar performance. If one works, most likely the other will too. A pure collision detection simulation of 1000 boxes will be a whole lot cheaper than a very dense solver heavy simulation.
(Sorry for dragging this off topic, I’ll quit bugging you now )
)