Hello!
This is a question not really related to BEPU v1 in its standard form, but the Fixedmath version found in:
https://github.com/sam-vdp/bepuphysics1int
Its a bit unfair to ask this here, but there's no other place to, so let me try.
We are developing a multiplayer game in which we simulate in 2 devices according to player input. We tried the deterministic version of bepu to try to avoid the hassle of creating and implementing our own fixed math physics.
But I think either we are doing something wrong or the fixed math version does not guarantee the same output under some circumstances (that we are apparently facing).
After a collision between to spheres with locked y (no vertical movement, only movement in a 2d plane by overriding y always to 0), the final output position is slightly different, and our consistency checks alert us that they are not the same.
My biggest suspect is the DeactivationManager, that does its magic in intervals and might be setting slightly different results for each client (all run in the same machine, for now). We are trying to avoid having an authority that fixes this discrepancies, so we would like them to have the same results always...
Does this make any sense? Is there something that comes to your mind that could help us? Is my assumption of the DeactivationManager all wrong?
Thanks a lot in advance!
Cheers
Bepuint and solver discrepancies
Re: Bepuint and solver discrepancies
To narrow things down, you can disable the DeactivationManager by setting the Enabled property to false.
It's hard to say what the actual issue is. The fact that they're running on the same machine rules out hardware level differences- even the floating point versions should be able to run deterministically on the same machine when properly configured. If I had to guess, there may be some interaction with the engine which does not fully obey determinism- any reordering of adds/removes/property changes relative to timesteps, for example, will break determinism. Make sure the simulation only runs on a single thread, too- many stages in v1 are not deterministic with multithreading.
It's hard to say what the actual issue is. The fact that they're running on the same machine rules out hardware level differences- even the floating point versions should be able to run deterministically on the same machine when properly configured. If I had to guess, there may be some interaction with the engine which does not fully obey determinism- any reordering of adds/removes/property changes relative to timesteps, for example, will break determinism. Make sure the simulation only runs on a single thread, too- many stages in v1 are not deterministic with multithreading.
Re: Bepuint and solver discrepancies
Hello Norbo!
Just so you know, we kind of found the source of our missmatches. It had to do with the CollisionResponseSettings.Softness value. Apparently, it was applying some modifiers to our linear velocities in a way that was inconsistent (most probably related to the TimeStep calls, but not sure about that).
As we don't have a lot of entities colliding nor interacting in each frame, we tried setting Softness to 0 and it solved most of our discrepancies so far.
Also worth saying that we were not trying to solve this particular issue when we found the Softness one. We were investigating why apparently inelastic collisions where losing energy in one axis. We tried a lot of set up values but regardless of that when a ball hit a wall and was supposed to bounce without losing energy, it did loose some only in one axis (we are using X and Z and locking Y for the physics world, only using 2 dimensions for the collisions).
Out of curiosity, why is this Softness set this way? Can you elaborate / rephrase a bit on the comment:
I don't really understand what you are implying here (probably it's me lacking some physics knowledge).
Anyway, thanks a lot for your support!
Just so you know, we kind of found the source of our missmatches. It had to do with the CollisionResponseSettings.Softness value. Apparently, it was applying some modifiers to our linear velocities in a way that was inconsistent (most probably related to the TimeStep calls, but not sure about that).
As we don't have a lot of entities colliding nor interacting in each frame, we tried setting Softness to 0 and it solved most of our discrepancies so far.
Also worth saying that we were not trying to solve this particular issue when we found the Softness one. We were investigating why apparently inelastic collisions where losing energy in one axis. We tried a lot of set up values but regardless of that when a ball hit a wall and was supposed to bounce without losing energy, it did loose some only in one axis (we are using X and Z and locking Y for the physics world, only using 2 dimensions for the collisions).
Out of curiosity, why is this Softness set this way? Can you elaborate / rephrase a bit on the comment:
Code: Select all
//If we used a single fixed softness value, then heavier objects will tend to 'squish' more than light objects.
//In the extreme case, very heavy objects could simply fall through the ground by force of gravity.
//To see why this is the case, consider that a given dt, softness, and bias factor correspond to an equivalent spring's damping and stiffness coefficients.
//Imagine trying to hang objects of different masses on the fixed-strength spring: obviously, heavier ones will pull it further down.
//To counteract this, scale the softness value based on the effective mass felt by the constraint.
//Larger effective masses should correspond to smaller softnesses so that the spring has the same positional behavior.
//Fortunately, we're already computing the necessary values: the raw, unsoftened effective mass inverse shall be used to compute the softness.
Anyway, thanks a lot for your support!
Re: Bepuint and solver discrepancies
That's odd- softness shouldn't introduce nondeterminism alone.
As for why softness is the way that it is:
1) Collision softness is, roughly, inverse damping coefficient normalized for effective mass. A raw damping coefficient would produce different behavior depending on the effective mass at the contact point, meaning changing an object's mass or inertia tensor would result in different collision behavior. Unlike constraints where the damping/stiffness can be directly and easily configured, it would be a pretty big pain in the butt to need to set material properties that work as expected across different masses.
2) The benefit of softness is stability. At zero softness, the collision constraint is fully rigid and the each constraint will not permit any error. In simple cases, this is fine, but for more complex cases the constraint graph can quickly become unsolvable within a reasonable timeframe for PGS/SI iterative solvers. When the solver terminates before reaching a global solution with high rigidity, the result is jitter or sometimes explosions. Softening constraints makes it easier for the solver to find a reasonable solution.
3) The v1 softness value can be thought of as a bit of a hacky version of what v2 ended up using- a frequency and damping ratio. Frequency/damping ratio define the behavior of a constraint across variable masses, so they don't require retuning when mass changes. Further, given a timestep duration, effective mass, frequency, and damping ratio, there is an equivalent damping coefficient and stiffness coefficient. They boil down to the same thing, one is just easier to work with.
If you want a very thorough low level explanation of frequency/damping ratio, there's an example constraint with lengthy comments in v2: https://github.com/bepu/bepuphysics2/bl ... DOF.cs#L88
As for why softness is the way that it is:
1) Collision softness is, roughly, inverse damping coefficient normalized for effective mass. A raw damping coefficient would produce different behavior depending on the effective mass at the contact point, meaning changing an object's mass or inertia tensor would result in different collision behavior. Unlike constraints where the damping/stiffness can be directly and easily configured, it would be a pretty big pain in the butt to need to set material properties that work as expected across different masses.
2) The benefit of softness is stability. At zero softness, the collision constraint is fully rigid and the each constraint will not permit any error. In simple cases, this is fine, but for more complex cases the constraint graph can quickly become unsolvable within a reasonable timeframe for PGS/SI iterative solvers. When the solver terminates before reaching a global solution with high rigidity, the result is jitter or sometimes explosions. Softening constraints makes it easier for the solver to find a reasonable solution.
3) The v1 softness value can be thought of as a bit of a hacky version of what v2 ended up using- a frequency and damping ratio. Frequency/damping ratio define the behavior of a constraint across variable masses, so they don't require retuning when mass changes. Further, given a timestep duration, effective mass, frequency, and damping ratio, there is an equivalent damping coefficient and stiffness coefficient. They boil down to the same thing, one is just easier to work with.
If you want a very thorough low level explanation of frequency/damping ratio, there's an example constraint with lengthy comments in v2: https://github.com/bepu/bepuphysics2/bl ... DOF.cs#L88