FBX Import: Fix pre-, post- and geometric rotations #104561

Merged
Bastien Montagne merged 1 commits from Mysteryem/blender-addons:fbx_fix_pre_post_rotations_pr into main 2023-04-28 17:21:50 +02:00
Member

The pre-, post- and geometric rotations were using the rotation order of
the transform, but it's only the rotation that uses the rotation order
of the transform.

The post-rotation used in calculating the WorldTransform was being used
as-is, this seems to have been an error in the FBX 2011 documentation
because since FBX 2012, the documentation has specified that the inverse
of post-rotation is used and there is no mention of this change in the
FBX 2012 changes. Additionally, given files in FBX 2011 format, the
post-rotation works the same as in FBX 2012 and newer.

The pre-, post- and geometric rotations have been changed to always use
XYZ order.

The post-rotation is now inverted when calculating each WorldTransform.

Fixes the import of .fbx that have non-zero post-rotation.
Fixes the import of .fbx that have pre-/post-/geometric rotation and
have non-XYZ rotation order.

Cases where the "Use Pre/Post Rotation" option of the FBX Importer had
to be disabled to get a working import are likely to now work with the
option enabled.

Fixes #45176: Incorrect rotation of imported Cameras and Lights


The recent claim to having fixed #45176 in #104500 had me wondering what the actual problem with imported camera rotations was. Some other open-source FBX importers have had and fixed similar issues. It appears that there were two issues at play, I've tried to explain them here.

post-rotation inversion

Initially I figured out that post-rotation needed to be inverted by setting up an .fbx with post-rotation on a camera on all three axes (.fbx files in reported issues tend to have only a single non-zero axis) and importing it into Unity and then manually brute-forcing the rotation order and sign of components in Blender's FBX importer until Blender matched.
Later, I found that since FBX 2012, the documentation actually specifies that the inverse of the post-rotation is used. There was no mention of post-rotation changing in the FBX 2012 change notes and it just so happened that the ecp020_shotcam1_2011_v001.fbx attached in #45176 was a 2011 format FBX, so I could inspect its post-rotation and convert it to a newer FBX format using FBX Converter 2013. By observing that both the original 2011 version and the converted 2013 version had identical post-rotation, both displayed the same in the FBX Viewer in FBX Converter and both imported correctly into Blender when using the inverse of post-rotation, I deduced that the FBX 2011 documentation must have been incorrect as opposed to the FBX format having changed in this regard in FBX 2012.

ufbx inverts post-rotation: 70d5526256/ufbx.c (L19152)
assimp inverts post-rotation: b1afa41047/code/AssetLib/FBX/FBXConverter.cpp (L820)
I also found a thread on the autodesk forums from 2010 where the user managed to figure out that post-rotation needed to be inverted, despite it not being in the documentation: https://forums.autodesk.com/t5/fbx-forum/maya-quot-rotate-axis-quot-vs-fbx-quot-postrotation-quot/td-p/4168814?profile.language=en

pre-/post-/geometric rotation order

The FBX documentation only actually specifies that the R rotation matrix takes into account the rotation order of the transform, it seems to have been a mistake to also apply the rotation order to the other rotation matrices.
The example code under "Pivot Management" at https://download.autodesk.com/us/fbx/20112/FBX_SDK_HELP/SDKRef/a00209.html actually has a comment that states "// Rotation order don't affect post rotation, so just use the default XYZ order", so that at least makes it clear that post-rotation is not affected by rotation order.
assimp had the same issue of not having pre-/post-rotation in XYZ order: 9444935ce8
ufbx also uses XYZ order for pre-/post-rotation: 70d5526256/ufbx.c (L19165)

Geometric rotation I couldn't tell whether to use 'XYZ' or the rotation order of the transform so figured it out myself by modifying the Road_signs_v1.FBX from #104558 so that the first sign Model had a geometric rotation of (-90, -20, 15) and so that all the models in the file had ZXY rotation order. By opening the modified .fbx in Unity and FBX Review, I could see that geometric rotation had to also always be XYZ otherwise blender would import the rotation of the modified first sign Model incorrectly.

Tested files now importing with expected rotation with this patch

The FBX Viewer in FBX Converter 2013 is very useful for showing the expected import where users have not provided screenshots in the issues though it tends to crash opening manually modified .fbx files and can't open some newer .fbx files since it's only designed to support up to FBX 2013. FBX Review is also useful for the same purpose and is much more recent and resilient to manually modified and broken .fbx files, but it's very basic and doesn't show cameras or lights as objects in the scene which makes it less useful since a lot of the reports are about camera rotations specifically.
I found that a lot of the imported .fbx import really tiny with default settings, so you may need to zoom in or scale up imported Objects to see them better in Blender.

  • ecp020_shotcam1_2011_v001.fbx from #45176 (comment)
    • image
    • image
  • T1v2.fbx from #45176 (comment)
    • image
  • fontan new.fbx from #81444 (comment)
    • Note that this .fbx also sets the Shift X and Shift Y of the camera in the import, so to get parity with other software, both shift values may need to be set to zero.
    • image
  • g2f_nolimits.fbx from #88272 (comment)
    • This patch does not solve the linked issue, but rather fixes the fact that importing older DAZ3D FBX would have incorrect rotations unless Use Pre/Post rotations was disabled in the importer (this is a common step to find in older tutorials for importing from DAZ Studio to Blender). With this patch, disabling Use Pre/Post rotations appears to now be unnecessary, though I was unable to find an older animated DAZ3D FBX to determine if animations would also work. Newer versions of DAZ Studio appear to not use pre- and post-rotations in their FBX exports anymore, so the Use Pre/Post rotations option of the importer is irrelevant for newer DAZ3D produced .fbx files.
    • image
  • MayaLightCameraOutputTest_20201012.fbx from #81647
    • image
  • Road_signs_v1_underground_parking_geometric_rotation_modified.fbx
    • This is the .fbx I modified so that the first sign has a geometric rotation of (-90, -20, 15) and so that all the objects have ZXY rotation order.
    • image
    • image
The pre-, post- and geometric rotations were using the rotation order of the transform, but it's only the rotation that uses the rotation order of the transform. The post-rotation used in calculating the WorldTransform was being used as-is, this seems to have been an error in the FBX 2011 documentation because since FBX 2012, the documentation has specified that the inverse of post-rotation is used and there is no mention of this change in the FBX 2012 changes. Additionally, given files in FBX 2011 format, the post-rotation works the same as in FBX 2012 and newer. The pre-, post- and geometric rotations have been changed to always use XYZ order. The post-rotation is now inverted when calculating each WorldTransform. Fixes the import of .fbx that have non-zero post-rotation. Fixes the import of .fbx that have pre-/post-/geometric rotation and have non-XYZ rotation order. Cases where the "Use Pre/Post Rotation" option of the FBX Importer had to be disabled to get a working import are likely to now work with the option enabled. Fixes #45176: Incorrect rotation of imported Cameras and Lights ---- The recent claim to having fixed #45176 in https://projects.blender.org/blender/blender-addons/pulls/104500 had me wondering what the actual problem with imported camera rotations was. Some other open-source FBX importers have had and fixed similar issues. It appears that there were two issues at play, I've tried to explain them here. ### post-rotation inversion Initially I figured out that post-rotation needed to be inverted by setting up an .fbx with post-rotation on a camera on all three axes (.fbx files in reported issues tend to have only a single non-zero axis) and importing it into Unity and then manually brute-forcing the rotation order and sign of components in Blender's FBX importer until Blender matched. Later, I found that since FBX 2012, [the documentation](https://download.autodesk.com/global/docs/fbxsdk2012/en_us/files/GUID-10CDD63C-79C1-4F2D-BB28-AD2BE65A02E-50.htm) actually specifies that the inverse of the post-rotation is used. There was no mention of post-rotation changing in the FBX 2012 change notes and it just so happened that the [ecp020_shotcam1_2011_v001.fbx](https://archive.blender.org/developer/F197080/ecp020_shotcam1_2011_v001.fbx) attached in https://projects.blender.org/blender/blender-addons/issues/45176 was a 2011 format FBX, so I could inspect its post-rotation and convert it to a newer FBX format using FBX Converter 2013. By observing that both the original 2011 version and the converted 2013 version had identical post-rotation, both displayed the same in the FBX Viewer in FBX Converter and both imported correctly into Blender when using the inverse of post-rotation, I deduced that the FBX 2011 documentation must have been incorrect as opposed to the FBX format having changed in this regard in FBX 2012. ufbx inverts post-rotation: https://github.com/ufbx/ufbx/blob/70d552625622819e91881ead78c5fe649a855075/ufbx.c#L19152 assimp inverts post-rotation: https://github.com/assimp/assimp/blob/b1afa41047de5e81f3c6b8b083a1ba8c169adce6/code/AssetLib/FBX/FBXConverter.cpp#L820 I also found a thread on the autodesk forums from 2010 where the user managed to figure out that post-rotation needed to be inverted, despite it not being in the documentation: https://forums.autodesk.com/t5/fbx-forum/maya-quot-rotate-axis-quot-vs-fbx-quot-postrotation-quot/td-p/4168814?profile.language=en ### pre-/post-/geometric rotation order The [FBX documentation](http://download.autodesk.com/us/fbx/20112/FBX_SDK_HELP/index.html?url=WS1a9193826455f5ff1f92379812724681e696651.htm,topicNumber=d0e7429) only actually specifies that the `R` rotation matrix takes into account the rotation order of the transform, it seems to have been a mistake to also apply the rotation order to the other rotation matrices. The example code under "Pivot Management" at https://download.autodesk.com/us/fbx/20112/FBX_SDK_HELP/SDKRef/a00209.html actually has a comment that states "// Rotation order don't affect post rotation, so just use the default `XYZ` order", so that at least makes it clear that post-rotation is not affected by rotation order. assimp had the same issue of not having pre-/post-rotation in `XYZ` order: https://github.com/assimp/assimp/commit/9444935ce8411c8326d1eea20da676a4bb6a27bd ufbx also uses `XYZ` order for pre-/post-rotation: https://github.com/ufbx/ufbx/blob/70d552625622819e91881ead78c5fe649a855075/ufbx.c#L19165 Geometric rotation I couldn't tell whether to use 'XYZ' or the rotation order of the transform so figured it out myself by modifying the `Road_signs_v1.FBX` from https://projects.blender.org/blender/blender-addons/issues/104558 so that the first sign Model had a geometric rotation of `(-90, -20, 15)` and so that all the models in the file had `ZXY` rotation order. By opening the modified .fbx in Unity and FBX Review, I could see that geometric rotation had to also always be `XYZ` otherwise blender would import the rotation of the modified first sign Model incorrectly. ### Tested files now importing with expected rotation with this patch The FBX Viewer in FBX Converter 2013 is very useful for showing the expected import where users have not provided screenshots in the issues though it tends to crash opening manually modified .fbx files and can't open some newer .fbx files since it's only designed to support up to FBX 2013. FBX Review is also useful for the same purpose and is much more recent and resilient to manually modified and broken .fbx files, but it's very basic and doesn't show cameras or lights as objects in the scene which makes it less useful since a lot of the reports are about camera rotations specifically. I found that a lot of the imported .fbx import really tiny with default settings, so you may need to zoom in or scale up imported Objects to see them better in Blender. * [ecp020_shotcam1_2011_v001.fbx](https://archive.blender.org/developer/F197080/ecp020_shotcam1_2011_v001.fbx) from https://projects.blender.org/blender/blender-addons/issues/45176#issue-5995 * ![image](/attachments/ffa400cc-3345-4150-8f42-3d34ea6dc443) * ![image](/attachments/f57d2ee3-91c8-44bd-b042-a3fd47527940) * [T1v2.fbx](https://archive.blender.org/developer/F512439/T1v2.fbx) from https://projects.blender.org/blender/blender-addons/issues/45176#issuecomment-55477 * ![image](/attachments/adf77195-de10-4529-864e-7956b24cc34e) * [fontan new.fbx](https://archive.blender.org/developer/F8959054/fontan_new.fbx) from https://projects.blender.org/blender/blender-addons/issues/81444#issuecomment-24398 * Note that this .fbx also sets the `Shift X` and `Shift Y` of the camera in the import, so to get parity with other software, both shift values may need to be set to zero. * ![image](/attachments/e7aec455-8c28-4d7c-8322-b03e2203a53f) * [g2f_nolimits.fbx](https://drive.google.com/file/d/12e2DtFcy8fqVmhOsq4DSuth7U4wmbbkH/view?usp=sharing) from https://projects.blender.org/blender/blender-addons/issues/88272#issue-2434 * This patch does not solve the linked issue, but rather fixes the fact that importing older DAZ3D FBX would have incorrect rotations unless `Use Pre/Post rotations` was disabled in the importer (this is a common step to find in older tutorials for importing from DAZ Studio to Blender). With this patch, disabling `Use Pre/Post rotations` appears to now be unnecessary, though I was unable to find an older animated DAZ3D FBX to determine if animations would also work. Newer versions of DAZ Studio appear to not use pre- and post-rotations in their FBX exports anymore, so the `Use Pre/Post rotations` option of the importer is irrelevant for newer DAZ3D produced .fbx files. * ![image](/attachments/2753508d-f743-4b96-a7ec-1394fabc3c6d) * [MayaLightCameraOutputTest_20201012.fbx](https://archive.blender.org/developer/F8982408/MayaLightCameraOutputTest_20201012.fbx) from https://projects.blender.org/blender/blender-addons/issues/81647 * ![image](/attachments/b7c2670b-2b32-4fd3-b29f-3ccfc618ae0e) * [Road_signs_v1_underground_parking_geometric_rotation_modified.fbx](/attachments/f853909f-7dcb-4943-b949-e1628797da89) * This is the .fbx I modified so that the first sign has a geometric rotation of `(-90, -20, 15)` and so that all the objects have `ZXY` rotation order. * ![image](/attachments/13be9877-7572-479e-9807-139298e22601) * ![image](/attachments/5f9d895a-b87f-4c79-8018-df49fdca1a83)
Thomas Barlow force-pushed fbx_fix_pre_post_rotations_pr from 465bda6e98 to f858f9528e 2023-04-24 07:22:10 +02:00 Compare
Author
Member

I updated the "Computing transformation matrices" link to the current FBX SDK documentation and removed the links to older versions of the documentation.

The link for reference: https://help.autodesk.com/view/FBX/2020/ENU/?guid=FBX_Developer_Help_nodes_and_scene_graph_fbx_nodes_computing_transformation_matrix_html

I updated the "Computing transformation matrices" link to the current FBX SDK documentation and removed the links to older versions of the documentation. The link for reference: https://help.autodesk.com/view/FBX/2020/ENU/?guid=FBX_Developer_Help_nodes_and_scene_graph_fbx_nodes_computing_transformation_matrix_html
Thomas Barlow requested review from Bastien Montagne 2023-04-24 07:30:40 +02:00
Bastien Montagne approved these changes 2023-04-28 17:02:55 +02:00
Bastien Montagne left a comment
Owner

Uuuuh nice finding, thanks a lot! And great explanations once again. :D

Uuuuh nice finding, thanks a lot! And great explanations once again. :D
Bastien Montagne merged commit 8e37176dcd into main 2023-04-28 17:21:50 +02:00
Bastien Montagne deleted branch fbx_fix_pre_post_rotations_pr 2023-04-28 17:21:50 +02:00
Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-addons#104561
No description provided.