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
- Objects receive a black outline in Ray Traced Screen Space Reflections
- NullReferenceException Occurs When Baking APV with GPU Streaming Enabled
- Scene renders incorrectly when using RenderGraphUtils.AddCopyPass
- [URP] Searchable context menu instantly closes when attempting to open it
- [Multiplayer Center] Hosting Model Doesn't Reset to Recommended When Re-selecting Default Netcode Solution
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.