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
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution enabled
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.