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
                    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.

simple animated cube

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

Blend File link

FBX link

  • $\begingroup$ 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. $\endgroup$
    – dr. Sybren
    Commented Oct 9, 2016 at 19:21
  • $\begingroup$ 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. $\endgroup$ Commented Oct 9, 2016 at 20:28
  • $\begingroup$ Somehow this must be related to the use of the transform & transformLink matrices in the FBX file $\endgroup$ Commented Oct 9, 2016 at 23:01
  • $\begingroup$ Well, if you don't think it's a bug, I don't see a question in your post. What are you asking for? $\endgroup$
    – dr. Sybren
    Commented Oct 10, 2016 at 0:11
  • $\begingroup$ Edited. I thought the information I supplied was enough for one to infer a general "WTF??" $\endgroup$ Commented Oct 10, 2016 at 0:48

2 Answers 2



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..

  • $\begingroup$ 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. $\endgroup$ Commented Oct 13, 2016 at 16:22
  • $\begingroup$ 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? $\endgroup$ Commented Oct 21, 2016 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
                    Color: 1,0,0
                Channel: "Y" {
                    Default: 0.064355529793542
                    KeyVer: 4005
                    KeyCount: 34

... 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).

I am interested in more info about the rotation theme, too.

  • $\begingroup$ Your results would make sense, because you are telling it during the export that +y is up. This is what I would want and expect. I am doing the same thing, and my rotation is still placed on X. $\endgroup$ Commented Oct 12, 2016 at 2:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .