Search Issue Tracker
Fixed
Fixed in 2022.3.70f1, 6000.3.1f1, 6000.4.0b2, 6000.5.0a3
Won't Fix in 6000.2.X
Votes
1
Found in
2021.3.40f1
2022.3.36f1
6000.0.10f1
6000.1.0a7
6000.2.0a1
6000.3.0a1
6000.4.0a1
6000.5.0a1
Issue ID
UUM-75577
Regression
No
Velocity is set to NaN when using Mathf.SmoothDamp
Reproduction steps:
1. Open the attached “BugRepro” project
2. Open the “Assets/Scenes/SampleScene.unity” Scene
3. Enter the Play Mode
4. Observe the Console window
Expected result: Velocity is a valid float value
Actual result: Velocity is NaN
Reproducible with: 2021.3.40f1, 2022.3.36f1, 6000.0.10f1
Reproducible on: Windows 11
Not reproducible on: No other environment tested
Comments (1)
-
RoyTheunissen
Mar 14, 2025 16:47
I've also reproduced this issue in 2022.3.26f1, I use `SmoothDamp` in various places in the game and there is also pause functionality that sets `Time.timeScale` to 0.
I've never before noticed NaN to occur as a result of `SmoothDamp` but today I paused/unpaused the game in rapid succession and suddenly found various unrelated `SmoothDamp` calls in the game causing NaN propagation at unpredictable times (unpredicable but it very consistently does so if you pause and unpause in rapid succession for a few seconds).
This related ticket seems to have been set to Won't Fix but I don't think that's acceptable: https://issuetracker.unity3d.com/issues/mathf-dot-smoothdampangle-sets-currentvelocity-to-nan-when-time-dot-timescale-is-set-to-0-and-target-is-close-in-value-to-current
Every game that uses `SmoothDamp` and also has a pause feature (which is probably every game that isn't multiplayer-only) runs the risk of this issue happening.
If this is indeed expected behaviour and you want users to be more careful when using `SmoothDamp`, that is fine, but then the `SmoothDamp` documentation needs to be updated to say so. As a user you can reasonably expect `SmoothDamp` to just return the input value if `Time.timeScale` is 0, like it seems to do correctly *most* of the time.
As a user, I would expect `SmoothDamp` to internally check for invalid intervals and just not modify the input value in that case. Quaternion similarly checks for invalid conditions and even logs to the console if you use it incorrectly, `SmoothDamp` is such a core feature of the engine that I would argue that it deserves the same level of caution.
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
- Invalid Clip Method
- WebGPU error with Fantasy Kingdom and GPU Resident Drawer
- WebGPU fails with height fog in Fantasy Kingdom
- Crash on UndoManager::RegisterUndoInternal when applying added GameObjects to a Prefab
- [Asset Bundles] A new bundle hash is not generated when the name of a serialized field is changed
Resolution Note (fix version 6000.5.0a3):
Fix verified with: 6000.5.0a3
Resolution Note (fix version 6000.4.0b2):
Passing a 0 detaTime into Mathf.SmoothDamp would cause a returned velocity of NaN (0 distance / 0 time). The returned velocity has been changed to pass back the same velocity that was passed in to the function.
Resolution Note (fix version 6000.3.1f1):
Passing a 0 detaTime into Mathf.SmoothDamp would cause a returned velocity of NaN (0 distance / 0 time). The returned velocity has been changed to pass back the same velocity that was passed in to the function.
Resolution Note (6000.2.X):
6000.2 is no longer being supported
Resolution Note (fix version 2022.3.70f1):
Passing a 0 detaTime into Mathf.SmoothDamp would cause a returned velocity of NaN (0 distance / 0 time). The returned velocity has been changed to pass back the same velocity that was passed in to the function.