FBX Import - Armatures are incorrect #53620

New Issue

Gatis Kurzemnieks · 2017-12-23T18:25:32+01:00

Gatis Kurzemnieks commented

2017-12-23 18:25:32 +01:00

This has been there for a very long time. Whenever importing FBX with skeleton/armature from other apps, many times It's completely screwed - bones are rotated in wrong directions and rotations are wrong. Looks like coordinate systems are not converted correctly.

In this case - perfectly normal skeleton from Maya (From actual project where it is used in production in Maya, Unity, Motion builder etc).

Blender: All versions
OS: All OS

tereza_skel.fbx

This has been there for a very long time. Whenever importing FBX with skeleton/armature from other apps, many times It's completely screwed - bones are rotated in wrong directions and rotations are wrong. Looks like coordinate systems are not converted correctly. In this case - perfectly normal skeleton from Maya (From actual project where it is used in production in Maya, Unity, Motion builder etc). Blender: All versions OS: All OS ![maya_to_blender_bug.jpg](https://archive.blender.org/developer/F1505031/maya_to_blender_bug.jpg) [tereza_skel.fbx](https://archive.blender.org/developer/F1505034/tereza_skel.fbx)

Gatis Kurzemnieks commented

2017-12-23 18:25:32 +01:00

Added subscriber: @GatisKurzemnieks

blender-admin commented

2017-12-23 18:25:32 +01:00

#72386 was marked as duplicate of this issue

blender-admin commented

2017-12-23 18:25:32 +01:00

#68495 was marked as duplicate of this issue

blender-admin commented

2017-12-23 18:25:32 +01:00

#53821 was marked as duplicate of this issue

Philipp Oeser commented

2018-01-02 21:34:41 +01:00

Added subscribers: @mont29, @lichtwerk

Philipp Oeser commented

2018-01-02 21:34:41 +01:00

While I cant very the file in another program atm (could do tomorrow) I can confirm the output in blender looks unexpected [tried a couple of settings with no luck]
Hate to ask, but @mont29, could you have a look?

While I cant very the file in another program atm (could do tomorrow) I can confirm the output in blender looks unexpected [tried a couple of settings with no luck] Hate to ask, but @mont29, could you have a look?

Bastien Montagne was assigned by Philipp Oeser

2018-01-02 21:37:58 +01:00

Philipp Oeser commented

2018-01-04 10:20:07 +01:00

can confirm that provided file reads just fine into Maya or Unity

Bastien Montagne commented

2018-01-08 16:32:05 +01:00

Using Force Connect Children and Automatic Bone Orientation will help. Besides that, yes, upper part of the skeleton is weird, no idea why. Probably some issue in Pose/bind matrices somehow, armature model of FBX is so complicated…

Using `Force Connect Children` and `Automatic Bone Orientation` will help. Besides that, yes, upper part of the skeleton is weird, no idea why. Probably some issue in Pose/bind matrices somehow, armature model of FBX is so complicated…

Bastien Montagne commented

2019-01-24 18:06:07 +01:00

Added subscriber: @Joe_W

Eugene commented

2019-06-10 11:33:24 +02:00

Added subscriber: @SergienkoEugene

ghoulish commented

2019-07-23 02:26:26 +02:00

Added subscriber: @Ghoulish

ghoulish commented

2019-07-23 02:34:35 +02:00

I'm experiencing this issue with the importer (100% of FBX armatures I import fail to import correctly).

After spending a while looking into it, what appears to be happening is the importer is ignoring (or not successfully using) the PreRotation and PostRotation properties from the FBX LimbNodes to give the bones in Blender the rotation they're supposed to have. When the bones are getting created by the importer, the bones are successfully given proper lengths however the bones aren't getting rotated at all so that the bone tails actually wind up where they're supposed to. I'm not 100% sure about this, but from the reading of the python code I've put in I believe somewhere in the following line the rotation information using the PreRotation and PostRotation info is either not being considered or not being correctly applied:

from line 1931 of import_fbx.py
"# And rotate/move it to its final "rest pose".
bone_matrix = parent_matrix @ self.get_bind_matrix().normalized()"

I'm experiencing this issue with the importer (100% of FBX armatures I import fail to import correctly). After spending a while looking into it, what appears to be happening is the importer is ignoring (or not successfully using) the PreRotation and PostRotation properties from the FBX LimbNodes to give the bones in Blender the rotation they're supposed to have. When the bones are getting created by the importer, the bones are successfully given proper lengths however the bones aren't getting rotated at all so that the bone tails actually wind up where they're supposed to. I'm not 100% sure about this, but from the reading of the python code I've put in I believe somewhere in the following line the rotation information using the PreRotation and PostRotation info is either not being considered or not being correctly applied: from line 1931 of import_fbx.py "# And rotate/move it to its final "rest pose". bone_matrix = parent_matrix @ self.get_bind_matrix().normalized()"

stephen leger commented

2019-07-23 13:43:57 +02:00

Added subscriber: @StephenLeger

stephen leger commented

2019-07-23 13:43:57 +02:00

Looks like at least math behind pre-rotation is wrong.
PreRotation should be something like this
parent_matrix @ rotation_matrix @ parent_matrix.inverted()

Looks like at least math behind pre-rotation is wrong. PreRotation should be something like this parent_matrix @ rotation_matrix @ parent_matrix.inverted()

Bastien Montagne commented

2019-07-23 14:14:51 +02:00

wait , what? Are you telling me that those f***ing pre transform matrices need to be inter-mingled with parenting??? In other words, we are supposed to 'cancel' the parent transform for those?

So that would give something like (to get final bind matrix) parent_matrix @ pre_matrix @ parent_matrix.inverted() @ bind_matrix @ post_matrix (which should then be normalized and post-multiplied again with parent_matrix)???

I ô so hate FBX transformations model… :(((

wait , what? Are you telling me that those f***ing pre transform matrices need to be inter-mingled with parenting??? In other words, we are supposed to 'cancel' the parent transform for those? So that would give something like (to get final bind matrix) `parent_matrix @ pre_matrix @ parent_matrix.inverted() @ bind_matrix @ post_matrix` (which should then be normalized and post-multiplied again with `parent_matrix`)??? I ô so hate FBX transformations model… :(((

stephen leger commented

2019-07-23 18:33:40 +02:00

Either apply the "pre rotation" first - assuming bone is transform free when we apply, or cancel any transform before, "pre"-rotate and re-apply transform after.

Bastien Montagne commented

2019-07-23 19:46:14 +02:00

Current code does parent_matrix @ ((pre_matrix @ bind_matrix) @ post_matrix).normalized()… So that should be correct, right (iirc, order matters, but not associativity, in matrix multiplication…)?

Current code does `parent_matrix @ ((pre_matrix @ bind_matrix) @ post_matrix).normalized()`… So that should be correct, right (iirc, order matters, but not associativity, in matrix multiplication…)?

stephen leger commented

2019-07-23 20:09:42 +02:00

As far as i can understand the pre-rotation concept, it is not as the rotation must apply before any other transform (around 0,0,0).

So assuming object is at 0,0,0 before, should more be like this.
parent_matrix @ (post_matrix @ bind_matrix @ pre_matrix).normalized()

If it is not the case (any translation exist) you must cancel translation and re-apply after pre-rotation.

As far as i can understand the pre-rotation concept, it is not as the rotation must apply before any other transform (around 0,0,0). So assuming object is at 0,0,0 before, should more be like this. parent_matrix @ (post_matrix @ bind_matrix @ pre_matrix).normalized() If it is not the case (any translation exist) you must cancel translation and re-apply after pre-rotation.

Bastien Montagne removed their assignment 2019-08-12 16:03:51 +02:00

Bastien Montagne commented

2019-08-20 10:26:09 +02:00

Added subscriber: @Bater

Bater Janjatah commented

2019-08-20 10:38:48 +02:00

Yes I have the same issue when importing stuff from Unreal Engine to Blender 2.7X and 2.8
Importing FBX from Unreal Engine to Blender results in distorted bones and wrong IK bones locations and orientation even when connecting to children.
I can also confirm that creating an IK in blender and then exporting it to fbx then importing again will show different results than the originals

Yes I have the same issue when importing stuff from Unreal Engine to Blender 2.7X and 2.8 Importing FBX from Unreal Engine to Blender results in distorted bones and wrong IK bones locations and orientation even when connecting to children. I can also confirm that creating an IK in blender and then exporting it to fbx then importing again will show different results than the originals

Tom Weber commented

2020-05-18 02:21:28 +02:00

Added subscriber: @tw2020

Eittipat commented

2020-05-21 14:57:05 +02:00

Added subscriber: @Eittipat

Stanislav Baranov commented

2020-09-11 21:56:31 +02:00

Added subscriber: @sbaranov

GM commented

2021-01-14 23:16:44 +01:00

Added subscriber: @Mentales

Chris Schubert commented

2021-03-13 13:34:51 +01:00

Added subscriber: @cschubert25

Chris Schubert commented

2021-03-13 13:34:51 +01:00

In case anyone else is stuck by this issue:

I had many FBX files with armatures/animations and many were not rotated correclty when using FBX import. None of the import settings helped, and I tried every combination of bone alignment. The armatures would appear fine in rest pose, but playing animations would distort everything horribly. No amount of manual bone-roll alignment seemed to help.

What did work for me:
Converting the FBX files to glTF, and then importing glTF. The armatures imported correctly and the animations played correctly.

The magic to resolve this issue is either somewhere in the FBX > glTF conversion, or in the glTF importer itself. However, if FBX support is not a priority, maybe a simple hack could be an intermediate conversion during FBX import to glTF, which then proceeds with glTF import.

Anyway, for anyone looking for a manual workaround, here's the github for the converter. You run it via command line but it is very simple to use, and there is good documentation.
FBX to glTF: https://github.com/facebookincubator/FBX2glTF
Documentation: https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials/#convert-from-fbx

In case anyone else is stuck by this issue: I had many FBX files with armatures/animations and many were not rotated correclty when using FBX import. None of the import settings helped, and I tried every combination of bone alignment. The armatures would appear fine in rest pose, but playing animations would distort everything horribly. No amount of manual bone-roll alignment seemed to help. What did work for me: Converting the FBX files to glTF, and then importing glTF. The armatures imported correctly and the animations played correctly. The magic to resolve this issue is either somewhere in the FBX > glTF conversion, or in the glTF importer itself. However, if FBX support is not a priority, maybe a simple hack could be an intermediate conversion during FBX import to glTF, which then proceeds with glTF import. Anyway, for anyone looking for a manual workaround, here's the github for the converter. You run it via command line but it is very simple to use, and there is good documentation. FBX to glTF: https://github.com/facebookincubator/FBX2glTF Documentation: https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials/#convert-from-fbx

Jerome Humbert commented

2021-04-03 23:15:36 +02:00

Added subscriber: @djee

David Jeske commented

2021-09-26 06:01:34 +02:00

Added subscriber: @DavidJeske

David Jeske commented

2021-09-26 06:01:34 +02:00

I've investigated and I think I've uncovered the cause of some FBX armature problems as it relates to game engine import/export.

In order to round trip skeletons and animations to game engines, the skeleton bone (joint) rotations need to remain consistent. However the Blender FBX Import automatic bone orientation and force connect children options alter the bone (joint) rotations, effectively altering the skeleton, and so animations built with an imported skeleton no longer match the basis skeleton when pushed back into game engines via Blender FBX Export. (sometimes game engine animation retargetting can fix this, sometimes)

The workaround is to standardize on a Blender compatible +Y bone skeleton.

The fix is for Blender to somehow preserve the original bone orientation through FBX import/export. (more detail below)

Background

I believe (based on what I can find and deduce) a Maya/FBX bone is always displayed connecting two bone joints. In other words, the Maya visual of the bone segment is not dependent on the bone/joint local axis orientation or bone scaling in any way. It's basically just an arrow pointing to a child joint.

Blender always displays bone segments towards the +Y local bone axis.

The pictures below are the default unreal engine mannequin loaded in Maya 2020. I don't see anything in the ASCII FBX file indicating a bone display orientation. In the first image you can see one bone pointing generally towards +x and the other generally towards -x. However, the display bone does not need to point towards any bone axis. In the second picture you can see a bone that doesn't point towards any bone axis at all... The bone is just pointing to the child joint. Joints with no children are shown as a circle with no bone.

Maya also supports adjusting bone axis in "Orient Joint Options" dialog, though I'm not sure what effect this has on the bone.

Maya Joint Orientation in a Minute - YouTube

The Blender FBX import Automatic Bone Orientation and Force Connect Children options sort-of do what Maya does, but the problem is that it throws away the transformation it performs, which effectively creates a new skeleton. Then, when you export an animation based on this skeleton, it does not match the original FBX imported skeleton anymore.

Because each FBX bone can point in a different direction, there is no single uniform swapping of bone orientations on import/export that will ever work for FBX armatures which have different orientations on different bones. For example, the default UE4 skeleton orients left-leg bones towards -X, and right-leg bones towards +X. As a result, using Blender FBX Import "primary bone axis" can fix the left leg OR the right leg, but never both at the same time.

This pic below shows a UE4 mannequin skeleton imported into blender without any bone adjustment. You can see the bone X axis points up on one leg and down on the other. Without any bone correction, the animations work fine in blender and export fine back to UE4, but this rig isn't very convenient to use, as the bones are not oriented in the model.

Ideas about how to fix this problem...

(1) have the FBX importer save the correction_matrix that "automatic bone orientation" computes, and save it in custom property per bone. Then. during FBX export of that armature or animations, that matrix would be inverted to correct the bone orientations back to the way they were in the source FBX file. (and it would be convenient to have a small property UI and widget to display the FBX bone local axis, which will not match the Blender bone local axis)

(2) extend Blender's bone display code to have an additional "bone display rotation", which would rotate the visible bone handle without affecting the underlying bone axis. An additional toggle "always orient bone towards child pivot" could orient the bone display towards the child bone, matching Maya's behavior. Leaf bones could be automatically oriented during import, similar to the current "automatic bone orientation"

Pros and Cons:

(1) is likely to be easier to implement and experiment with. It has the drawback that any thing driven off the Blender bone local axis will not match the FBX local axis, but anything like this is unlikely to export into game engines anyway (a primary target of this fbx import/export process).

(2) and/or (3) are probably unnecessary... as the way blender handles bones works just fine

Workaround until then...

Until there is a solution which makes Blender able to preserve FBX bone orientations through import/export in a useful way.. the solution to get import/export interop between Blender and FBX based tools is to standardize on a rig where all bones match the Blender orientation... such as by building a rig in blender and standardizing on that rig. This is the approach the Blender Uefy addon for Unreal Engine takes. Alternatively, one can build a blender-centric +Y bone skeleton for getting animations into Unreal/UE and then retarget them to another skeleton with their animation retargeting tools.

I've investigated and I think I've uncovered the cause of some FBX armature problems as it relates to game engine import/export. In order to round trip skeletons and animations to game engines, the skeleton bone (joint) rotations need to remain consistent. However the Blender FBX Import `automatic bone orientation` and `force connect children` options alter the bone (joint) rotations, effectively altering the skeleton, and so animations built with an imported skeleton no longer match the basis skeleton when pushed back into game engines via Blender FBX Export. (sometimes game engine animation retargetting can fix this, sometimes) The workaround is to standardize on a Blender compatible +Y bone skeleton. The fix is for Blender to somehow preserve the original bone orientation through FBX import/export. (more detail below) **Background** I believe (based on what I can find and deduce) **a Maya/FBX bone is always displayed connecting two bone joints**. In other words, the Maya visual of the bone segment is not dependent on the bone/joint local axis orientation or bone scaling in any way. It's basically just an arrow pointing to a child joint. Blender always displays bone segments towards the +Y local bone axis. The pictures below are the default unreal engine mannequin loaded in Maya 2020. I don't see anything in the ASCII FBX file indicating a bone display orientation. In the first image you can see one bone pointing generally towards +x and the other generally towards -x. However, the display bone does not need to point towards any bone axis. In the second picture you can see a bone that doesn't point towards any bone axis at all... The bone is just pointing to the child joint. Joints with no children are shown as a circle with no bone. ![image.png](https://archive.blender.org/developer/F11138611/image.png) ![image.png](https://archive.blender.org/developer/F11138631/image.png) Maya also supports adjusting bone axis in "Orient Joint Options" dialog, though I'm not sure what effect this has on the bone. ![image.png](https://archive.blender.org/developer/F10600699/image.png) [Maya Joint Orientation in a Minute - YouTube](https://www.youtube.com/watch?v=hECwVEaXDyY) The Blender FBX import `Automatic Bone Orientation` and `Force Connect Children` options sort-of do what Maya does, but the problem is that it throws away the transformation it performs, which effectively creates a new skeleton. Then, when you export an animation based on this skeleton, it does not match the original FBX imported skeleton anymore. Because each FBX bone can point in a different direction, there is no single uniform swapping of bone orientations on import/export that will ever work for FBX armatures which have different orientations on different bones. For example, the default UE4 skeleton orients left-leg bones towards -X, and right-leg bones towards +X. As a result, using Blender FBX Import "primary bone axis" can fix the left leg **OR** the right leg, but never both at the same time. This pic below shows a UE4 mannequin skeleton imported into blender without any bone adjustment. You can see the bone X axis points up on one leg and down on the other. Without any bone correction, the animations work fine in blender and export fine back to UE4, but this rig isn't very convenient to use, as the bones are not oriented in the model. ![image.png](https://archive.blender.org/developer/F10600749/image.png) --------------- **Ideas about how to fix this problem...** (1) have the FBX importer *save* the correction_matrix that "automatic bone orientation" computes, and save it in custom property per bone. Then. during FBX export of that armature or animations, that matrix would be inverted to correct the bone orientations back to the way they were in the source FBX file. (and it would be convenient to have a small property UI and widget to display the FBX bone local axis, which will not match the Blender bone local axis) (2) extend Blender's bone display code to have an additional "bone display rotation", which would rotate the visible bone handle without affecting the underlying bone axis. An additional toggle "always orient bone towards child pivot" could orient the bone display towards the child bone, matching Maya's behavior. Leaf bones could be automatically oriented during import, similar to the current "automatic bone orientation" Pros and Cons: (1) is likely to be easier to implement and experiment with. It has the drawback that any thing driven off the Blender bone local axis will not match the FBX local axis, but anything like this is unlikely to export into game engines anyway (a primary target of this fbx import/export process). (2) and/or (3) are probably unnecessary... as the way blender handles bones works just fine ---------------- **Workaround until then...** Until there is a solution which makes Blender able to preserve FBX bone orientations through import/export in a useful way.. the solution to get import/export interop between Blender and FBX based tools is to standardize on a rig where all bones match the Blender orientation... such as by building a rig in blender and standardizing on that rig. This is the approach the Blender Uefy addon for Unreal Engine takes. Alternatively, one can build a blender-centric +Y bone skeleton for getting animations into Unreal/UE and then retarget them to another skeleton with their animation retargeting tools.

Shandler Tanner-Romanov commented

2022-02-07 09:59:42 +01:00

Added subscriber: @satr7h

Omar Emara commented

2022-03-24 07:44:34 +01:00

Added subscribers: @DrPhil, @OmarEmaraDev, @mano-wii, @Ahm4Design

mistercokes commented

2022-04-16 20:54:08 +02:00

Added subscriber: @mistercokes

Marc Dittmar commented

2022-12-01 09:41:00 +01:00

Added subscriber: @marc_von_step

Alexey Zakharchenko commented

2022-12-14 16:57:27 +01:00

Added subscriber: @LuffyTheFox

Alexey Zakharchenko commented

2022-12-14 16:57:27 +01:00

Hello everyone. I did it - finally. Just because I love Blender, creative freedom and believe in the future of indie gamedev.

This has been there for a very long time, but finally after almost a year of development I fixed almost everything related to FBX files, Rig and 3D animations at least for Unreal Engine 5. Here how UE4 and UE5 skeletons now look like. Now you can do whatever you want with 3D characters based on Epic Skeleton. Animations for 3D meshes with correct scaling is supported too. Rig works too on standart Blender features without extra skeleton creation:

All original bone +X and -X axis from FBX file are preserved. Here YouTube playlist with half of Blender Next features: https:*youtube.com/playlist?list=PLldtCJ1OMBDhLSnxOyrNe-8iIAX_Xmhz- . Precompiled custom Blender Next build for Windows with Quinn rig file available now on my GitHub page: https:*github.com/LuffyTheFox/Blender-Next-for-Unreal-Engine/releases/tag/Blender

Enjoy. I hope you will not be as sad as I am right now at this difficult time for all of us. Due to the fact that I have changed a lot of things in the program I can not post here diff. In addition, this build breaks the support of existing plugins from Blender Market. So It just works correctly for FBX files for Unreal Engine 5 Epic Skeleton. That's it.

Hello everyone. I did it - finally. Just because I love Blender, creative freedom and believe in the future of indie gamedev. This has been there for a very long time, but finally after almost a year of development I fixed almost everything related to FBX files, Rig and 3D animations at least for Unreal Engine 5. Here how UE4 and UE5 skeletons now look like. ![UE4.JPG](https://archive.blender.org/developer/F13991351/UE4.JPG) ![UE5.JPG](https://archive.blender.org/developer/F13991353/UE5.JPG) Now you can do whatever you want with 3D characters based on Epic Skeleton. Animations for 3D meshes with correct scaling is supported too. Rig works too on standart Blender features without extra skeleton creation: ![rig.jpg](https://archive.blender.org/developer/F14057477/rig.jpg) All original bone +X and -X axis from FBX file are preserved. Here YouTube playlist with half of Blender Next features: https:*youtube.com/playlist?list=PLldtCJ1OMBDhLSnxOyrNe-8iIAX_Xmhz- . Precompiled custom Blender Next build for Windows with Quinn rig file available now on my GitHub page: https:*github.com/LuffyTheFox/Blender-Next-for-Unreal-Engine/releases/tag/Blender Enjoy. I hope you will not be as sad as I am right now at this difficult time for all of us. Due to the fact that I have changed a lot of things in the program I can not post here diff. In addition, this build breaks the support of existing plugins from Blender Market. So It just works correctly for FBX files for Unreal Engine 5 Epic Skeleton. That's it.

Pobedinskiy commented

2023-01-16 06:43:46 +01:00

Added subscriber: @Valdimir

Pobedinskiy commented

2023-01-16 06:43:46 +01:00

Thank you very much Alexey for your work!

Tom Weber commented

2023-01-16 09:23:10 +01:00

Thank you very much! May I ask you why you tested against UE and not against Unity?

Alexey Zakharchenko commented

2023-01-16 09:41:21 +01:00

In #53620#1474718, @tw2020 wrote:
Thank you very much! May I ask you why you tested against UE and not against Unity?

Sure. First, UE is open source - it's programming freedom for development. Second, very complex stuff with character setup in UE can be done in matter of seconds via quick and simple 3D character mesh replacement in Control Rig and Third Person blueprint. Also, animation retarget is quick and easy too via IK retargetter.

But I think my Blender Next can be used in Unity too. Because FBX behaviour is same for both engines.

> In #53620#1474718, @tw2020 wrote: > Thank you very much! May I ask you why you tested against UE and not against Unity? Sure. First, UE is open source - it's programming freedom for development. Second, very complex stuff with character setup in UE can be done in matter of seconds via quick and simple 3D character mesh replacement in Control Rig and Third Person blueprint. Also, animation retarget is quick and easy too via IK retargetter. But I think my Blender Next can be used in Unity too. Because FBX behaviour is same for both engines.

Sign in to join this conversation.