Using bepu v2 in Unity

[Telliax]

Hi. Long story short, I am currently working on a multiplayer Unity game, and I am hesitant to use built-in Unity physics because it will likely force me to use Unity on servers as well - a situation I would rather avoid. So I am looking for alternative physics engines, compatible with both Unity and .Net Core. Bepuphysics2 is one of the possible options. I have been playing around with Bepu2 for a couple of days now, and I think I am ready to ask a few questions:

1. I have been able to build unity client (with bepu physics inside) for android quite easily with mono back-end and Net Standard 2.0 compatibility. IL2CPP build doesn't seem to work "out of the box", but I haven't looked too much into it yet. So the question is, are there any known pitfalls when it comes to using bepu2 inside a Unity build, compatibility-wise? Is this a common use case, or is it largely untested by the community? I haven't been able to find much info about compatibility in the docs or on these forums.

2. My main use case for physics does not involve using a solver. Basically all I have is a static scene and a bunch of kinematic bodies which I move around manually every frame. When the scene is set up I do a lot of raycast/overlap queries, and that's it. I then repeat the process the next frame. Any recommendation on how to best utilize bepu in this case? I've been basically following the RaycastDemo, except I do not call Solve or Timestep methods. Is that the correct approach?

3. A quick performance test (~400 raycasts against a scene with ~50 static boxes), shows that in release build Bepu2 is about 10 times slower than Unity's default physics when it comes to raycasting. Does that sound about right? Have this been measured before? I am aware that Unity does not provide a hardware acceleration for numerics, but I do not know how much of a difference this makes in terms of performance.

4. Unity provides an API for "shape-overlap" (returns every body which collides with given shape description, e.g. a sphere, placed in given position) and "shape-cast" (returns every body which collides with given shape description, e.g. a sphere, if this shape is moved from given position a given distance in given direction). But I seem to struggle to find an equivalent methods in bepu2 API. It has "sweep" methods, which look similar. But it is not clear, whether "sweeping" is equivalent to "casting". Or whether "sweeping" with zero velocity is equivalent to "overlapping". So any pointers here are welcome.

5. Unity has an utility that can batch static bodies into a single mesh in runtime. Is something similar goes on inside bepu2, or is it something that I would have to write myself? Would it give any noticeable benefits?

[RossNordby]

So the question is, are there any known pitfalls when it comes to using bepu2 inside a Unity build, compatibility-wise?

Unfortunately, yes. I do not personally test unity builds so I'm going by scattered reports from users, but historically there have been major compatibility issues. It runs on most of the unity runtimes now, as far as I'm aware, but does still have some extreme performance pitfalls. I think the most recent previews may have updated mono JIT paths which will work somewhat better, but still much slower than CoreCLR. Depending on the runtime and features in question, expect somewhere between 3x and 4000x slower.

Notably, they are moving in the right direction, so hopefully this will no longer be an issue at some point: https://forum.unity.com/threads/unity-future-net-development-status.1092205/

A quick performance test (~400 raycasts against a scene with ~50 static boxes), shows that in release build Bepu2 is about 10 times slower than Unity's default physics when it comes to raycasting. Does that sound about right? Have this been measured before? I am aware that Unity does not provide a hardware acceleration for numerics, but I do not know how much of a difference this makes in terms of performance.

That does not sound like expected or reasonable performance. It appears it's still taking a massive hit under that runtime compared to CoreCLR.

The rest of this will pretend that there's no massive performance issues for informational purposes:

My main use case for physics does not involve using a solver. Basically all I have is a static scene and a bunch of kinematic bodies which I move around manually every frame. When the scene is set up I do a lot of raycast/overlap queries, and that's it. I then repeat the process the next frame. Any recommendation on how to best utilize bepu in this case? I've been basically following the RaycastDemo, except I do not call Solve or Timestep methods. Is that the correct approach?

In order to ensure reasonable query performance over time, the broad phase structures need to be incrementally updated. A custom ITimestepper that doesn't call the solver or other unnecessary stages could help here (for an example, check out https://github.com/bepu/bepuphysics2/blob/master/BepuPhysics/PositionLastTimestepper.cs).

Given that you're not using most of the logic in the physics engine anyway, you could also technically drop down a level. The Tree and CollisionBatcher could be used directly without any wrapping Simulation. Not sure you'd actually want to do this, since they are lower level interfaces and more annoying to use, but it would be possible. The CollisionQueryDemo shows a starting point for how to use the CollisionBatcher.

Unity provides an API for "shape-overlap" (returns every body which collides with given shape description, e.g. a sphere, placed in given position) and "shape-cast" (returns every body which collides with given shape description, e.g. a sphere, if this shape is moved from given position a given distance in given direction). But I seem to struggle to find an equivalent methods in bepu2 API. It has "sweep" methods, which look similar. But it is not clear, whether "sweeping" is equivalent to "casting". Or whether "sweeping" with zero velocity is equivalent to "overlapping". So any pointers here are welcome.

The sweep methods are similar to a shape cast that allows angular motion. (Note that these have historically had massive performance problems under unity- three order of magnitude slowdowns have been observed. I assume it's not quite that bad anymore, but watch out.)

Sweeping with zero velocity could be similar to overlapping if you don't want a full contact manifold result. If you've got a bunch of overlap tests to run and you want contact data, it'll be quite a bit faster to run them through the CollisionBatcher together. (Or it would be, given numerics acceleration.)

Unity has an utility that can batch static bodies into a single mesh in runtime. Is something similar goes on inside bepu2, or is it something that I would have to write myself? Would it give any noticeable benefits?

I'm not familiar with the utility, but it doesn't sound like there's an exact analog to it. My expectation is that there would be no reason for it unless you're dealing with >> 100000 static objects. (And later on, once I finally get around to a couple of simple things I've been intending to do for a long time, it'll become almost entirely pointless.)

[Telliax]

Thank you for taking the time to write a detailed response, it helped a lot!

[nockawa]

@Telliax bepuv2 relies on .net core and its SIMD based types (Vector<T>, etc) in order to be very fast.
On the other hand, Unity doesn't want to rely on the .net CLR for the compilation of the player. So you have Mono for the editor and IL2CPP for the player.
IL2CPP doesn't compile the SIMD based types of .net with the SIMD intrinsics which leads to very very poor performances. Overall, all the things that bepuv2 relies on to be very fast are poorly supported by mono/IL2CPP, which is why this lib doesn't get along very well with Unity.
Unity keeps going their way, ignoring the .net ecosystem, because most of the leader don't like it, the only things they are using from .net is C# and Mono. I could go on and on for hours on this topic as I've worked 2 years on the DOTS team...

[Telliax]

Thanks! I can feel your pain :)

[onehundredfeet]

Thanks for the info. It is exceedingly frustrating that we can’t use agnostic libraries like Bepu with Unity. For what seems like very shallow reasons.

…

On Aug 25, 2021, at 12:15 PM, Loïc Baumann ***@***.***> wrote: @Telliax <https://github.com/Telliax> bepuv2 relies on .net core and its SIMD based types (Vector<T>, etc) in order to be very fast. On the other hand, Unity doesn't want to rely on the .net CLR for the compilation of the player. So you have Mono for the editor and IL2CPP for the player. IL2CPP doesn't compile the SIMD based types of .net with the SIMD intrinsics which leads to very very poor performances. Overall, all the things that bepuv2 relies on to be very fast are poorly supported by mono/IL2CPP, which is why this lib doesn't get along very well with Unity. Unity keeps going their way, ignoring the .net ecosystem, because most of the leader don't like it, the only things they are using from .net is C# and Mono. I could go on and on for hours on this topic as I've worked 2 years on the DOTS team... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#147 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABA3VTKRHCUTJCLNW34QX6DT6U6LTANCNFSM5CZGZ7GQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>.

[nockawa]

Thanks for the info. It is exceedingly frustrating that we can’t use agnostic libraries like Bepu with Unity. For what seems like very shallow reasons.

Unity is not .net, and there is no plan of any kind for this to improve over time. That's what people have to understand, and they have to understand that Unity doesn't care at all about the .net ecosystem (to be polite).

C# came out initially in Unity for scripting purpose, where perf was not as critical as doing something like a physics engine or a general purpose 3D engine.
Now Unity succeeded to mix C# with their own tech for things like HDRP or the DOTS Physics engine (written by Havok), Burst is doing a fine job when you write C# code with the mindset of being compiled with it. But the only way to get good perf with C# in Unity is to write highly specialized code that has absolutely nothing similar to C#/.net.

Thanks! I can feel your pain :)

Well, indeed. I thought (and still think) that Unity would have been better if they accepted (5 years ago) the offer from Microsoft to collaborate with them and improve .net core to build their future tech stack.
There are plans to replace mono by .net 6 in the editor, but it's not a small task and the team in charge is made of really good guys but they have a lot on their plate and Unity is not pushing for this to be a priority. Part of the reason is because this won't improve the final products (player compiled games, which are all using IL2CPP).

I feel bad for Unity users who expect from Unity to be closer to the .net ecosystem.

[Frooxius]

This is something I ended up chasing myself and I managed to figure out a pretty big cause of the slowdown - the System.Numerics.Vectors library. The JIT doesn't produce vectorized code so there's some slowdown from that, but it's actually much worse than that.

The C# implementation of the library internally uses patterns like (T)(object)(float) and (float)(object)(T) (where T is float here for example) to convert generic type to specific one and back. It seems that the version of JIT used in Unity doesn't understand this pattern as T being the same type, so it doesn't optimize the boxing and unboxing away.

This ends up in every single vector operation constantly boxing and unboxing data - sometimes multiple times per operation. I've had a simple operation where just calculating a convex hull for a set of points with BEPUv2 would end up allocating 50 MB of RAM as a result, while being horrendously slow (14.5 seconds in my test).

To deal with this, I ended up making a patcher script that replaces all the boxing and unboxing with pointer reinterpreting to avoid those allocations. I've put up the script here, it requires Mono Cecil: https://gist.github.com/Frooxius/c3e1a181376a3b97bea53e7efd16f992

After patching the library the operations are actually significantly faster (went down to around 0.5 seconds for the same convex hull) and don't generate a whole bunch of allocations for the GC to deal with.

You still won't get best performance in Unity just because the JIT codegen is relatively poor and the library isn't vectorized, but at least it's not as bad.

Unity's also updating the Mono from 5.11.0 on to 6.13.0 on the latest beta, which seems to actually optimize the pattern above and the patcher might not be needed, but I haven't tested it's impact of it on BEPUv2 yet, although I want to soon(ish).

With our project we're working towards moving away from Unity completely, so we can switch over to .NET 5 (or 6 probably by the time we do it), since the Mono and the GC embedded in Unity is a big limiting factor for pretty much rest of our project as well - the performance improvements even in the first .NET Core versions are too great and the .NET 5 and 6 just end up pushing that even further, but these changes help bridge the gap in the meanwhile (plus our headless server runs completely outside of Unity with any .NET runtime), hopefully they'll help you as well!

[Telliax]

That's good to know, thanks!
As I understand it, you are running bepu with mono backend. Did you have any luck running it with IL2CPP?

[Frooxius]

I haven't tried it with IL2CPP yet unfortunately so I can't say, sorry!

It's a little bit too brittle with our project, it's hard to get it to compile in the first place (tends to generate invalid C++ code, which we need to wait on Unity to fix or figure out what to change to make it go through which is usually very time consuming), but I'd like to give it a try again sometime in the future. I'll probably be trying the new Mono first.