Help particles have inconsistent weight on solver with high substeps

[locque]

I made a lab scale which is supposed to weigh fluid in a container, which worked really well up until I had to raise the solver substeps in my project to 8 to get viscous fluids to behave properly. Now suddenly all particles weigh only about a fourth of what they did on 1 substep, and also vary in their weight by a factor of at least 2 depending on how you pour them into the container and how long you wait after that. Sometimes the fluid even lifts the container up so much that it lifts itself up and the filled container actually weighs less than the empty one.
I can compensate for a weight reduction, but I can't work around the inconsistency. Is there anything that can be done to mitigate it?

[josemendez]

I made a lab scale which is supposed to weigh fluid in a container, which worked really well up until I had to raise the solver substeps in my project to 8 to get viscous fluids to behave properly. Now suddenly all particles weigh only about a fourth of what they did on 1 substep, and also vary in their weight by a factor of at least 2 depending on how you pour them into the container and how long you wait after that. Sometimes the fluid even lifts the container up so much that it lifts itself up and the filled container actually weighs less than the empty one.
I can compensate for a weight reduction, but I can't work around the inconsistency. Is there anything that can be done to mitigate it?

Hi,

How are you weighting the particles? keep in mind that using more substeps decreases the simulations effective timestep, so if you're factoring the timestep in your weight calculations you will need to account for the number of substeps.

Also, all forces involving rigidbodies will be affected by using substeps, since substepping updates the fluid solver more often than the rigidbody solver (which uses Unity's global timestep). The only way to get them both to agree regarding the forces "seen" by each other is to update them in sync: if you're using 8 substeps, use 1 substep and a fixed timestep that's 8 times smaller instead.

[locque]

How are you weighting the particles? keep in mind that using more substeps decreases the simulations effective timestep, so if you're factoring the timestep in your weight calculations you will need to account for the number of substeps.

It's basically how a real scale would work, the plate of the scale is locked on the y axis and propped up by spring joint. The script takes the local y position of the plate when turning it on as a baseline and then tracks the the height differential to that point.

Also, all forces involving rigidbodies will be affected by using substeps, since substepping updates the fluid solver more often than the rigidbody solver (which uses Unity's global timestep). The only way to get them both to agree regarding the forces "seen" by each other is to update them in sync: if you're using 8 substeps, use 1 substep and a fixed timestep that's 8 times smaller instead.

That doesn't seem to be the way it works, decreasing the fixed timestep has almost no effect on the fluid behaviour compared to raising the solver substeps.

I can get proper viscuous fluids at 10 substeps and only the default fixed timestep 0f .02, but using 1 substep and .002 behaves pretty much exactly the same as if it was on .02. Even putting it on the lowest Unity will allow it to go at .0001 will still make no perceptible difference to .02 on 1 substep.

[josemendez]

It's basically how a real scale would work, the plate of the scale is locked on the y axis and propped up by spring joint. The script takes the local y position of the plate when turning it on as a baseline and then tracks the the height differential to that point.

This assumes an infinitely small timestep, which is true in the real world (since time is continuous) but not at all in a simulation, where time is discrete. Every simulation step, position is integrated from velocity, and velocity from acceleration.The accuracy of the integration is affected by the timestep length, being better the smaller the timestep is.

The following graph shows the trajectory of an object integrated using Euler's method (a variant of which is the most widely used one in realtime physics engines): As you can see, the simulated trajectory significantly diverges from the real one over time:


If you were to measure the mass of the object using its position at time T (assuming a given impulse at T=0), you'd underestimate it. By chopping up time into smaller chunks, you'd get a piecewise linear approximation that's closer to the real thing.

By using positional deltas to measure weight instead of forces/impulses you're measuring the approximation of an approximation, the quality of which depends on the timestep length used. To make things worse constraint corrections aren't instantly propagated, so the more objects you add on top of your scale, the less precise it will be.

The usual way to implement a scale in a game is to measure contact impulses between the scale plate and the object(s) being weighted, convert these to forces (dividing by the timestep) and then divide by gravitational acceleration to get mass. Imho you should try this, this is what I assumed you were doing in the first place and why I asked if you were using the full timestep length or the substep length to perform this calculation.

That doesn't seem to be the way it works, decreasing the fixed timestep has almost no effect on the fluid behaviour compared to raising the solver substeps.

This is the expected behavior:
A) Using a timestep of X and 8 substeps yields an effective timestep length of X/8.
B) Using a timestep of X/8 seconds and 1 substep yields an effective timestep length of X/8/1 = X/8.

As you see, the timestep used by the fluid simulation is the exact same in both cases, so the behavior of the fluid should be pretty much identical in A) and B). Any differences are due to collision detection being performed only once per full step, and reusing the results over all substeps.

However, in case A) the timestep used by Unity's physics engine is X but the one used by Obi is eight times smaller. In case B, both engines use a timestep of X/8, which increases the accuracy of Unity's physics simulation as well.

The reason why I suggested to try B) is to improve your weighting scale precision by using a smaller timestep for Unity's simulation, while keeping identical fluid behavior.