Search Issue Tracker
By Design
Votes
1
Found in
2019.3.0a9
2020.1
2020.2
2020.2.0b1
Issue ID
1275167
Regression
No
ConfigurableJoint accuracy is reported to degrade quick as the distance to origin is increased with the TGS solver
How to reproduce:
1. Open user-submitted project (Temporal Gauss Seidel Bug.zip)
2. Open the SampleScene
3. Enter Play Mode
4. Press the 'Up Arrow' key and observe the drawer
Expected result: the drawer keeps moving as long as it has velocity
Actual result: the drawer stops in place while still having velocity
Reproducible with: 2019.3.0a9, 2019.4.11f1, 2020.1.6f1, 2020.2.0b3
Could not test with: 2018.4.27f1, 2019.3.0a8(Temporal Gauss Seidel solver not yet implemented)
Notes:
Not reproducible with Projected Gauss Seidel solver
Moving the 'Table Locker' GameObject closer to origin(e.g. 0,0,0) does not cause this issue
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [macOS] forward and backward mouse buttons are recognized as middle mouse button
- NavMeshModifier.OnEnable/OnDisable gets progressively slower when called repeatedly
- "System.Net.CookieContainer" throws an "ArgumentException" error when using a non-UTF-8 machine locale and hostname
- Crash on ModelImporter::ImportSkinnedMesh when disabling "Strip Bones" on a specific FBX model
- WebGL Development builds ignore the "Compression Format" setting when using "Gzip" compression
Resolution Note:
Background info:
TGS works by splitting the fixedDeltaTime into n smaller steps and solving them once vs PGS using 1 time step and n solver iterations. The actual individual TGS timestep is equal to Δt / n (where Δt = fixedDeltaTime and n = solverIterations).
In this issue, the object that is far away from origin is supposed to move slowly but in reality doesn't move at all. This happens because in this project Δt is small and n is large which results in a lot of very small sub-steps for the TGS solver. Given a large object position, small velocity, and only 32 bits to store floats: position + Δposition == position.
E.g. 140.91771 + 2.642e-6 = 140.91771 (this can be tested in an IEEE 754 float calculator)
This is a small drawback of the TGS solver that is in the core idea of it. There is nothing that can be fixed about this apart from moving to 64bit doubles.