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.

Searching for this problem on Google brings up this page:

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.

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

KFbxQuaternion q( quat.x, quat.y, quat.z, quat.w )
KFbxXMatrix M; M.SetQ(q)
KFbxVector4 euler = M.GetR() // 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.

	Attachment

Hi TravF,
It’s a known problem when we processed Collada file. In Fbx sdk, we solved it with FCurve filter, called “GimbleKiller” (KFCurveFilterGimbleKiller). Unfortunately, it’s not released to public SDK:(

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(&KFCurve, 3) 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:( you may find gimble and related issues to develop your own algorithm like Okino? Thank you.

Zhihao, Data Platform - Autodesk

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…

	Attachment

TravF 06 July 2009 03:37 PM

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…

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

http://area.autodesk.com/for...ient-for-rotation-solved/

I’m not sure, but this thread was about an export issue (quat to eulers).  The other thread was about an import issue (eulers to quat).

On import, I have to align the quats to take the shortest path, and on export, I have to ‘unflip’ the euler angles.
I did mention I was using a quaternion-based animation system.