I have a strange problem. I have two blueprints with particle mass 0.3 for red balls and 1 for the blue ones. When I start the game in unity, all the balls fall on the floor and stay there. When I launch the same build on Android, suddenly all the balls start rolling towards -z. The bigger the mass, the faster. Here's the video: https://youtu.be/f1ALZPc1Kfg
01-03-2021, 09:59 AM (This post was last modified: 01-03-2021, 11:04 AM by josemendez.)
Hi there,
Initial tests show that there's several things at play that cause this:
- Floating point precision in certain Android devices is lower, this causes a slight bias in shape matching constraints that adds a constant "push" to softbodies. The push is larger the further away they're from the world origin (0,0,0). Mass also affects the magnitude of this push, larger mass values result in smaller inverse mass which exacerbate this lack of precision.
- The particle distribution in your spheres is not radially symmetric on all axis, so the bias direction is towards the world's origin + a slight offset towards regions with more particle density.
- Both your bodies' and your floor's friction is set to zero. This results in no opposition to softbody movement at all, so any accelerations affect the body indefinitely.
I could reduce this unwanted bias by using the Burst backend (floating point precision seems slightly better that in the native backend), tweaking mass values and using the built-in "medium friction" collision material in your floor. Let me know if this improves the situation for you.
Unfortunately the root cause of this (lack of floating point precision) is not easily solvable, the only possible solution is switching all calculations from floats to doubles, which isn't feasible at this moment.
On a side note, you're using 10 iterations for all constraints, which isn't needed at all. Most constraints (all except shape matching) will do fine with just 1 iteration, as there aren't complex collision or frictional effects in your scene. This will improve performance noticeably.
04-03-2021, 09:22 PM (This post was last modified: 04-03-2021, 09:32 PM by the-lander.
Edit Reason: added info
)
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.
So you're saying there won't be a solution in a foreseeable future?
05-03-2021, 10:09 AM (This post was last modified: 05-03-2021, 10:16 AM by josemendez.)
(04-03-2021, 09:22 PM)the-lander Wrote: 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.
(04-03-2021, 09:22 PM)the-lander Wrote: 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:
Quote: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.
I'm using 1-3 iterations and still the result is bad. Frictionless objects just move to the origin. Adding them friction needs to be compensated with adding more friction or mass to other objects so they'd act the same, which brings another problems.
I don't think moving solver's origin will help as the problems appear at any point of space.
05-03-2021, 12:21 PM (This post was last modified: 05-03-2021, 12:35 PM by josemendez.)
(05-03-2021, 12:13 PM)the-lander Wrote: I'm using 1-3 iterations and still the result is bad. Frictionless objects just move to the origin. Adding them friction needs to be compensated with adding more friction or mass to other objects so they'd act the same, which brings another problems.
I don't think moving solver's origin will help as the problems appear at any point of space.
It looks like this extension is not usable on mobile as the problems are so visible and they show up so early.
Hi,
You're not actually using Burst as you don't have the required dependencies installed, so it will fall back to Oni (see the warning message in the solver's inspector). Make sure your objects are as close to the origin as possible.
If at any point you need a refund for this reason, just let me know your invoice number.
05-03-2021, 01:41 PM (This post was last modified: 05-03-2021, 01:44 PM by josemendez.)
These are the results I get using the default backend (Burst) in an android phone (Xiaomi A2 Lite). As you can see, floating point error falls below the sleep threshold, so softbodies don't drift at all:
I'm using the default settings in your project, didn't change anything. Just downloaded, built and deployed the project using Burst.
The constraint settings are cranked way too high for mobile though (10 iterations in all constraint types) so it runs considerably slow. Some constraints such as contact/friction need as little as 1, no need to enforce them ten times per frame. Shape matching will do good with 2-3.
