FBXLoader: added warning for unsupported rotation orders

[looeee]

See #12405

I've had a look into supporting Euler rotation order other than XYX in the FBXLoader - it will take a bit of work, so in the meantime I've added a warning when unsupported orders are encountered.

If anybody else want to look into this here are some test files.

fbx_rotation_order_test.zip

The main issue I have run into here is that rotation order is hard coded as 'ZYX' in several places throughout the loader - this may mean that FBX is using extrinsic Euler angles since as far as I know the conversion from intrinsic XYZ order will be extrinsic ZYX. I'm not sure how to do this conversion for other orders though.

@WestLangley any ideas if this is correct, and if so how to go about converting the other possible orders?

[WestLangley]

Conversion from extrinsic to intrinsic via reversal of the order works for any Euler Order.

If you are including animation, make sure your examples are simple enough to understand what is happening.

If only one axis is being rotated, it does not matter what the Euler Order is, so I am not sure your test cases will be very informative.

[ignazioa]

@WestLangley agree on the reverse order, any idea how eSPHERIC_XYZ works ?

[WestLangley]

No idea.

[looeee]

@WestLangley thank you - I had tried just reversing the order and it didn't work, so I guess I must have missed something else.

If only one axis is being rotated...

Are you looking at the preRotation? That is (-90, 0, 0), I'm not sure why since the I didn't do any initial rotating of the cube. I'm testing the animation here, which is a rotation defined on multiples axes.

[makc]

unsupported rotation orders

wait, but Euler class (which object.rotation is) specifically supports any order? I was under impression that, if you set object rotation order, it sticks? of course if actual animation code is using some quaternion voodoo, it is irrelevant.

[makc]

any idea how eSPHERIC_XYZ works ?

google pretends it's the same as euler xyz but I doubt it. you have to ask sdk engineers.

[looeee]

google pretends it's the same as euler xyz

I suspect that they don't know (or don't support it) either and are just defaulting to XYZ in that case.

if actual animation code is using some quaternion voodoo

All rotations in the FBX format are stored as Euler angles. These are converted to quaternions by the loader.

[makc]

back in 2012 Jiayang.Xu and Robert.Goulet @autodesk.com were kind enough to answer my fbx format questions. feel free to try your luck )

[makc]

oh, one of them CCed [email protected] so maybe that is proper email to direct the questions to.

[looeee]

Thanks for contacts!

With regards to eSPHERIC_XYZ I don't think it's something we need to worry about though.

[WestLangley]

Maybe this is of interest...
http://download.autodesk.com/global/docs/motionbuilder2014-tutorial/index.html?url=files/Degrees_of_Freedom_(DOF)_DOF_Rotation_Properties.htm,topicNumber=d30e130768

[looeee]

@WestLangley thanks, that solves that mystery 😁

[looeee]

@mrdoob was there a reason that you didn't want to merge this? Even though it doesn't actually add support for different Euler orders it will at least display a useful warning and sets the ground work for adding support later.

[mrdoob]

@mrdoob was there a reason that you didn't want to merge this?

I forgot 😇

[mrdoob]

Thanks!