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
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
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.