BepuPhysics1 Performance

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
jonas
Posts: 1
Joined: Tue Apr 23, 2019 6:30 pm

BepuPhysics1 Performance

Post by jonas »

I'm developing a fighting game 1vs1 in realtime, I'm using unity3d and bepuphysics1.

I don't have many colliders (all boxes and spheres), just the walls, some hitboxes and some hurtboxes. The scenerio is pretty simple but still the space update, or updating the colliders positions takes too much time, the logic of the game runs multiple times per frame because of the network support.

I'm thinking on getting rid of the space and checking the collisions manually, something like, is player 1 colliding with player 2, are they colliding against the walls, is any player1's hitboxes hitting any player2's hurtboxes, is this possible?

Do you have any suggestion to improve the performance in this scenerio?

I already tried splitting the colliders in multiple spaces, I have one for movement with walls, floor and 2 player colliders. And another for attacking, a couple hitboxes and hurtboxes for each player. I add and remove colliders depending on wether they are active or not, I think this option was more performant than leaving the colliders and ignoring the collision, or updating the collision rules.

I'm also using collision gorups to setup which colliders collide.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: BepuPhysics1 Performance

Post by Norbo »

While there are some tricks that can be used to improve performance, this doesn't sound like a case where I'd expect even v1 to struggle in the slightest, so I'd recommend first ruling out other issues.

As a sanity test, on a 3770K in v1 you should expect performance like:
1) 400 active dynamic boxes stacked up in a wall: ~1.3ms (a bit more initially due to the greater solving requirements).
2) 192 objects falling into a complex environment defined by a large StaticGroup: ~0.7ms
3) 24 active ragdolls: ~1ms
These are with multithreading on, but multithreading doesn't help much for such tiny simulations. In fact, for very small simulations, I'd recommend disabling multithreading since the tiny cost of launching the jobs would overwhelm the cost of the actual work.

Are you seeing performance remotely consistent with this? If not, there may be some environmental issue that needs to be addressed.
Post Reply