I'm just putting this here for maybe future use and save somebody the effort. It's mostly about unlocking C# 7.x in Unity but maybe we can add more info as it becomes relevant. Bepu v2 uses the latest C# 7.3 features, and though Unity has some C# 7.x features, they are not enabled by default. V2 wont work in Unity without substantial changes(aka removing C# new features, like replacing all 'in' argument modifiers with 'ref' perhaps) but that is way beyond the scope of this post.

Then place the following script titled CsProjFixer.cs in an Editor folder, you should now already have UnityVS/Editor folder. It must be in a folder titled Editor or it wont work, the VS tools are editor only tools.

The team at Unity is now working with the Roslyn team to adopt the Roslyn C# compiler in Unity. Because Roslyn is a larger compiler, it is a slower compiler to startup, and Unity does many small incremental compilations. So the team is working towards adopting the server compilation mode of Roslyn. This runs the Roslyn C# compiler as a reusable service which can compile code very quickly, without having to pay the price for startup every time.

I'm not sure how far along that work is, but that would hopefully resolve all the language issues.

(SIMD intrinsics related codegen, on the other hand, is still a question mark as far as I know.)

I did the following and added System.Runtime.CompilerServices.Unsafe.dlls to the project.
I got rid of all the errors that Unity was giving me - however when I try to run it Unity crashes. (It's wip naturally)

I thought I should probably ask has anyone actually got v2 working on Unity before spending too much time on it? I would love to use Bepu for networked physics,

I'm not sure if anyone has managed it with v2 yet. If you want to try a smaller scale test, you may want to check if the System.Numerics.Vectors types work well yet. It may still be a little tricky- there might be configuration options you'd have to fiddle with to enable the relevant supporting runtimes, if they exist at all.

Getting that to work is a necessary prerequisite to getting v2 to work anyway, so it's a good starting point. I suspect it will run, but I wouldn't be surprised if it still doesn't output optimized results for the System.Numerics.Vectors types (in particular Vector<T>). It might even output assembly significantly worse than naively doing the same computations in a scalar fashion. In other words, without a compiler able to handle those types, performance will tank by an order of magnitude (or two) and there isn't much point in using v2 compared to v1 or another physics engine.

(Still got my fingers crossed that this will become a nonissue at some point!)

Xenko is a C# MIT licensed game-engine which might be able to accept Bepu2 now. (github)

Because it's written in C#, it runs atop a standard .NET runtime, not a specific embedded one like Unity. While they use C# 7.0, they also target .NET 4.7.2, which I believe has everything Bepu2 requires.

Obviously this is not as exciting as Unity, because it doesn't have a huge number of users. However, it's also completely open source, and could be experimented with now, rather than at some unknown future time when Unity supports the required .NET features for Bepu2.

Yup, xenko's a pretty interesting potential use case- I've been intending to poke into their discord and offer help to anyone interested in undertaking an integration. (I probably shouldn't try to do it myself- my todo list already approximates eternity.)

So It's actually pretty easy to get Bepu 2 working in Unity (2019+) now. However as Norbo already showed there is a breaking bug with Unity's JIT compiler, and Bepu 2 is very slow in Unity. So if you're making a game that doesn't have Box-Box collisions and can fiddle around until Unity fixes compiler problem, then it might be worth it to give Bepu 2 + Unity a shot!

Get System.Runtime.CompilerServices.Unsafe.dll into your project with nuget and copy the dll into Asset folder
Then copy BepuPhysics and BepuUtilities (.dll or source file folders) into Asset folder.
Thats it!

Awesome! I harangued some unity users I know into trying it- looks like the performance might have improved some too. From what I heard, Vector.IsHardwareAccelerated is still false so there is still a pretty big performance gap between the unity runtime and coreclr, but that's definitely progress in the right direction.