PGS: Gravity has large precision error during simulation

[Darkmist101 (Darkmist)]

GravityOffsetRepro.rbxl

When using basic equations of motion it’s expected that you would get near accurate results compared to simulating in Roblox. Of course, we should expect a small error that shouldn’t be impactful on a small scale; this is not the case. The following output displays the results from dropping a part with gravity set to 1000 for ~3 seconds.

Spring Solver:
Actual Y: -4487.51171875
Expected Y: -4487.5002998815
Difference: -0.011418868496548
Precision Error: 3.8115869238115e-06

PGS Solver:
Actual Y: -4543.853515625
Expected Y: -4537.5689315842
Difference: -6.2845840407535
Precision Error: 0.0020861710895411

Actual Y is the where the part ended up.
Expected Y is where it was calculated to end up.
Precision Error is the difference/(gravity*time) or (different/gravity)

The tests are obviously over-the-top, but now we can substitute a gravity number we actually use (32.174)

Spring Solver:
Actual Y: -144.783203125
Expected Y: -144.78272288717
Difference: -0.00048023782730411
Precision Error: 4.9754282804296e-06

PGS Solver:
Actual Y: -146.59851074219
Expected Y: -146.39586527024
Difference: -0.20264547195092
Precision Error: 0.0020878773042806

The precision errors are both constant for each solver, though PGS is constantly poor. If you’re working with higher gravity or longer simulation times the difference between what you calculate (and expect) vs what is simulated is far less accurate in PGS.

In the above example is the conditions we need to work. A 0.2 stud offset in a low gravity and small simulation time can make it hard to work with PGS. For now we’ve accounted for the percision error by adding a larger offset to accomplish what we want to do, but it adds some unnessecary complications. It feels wrong that over such a small simulation, we have to account for such a large error.

[chefdeletat]

Your calculation is correct and is as expected due to a different frequency that the PGS solver integrates the rigid body motion. The legacy solver integrates at a very high frequency of 4000hz where PGS uses 240hz simulation steps.

In fact your measurment of the error is amazingly accurate: assuming g = 1000, for PGS the theoretical error should be -6.25.

Unfortunately not much can be done (except trying to hack a fix for that specific case of free falling body). This is the nature of iterative solvers. The PGS is better at handling constraints at the expense of being less accurate with integration.

Edit: I’ll look into possible solutions.

[tyzone]

This is a very late reply, but I’d like to offer that piece of information for anyone who encounters the same issue and stumbles upon this thread.

This error can be quantified accurately, and even compensated for in specific scenarios if you so choose. @GFink, @GloriedRage and I have worked on a forum post to try and explain the cause of the offset, as well as how to calculate and compensate for it. You can find it here!