Best of the Best 2014 Show reel call for submissions
Discussion Groups

## FBX SDK

Distinguished Contributor
Posts: 107
Registered: ‎10-22-2007

# Fix for euler flip?

122 Views, 4 Replies
07-01-2009 06:01 PM
I have an quaternion-based animation system, and when I export to FBX, I'm getting Euler curves that flip back and forth
around the +- 180 degree mark.

http://www.okino.com/conv/exp_fbx.htm
The section under "Maintain Euler Continuity" describes this problem in detail.

Can anyone suggest a coding example that fixes this problem, or provide a FBX SDK solution for it?
All of my attempts to fix it have failed miserably so far.

Also, is there a mathematical name for this condition? Is it related to gimbal lock? Because I tried re-ordering
the Euler rotation order, but I don't see how that is going to help me if the FBX format only recognizes XYZ-ordered rotations.

Here's a graph of one such curve. RGB is XYZ euler angles, respectively, from -180 to 180. Y is fine, but
X and Z have problems at +- 180 degrees.

http://img190.imageshack.us/img190/9756/curvexyz.png

BTW, I'm using the FBX SDK to convert my quaternions to Euler angles, which works fine:

KFbxQuaternion q&#40; quat.x, quat.y, quat.z, quat.w &#41;
KFbxXMatrix M; M.SetQ&#40;q&#41;
KFbxVector4 euler = M.GetR&#40;&#41; // in degrees

My animation data is perfectly valid. I just need to know how to fix them when they cross the +-180 border.
Everybody must encounter this problem, because the FBX format only accepts Euler angles.

I can only think of all the game engines that adopt this format, only to discover later on that it will
cripple their animation.

Valued Contributor
Posts: 92
Registered: ‎09-04-2008

# Re: Fix for euler flip?

07-06-2009 02:17 AM in reply to: TravF
Hi TravF,
It's a known problem when we processed Collada file. In Fbx sdk, we solved it with FCurve filter, called "GimbleKiller" &#40;KFCurveFilterGimbleKiller&#41;. Unfortunately, it's not released to public SDK:&#40;

I'm afraid it's hard to fix your problem with fbx SDK in short term.
However,a good news for you, KFCurveFilterGimbleKiller should be published in our 2010 release.
Then let's call KFCurveFilterGimbleKiller::apply&#40;&KFCurve, 3&#41; to fix this problem.

BTW, I looked into the code of KFCurveFilterGimbleKiller, it's some math computations which is complicated to me and out of my band:&#40; you may find gimble and related issues to develop your own algorithm like Okino? Thank you.
Zhihao, Data Platform - Autodesk
Distinguished Contributor
Posts: 107
Registered: ‎10-22-2007

# Re: Fix for euler flip?

07-06-2009 12:37 PM in reply to: TravF
Great! It looks like that does the job!

Here's my results after using it:

It looks like the Gimble filter is simply extending the Euler angle space, so it doesn't get cut off at +- 180.
The angles don't wrap at anymore at +- 180. They go beyond the -180 and 180 range. I was trying to keep the
angles within +- 180, so that's where I was failing.

That shouldn't be too hard to write something like that? I don't see any need for complicated math or re-ordering, etc...

Distinguished Contributor
Posts: 656
Registered: ‎02-19-2008

# Re: Fix for euler flip?

07-17-2009 08:41 PM in reply to: TravF
 Great! It looks like that does the job! Here's my results after using it:It looks like the Gimble filter is simply extending the Euler angle space, so it doesn't get cut off at +- 180. The angles don't wrap at anymore at +- 180. They go beyond the -180 and 180 range. I was trying to keep theangles within +- 180, so that's where I was failing.That shouldn't be too hard to write something like that? I don't see any need for complicated math or re-ordering, etc...

Why isn't this the same issue as we discussed in this thread?

http://area.autodesk.com/forum/autodesk-fbx/fbx-sdk/why-euler-angles-are-not-sufficient-for-rotation...