Search Issue Tracker
Fixed
Fixed in 2021.3.30f1, 2022.3.8f1, 2023.1.10f1, 2023.2.0b6, 2023.3.0a1
Votes
0
Found in
2021.3.21f1
2022.2.11f1
2023.1.0b8
2023.2.0a6
Issue ID
UUM-31316
Regression
Yes
FBX animation results in different frame keys when imported from Maya
Steps to reproduce:
1. Open the “TestFBX” project
2. Unfold the “step_key_test_0_2_4_9_13_17_Frame_ascii” FBX file to reveal the “Take 001” Animation Clip
3. Double click to open "Take 001" Animation Clip in the Animation window
4. Go to frame 17 in the Animation window and observe the value in position.Z property
Expected result: position.Z value is 1
Actual result: position.Z value is 0
Reproducible with: 2021.1.0a8, 2021.3.21f1, 2022.2.11f1, 2023.1.0b8, 2023.2.0a6
Not reproducible with: 2020.3.46f1, 2021.1.0a7
Reproduced on: macOS Monterey 12.2 (Intel)
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
- Unity crashes during the scene template selection in the "Inspector" tab
- [Android] [iOS] [UnityWebRequest] Requests with "UnityWebRequest" are open for SSL Proxying
- SetWindowsHookEx does not prevent Windows key input when Editor or Player Window is focused and Active Input Handling is set to “Input System Package (New)” or “Both”
- Crash on GetEffectiveBc7TextureCompressor() when loading and unloading all Assets in the Project
- Terrain Masks do not ignore the mipmap limit
Resolution Note (fix version 2023.3.0a1):
The FBX actually has value 0 at frame 17, the FBX contains a keyframe of value 1 just after frame 17, but at frame 17, the value is actually 0. So in the Animation Window, when the user clicks on frame 17, it's expected to see 0 on position.Z.
Issues are fixed by preventing the discarding of the keyframes if they have different values or different out tangents.