# FBX export places rotation on wrong axis

I have a dead simple animation created in Blender 2.75. It is a cube which moves up and down, and rotates, both along the Z (up) axis. I want to export the mesh and animation as an FBX file and use it in an OpenGL code project.

The problem is that in the exported FBX file, the rotation is happening on the X axis. I have tried exporting with coordinates set both ways (OpenGL & Blender) and either way, in the FBX file, the rotation in the keyframes is happening on the X axis. The translation however correctly happens along the Z axis.

Here is the generated FBX code

Channel: "R" {
Channel: "X" {
Default: 90.000002504348856
KeyVer: 4005
KeyCount: 21
Key:
0,90.000002504348856,L,
1924423250,90.632805870571289,L,
3848846500,92.594996275708070,L,
5773269750,95.924201231896745,L,
7697693000,100.531853676169902,L,
9622116250,106.157088193557598,L,
11546539500,112.381692301180564,L,
13470962750,118.725681285306010,L,
15395386000,124.771805719727638,L,
17319809250,130.241844678794536,L,
19244232500,135.000000341428688,L,
21168655750,139.758156004062869,L,
23093079000,145.228194963129766,L,
25017502250,151.274333057929709,L,
26941925500,157.618335702433512,L,
28866348750,163.842919319488971,L,
30790772000,169.468153836876667,L,
32715195250,174.075813111338988,L,
34639618500,177.405024897716828,L,
36564041750,179.367201642475266,L,
38488465000,180.000018669076042,L
Color: 1,0,0
}
Channel: "Y" {


I also don't understand why the rotation is 90-180 and not 0-90 when I added the cube at the origin and didn't otherwise transform it, except for the animation keyframes, but I can work around that for now.

Edit It's hard to see, but there is an armature & single bone. The bone is rotating.

Edit: My question is: How does this animation correspond to the data created in the FBX file?

• If you think this is a bug (which it might well be), file a bug report at developer.blender.org. Be sure to attach a simple example for the devs so that we can recreate your problem on our own machine. But... before you do that, upgrade to Blender 2.78 first. No reason to report a bug that may already be fixed. – dr. Sybren Oct 9 '16 at 19:21
• I don't think it's a bug, I think somehow the rotation is being described in a different orientation than expected. I tried adding a second rotation along the Y axis and in the resulting FBX file the rotation values now change along all 3 axes. – parker.sikand Oct 9 '16 at 20:28
• Somehow this must be related to the use of the transform & transformLink matrices in the FBX file – parker.sikand Oct 9 '16 at 23:01
• Well, if you don't think it's a bug, I don't see a question in your post. What are you asking for? – dr. Sybren Oct 10 '16 at 0:11
• Edited. I thought the information I supplied was enough for one to infer a general "WTF??" – parker.sikand Oct 10 '16 at 0:48

sikand

I don't know, if fbx ASCII changed from blender vers. 2.75 to 2.77 or 2.78, but it is not wrong to update.

Maybe you can repeat a test again with only the z-rotation:

I did the test this way:

New file, n-key to follow the rotation data

Before you rotate the cube, you have to decide, whether you want to rotate the cube with xyz-Euler-angles or quaternions. It will break the animation, if this setting is changed afterwards. (I think the reason is, that keyframe interpolation is calculated, when the second keyframe in inserted and can't be done, when the rotation mode is changed afterwards)

So lets choose xyz-Euler-angles instead of quaternion wxyz for this test (the result should be the same: keyframes change at Channel: "R" and Channel: "Y"), in object mode choose i-key and in keyframe-menu choose rotation (rotation data become yellow and a yellow keyframe is inserted at keyframe 0 in the keyframe editor), go to another keyframe - 12 - for example, r-key followed by z-key, rotate the cube with a mouse-movement (z-axis rotation data should change), hit i-key again and choose rotation in keyframe menu. moving the green mark in keyframe editor should rotate the cube now, a green color indicates the "linear interpolated states" between the keyframes (maybe you can control it in the "dope sheet editor").

That the animation becomes broken, when the rotation mode is changed afterwards can be tested: When now quaternions-wxyz is selected, moving the green mark does not move the cube anymore and no interpolated keyframes are exported to the ASCII fbx-file. So go back to xyz-Euler-angles.

Now Export to fbx ASCII 6.1 with -z forward and y up, only choose "armat" and (shift) "mesh", animation, all actions and default take selected, export.. Compare files with WinMerge or notepad++

Do you have any info about the "default Lcl Rotation" or the 4x4 posenode matrix ?

greetings testuser

update: Rotation with bones:

New file, delete the cube, if necessary center 3d cursor with "shift C" and add a single bone, the bone can be handled as an object and be rotated in object mode, (what one usually won't do, when a mesh is rigged - as far as i understand).

In edit mode the head (at the bottom), the body and the tail (on top) can be selected. Selecting the tail and rotating over x axis changes the tails y and z position. Global and local transform orientation is z-up. In "object data" switching between rest position and pose position makes no difference. Thus with the rotation in edit mode the rest position is changed, not the pose position. The corresponding changes in the fbx file can be found at "Lcl Rotation" (= default rotation, these values are also used as default values of the default take).

In pose mode you can see, that a bone has an own additional local coordinate system with the green y-axis always aligned to the bones body (change transform orientation to local in pose mode). Perhaps this may be the reason for your bizarre rotation results ?

The global z-rotation is a bones local y-rotation (if the bone is aligned to blenders z-axis) and this is exported to x-rotation-data, when export-options are "-z forward and y-up"

When rotating in pose mode, you create a difference between rest and pose position (with ctrl A and "apply pose as rest pose" the pose can be converted to default rest pose again).

What i think is, that this local system of the bone is used for rotation, if a model is imported for example into a game engine like unity or a "OpenGL code project". Manually changing one of the values of a keyframe inside the fbx file (rotation channel of a bone) rotates the bone over the bones local axes. When a bone (together with the mesh) in pose mode is animated and rotated inside blender, this rotation uses the global coordinate system instead and blender calculates the x,y and z-values for the bones local coordinate system. These values are displayed under transform-rotation in pose mode and are calculated for each keyframe, when blender does the keyframe interpolation.

If you want to rotate a bone for yourself, it may be necessary to do this calculation for your own - the question is how, because the angle of the bone may be relevant..

• Thank you for your help. Please review the updated question. I forgot to mention I am using a bone to do the rotation. When I try animation without bones, everything works fine, but when I use a single bone as I have done, the bone rotation appears to be oriented in a bizarre way, even though scaling and translation work just the same. – parker.sikand Oct 13 '16 at 16:22
• thank you for such a detailed answer. What you are saying makes perfect sense, but I still don't understand it. If the global Z is the bone's local Y, why would the axis change once more if the export specifies -z forward / y up? Why isn't the exported rotation still on the y axis? – parker.sikand Oct 21 '16 at 4:32

As blender newbee i try an answer:

When i export a cube rotated over the z-axis (blender 2.77, fbx-export as ASCII 6.1, export options -z forwared, y-up) my results are:

Property: "Lcl Rotation", "Lcl Rotation", "A+",-90.000009334538021,0.000000000000000,0.000000000000000

PoseNode:  {
Node: "Model::Cube"
Matrix: 0.000000075497901,0.000000000000000,-1.000000000000000,0.000000000000000,-1.000000000000000,0.000000000000000,-0.000000075497901,0.000000000000000,0.000000000000000,1.000000000000000,0.000000000000000,0.000000000000000,0.000000000000000,0.000000000000000,0.000000000000000,1.000000000000000
}

Channel: "R" {
Channel: "X" {
Default: -90.000002504348856
KeyVer: 4005
KeyCount: 1
Key:
1924423250,-90.000002504348856,L
Color: 1,0,0
}
Channel: "Y" {
Default: 0.064355529793542
KeyVer: 4005
KeyCount: 34
Key:
0,0.064355529793542,L,
1924423250,0.258506491746185,L,
3848846500,0.583605620352607,L,
5773269750,1.040065988645140,L,
7697693000,1.627416046766789,L,


... With the export option -z forward and y-up, which i used, the z-rotation is converted to a rotation in y-direction.

There are left-hand and right-hand coordinate systems and z-up y-up differences.

each key-entry consists of: time, value, L (for linear interpolation).