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.