Search Issue Tracker
Won't Fix
Votes
2
Found in
2020.3.40f1
2021.3.11f1
2022.1.20f1
2022.2.0b10
2023.1.0a14
Issue ID
UUM-16397
Regression
No
Animator stops working when running for a long time
How to reproduce:
1. Open the attached project "animator_long_running.zip" and load Scene "main"
2. Enter Play Mode
3. Press the right arrow key on your keyboard
4. Wait for a couple of days (2 - 5) to pass in the game (top left of the Game View)
5. Press the down arrow key on your keyboard
6. Observe the animations in the Game View
Expected result: All animations are running the same way
Actual result: The middle cube and the right sprite are slowed down/completely stopped
Reproducible with: 2020.3.40f1, 2021.3.11f1, 2022.1.20f1, 2022.2.0b10, 2023.1.0a14
Notes:
- Interactions within the Editor can force the stopped animations to update a couple of frames (for example, opening a context menu, or moving the Editor windows around)
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
- Missing Render Feature "Full Screen Pass Render Feature" in any “Universal Renderer Data” asset when upgrading from 2022.3
- Inconsistent ParticleSystemVertexStream.PercentageAlongTrail data range in Trail Texture Modes except "Stretch"
- The Graph Debug Window can be right clicked through and the Node Workspace is manipulated instead
- [Linux] Top left corner of the screen is unresponsive when the Editor recompiles
- [Android] [Vulkan] Cubes stuck on the first few frames of rotation and application flickering when an Overlay Camera is added to the Camera Stack with MSAA enabled
Resolution Note:
After evaluating the impact, workaround and risk associated with fixing this issue, in addition to the current team's bandwidth and priorities, we have concluded that this issue will not be addressed in the foreseeable future.
We are closing this issue as Won’t Fix.
If you feel this issue does not have an acceptable workaround or that you are still blocked by this issue and strongly feel like this should be addressed, reply to this notification to re-open the issue and explain why this is the case. Or, simply log a new bug if the context (version, repro steps) has changed since the original bug report.
Workaround #1: If Root Motion is not required/being used (which seems to be the case here), the user can disable Apply Root Motion to avoid this issue completely.
Workaround #2: If workaround #1 is not possible, user can reset the state normalize time to a range between 0-1. This will also resolve the issue.