bepu
Thread-safety
Hello!
First of all, thank you for the library! It is really nice to find something like this performing so well in the .Net space!
We've been using PhysX 5 with a C# binding for a while but it natively doesn't support concurrent readers/writers which is a problem for us since the server is built on top a distributed system (Microsoft Orleans). PhysX require us to either use their native locks or to do lock and synchronization at the C# side which is a big performance hit which causes a lot of CPU contention.
So, we are evaluating other options for physics libraries for our server. We don't have very strict requirements besides kinematics and rigid bodies since the game in development is a (unannounced) MMO and hence why I've stumbled here when I found a Reddit post mentioning this library being as fast as PhysX and Jolt.
My question for you is: I understand that you have some support for scheduling the simulation tasks on multiple threads but, what about the methods that read and write from the simulation? Are they thread-safe? In our scenario the server operates in a distributed system as mentioned, where each entity essentially run in its own thread. Those entities will query a lot the state of itself and others on the simulation and may also update itself (i.e. character movement) on the simulation. The current approach is to "queue" all those updates and have a pump-loop on a single thread that acquires a write lock for PhysX in order to write and that write lock also lock all the reads essentially using a ReadWriteLock.
So, is Bebu behaving similar to PhysX where we need to manage those locks or is it multithread friendly as Jolt?
Again, thank you!
Looking forward to hear from you!
Jolt uses a lot of locks internally and was setup this way to deal with legacy game code that was not designed for multithreading.
I suggest an ECS approach to your game update as a sequence of systems rather than running entities on separate threads. You likely have lots of other locks as entities read/write each other. ECS largely solves this problem (but not completely).
Thanks for the reply. The server is custom tech built from scratch in .Net. ECS AFAIK only works on Unity itself on either client and server.
Regarding Jolt locks, yes, I read their docs and their locks, unlike PhysX, are per entity. So if I want to modify an entity (i.e. update its position) we acquire a lock on the Body object itself, not the whole simulation. That already saves a lot of contention since in our case, the entity on our distributed system, is the only one which can update its state (including physics).
Anyone can implement an ECS. It is not complex, it just means thinking carefully about your update loop. https://gdcvault.com/play/1024001/-Overwatch-Gameplay-Architecture-and
Ah ok. I thought you were referring to Unity's implementation. Got it.
To make some context explicit:
what about the methods that read and write from the simulation? Are they thread-safe?
A rule of thumb is, if a feature would introduce non-optional overhead for core use cases that don't need the feature, then it probably doesn't exist. Body properties, for example, are exposed as direct memory references.
The API tries to be minimal with the assumption that things like synchronization can be optionally added in an external layer.
