Strange and different behavior on mobile

[josemendez]

Thank you for the answer.

Adding friction helps, but very little. The Player Ball in my new game has maximum friction and is still slowing down at some point. All the other objects, which have to be frictionless, rush toward the world origin at the same rate though.

I don't think reducing the unwanted bias will help, as I'm working on a runner game and eventually I'll reach the same point in a level, where player won't be able to move forward again. And he'll be facing a hail of frictionless objects flying toward him from the end of a level.
And I'm already using Burst backend and no interpolation.

Shape matching (which is the algorithm used for softbody simulation) works by computing a rest configuration for each particle "cluster". At runtime, it tries to place the particles in such a way that they resemble the rest configuration as much as possible.

However, when particles are far away from the origin (in this case, the solver's position), the floating point numbers used to store their position lose precision. The further away they are, the larger this precision loss becomes.

Less precision means that their current shape might be calculated as being sliiiightly different from the rest shape, even though they should be exactly the same. This results in a small spurious correction to the particle's position. Since velocities are calculated trough differentiation ((current position - last position)/ deltaTime), the particle's velocity increases slightly, towards or away from the origin. Over time, if there's no friction or any other external acceleration that reduces kinetic energy, the soft body's momentum becomes increasingly large.

The more shape matching constraint iterations you use, the faster this happens. The further away from the origin the softbody is, the faster this happens. The lower friction/external forces are, the faster this happens. Mass also plays a role, since particle positions in the shape matching algorithm are weighted by their mass.

Unfortunately your game falls under pretty much all these categories: round softbodies using -I believe- 10 iterations, moving progressively further away from the origin with no friction.

So you're saying there won't be a solution in a foreseeable future?

At its core, this issue stems from the way floating point arithmetic works. Using higher-precision (doubles) would alleviate it, but wouldn't get rid of it entirely. So it's highly unlikely there will ever be a 100% solution for this. All physics engines are affected by this, to different degrees depending on the algorithms used. Generally, you want to have a "floating scene origin" that can move at runtime to re-center your objects when they get far enough from the origin:

https://docs.nvidia.com/gameworks/conten...Shift.html
Quote from PhysX's manual:

The further away objects move from the origin, the larger the chance to suffer from floating point precision issues. This can cause troubles especially in scenarios with big game worlds. To avoid these problems, a straightforward solution seems to teleport all objects towards the origin in certain intervals.

In Obi this is done by moving the solver around, as it acts as the simulation origin.

PhysX only simulates rigidbodies, so floating point precision issues are rarer (as error does not feed back into the same object like in Obi). They do take place, just further away from the world's origin.