Two "identical" hierarchies - one adds a -90 rotation to an object on creating FBX, but the other does not. Why? #104641

Open
opened 2023-05-27 19:19:08 +02:00 by Mike-M-2 · 2 comments

System Information
Operating system: Windows 10
Graphics card: GEFORCE RTX 3060

Blender Version
Broken: 2.93 & 3.5.1
Worked: None

Short description of error

I posted a thread summarizing the bug with screenshots here: https://blender.stackexchange.com/questions/292830/two-identical-projects-one-adds-a-90-rotation-to-an-object-on-creating-fbx

Attached is a blend file with "working" and "broken" hierarchies in them. Both hierarchies are identical to the visible eye. They are each just 9 objects - an empty root with a x-rotation of 90 degrees, then a tree trunk child, and 8 branches. None of the tree trunk or branch objects have any rotations on them.

The "broken" and "working" hierarchies are identical that I can tell to my eye.

However, if you export and then re-import an FBX of each of the two hierarchies, they behave differently. The "broken" hierarchy upon re-import of an FBX made from it adds a -90 degree x-rotation to the "bark" trunk object. The "working" hierarchy upon re-import of the FBX has no x-rotation on the "bark" named trunk object.

There is no reason I can find for this discrepancy. It is causing numerous glitches as hierarchies do not behave consistently in FBX export/import, and FBX is a needed intermediary into other systems like in game development.

Exact steps for others to reproduce the error

  • Right click either the "WORKING" or "BROKEN" Empty Axis and Select Hierarchy
  • File > Export > FBX
  • Object Types: Empty & Mesh
  • Apply Scalings: FBX Units
  • Forward: Y forward
  • Up: Z up
  • Uncheck Apply Unit, Uncheck Use Space Transform, Uncheck Apply Transform
  • Save the exported FBX to disk
  • File > Import > FBX and re-import the created FBX
  • Look at the object named "bark" and see the x-rotation added from the "BROKEN" as -90 while from "WORKING" it is 0.

I suspect there is some issue about how the two hierarchies were created (perhaps in terms of orders they were parented) that created an invisible glitch which is causing this but I have no way to verify it. I did not make the "WORKING" hierarchy - someone else did. I can't find any reason or explanation, but certainly need this solved to consistently get out working FBX files.

The "WORKING" hierarchy has the desired behavior on export - no extra rotation should be added to the "bark" object as it is in the "BROKEN" hierarchy.

Thanks for any help or clarification.

**System Information** Operating system: Windows 10 Graphics card: GEFORCE RTX 3060 **Blender Version** Broken: 2.93 & 3.5.1 Worked: None **Short description of error** I posted a thread summarizing the bug with screenshots here: https://blender.stackexchange.com/questions/292830/two-identical-projects-one-adds-a-90-rotation-to-an-object-on-creating-fbx Attached is a blend file with "working" and "broken" hierarchies in them. Both hierarchies are identical to the visible eye. They are each just 9 objects - an empty root with a x-rotation of 90 degrees, then a tree trunk child, and 8 branches. None of the tree trunk or branch objects have any rotations on them. The "broken" and "working" hierarchies are identical that I can tell to my eye. However, if you export and then re-import an FBX of each of the two hierarchies, they behave differently. The "broken" hierarchy upon re-import of an FBX made from it adds a -90 degree x-rotation to the "bark" trunk object. The "working" hierarchy upon re-import of the FBX has no x-rotation on the "bark" named trunk object. There is no reason I can find for this discrepancy. It is causing numerous glitches as hierarchies do not behave consistently in FBX export/import, and FBX is a needed intermediary into other systems like in game development. **Exact steps for others to reproduce the error** - Right click either the "WORKING" or "BROKEN" Empty Axis and Select Hierarchy - File > Export > FBX - Object Types: Empty & Mesh - Apply Scalings: FBX Units - Forward: Y forward - Up: Z up - Uncheck Apply Unit, Uncheck Use Space Transform, Uncheck Apply Transform - Save the exported FBX to disk - File > Import > FBX and re-import the created FBX - Look at the object named "bark" and see the x-rotation added from the "BROKEN" as -90 while from "WORKING" it is 0. I suspect there is some issue about how the two hierarchies were created (perhaps in terms of orders they were parented) that created an invisible glitch which is causing this but I have no way to verify it. I did not make the "WORKING" hierarchy - someone else did. I can't find any reason or explanation, but certainly need this solved to consistently get out working FBX files. The "WORKING" hierarchy has the desired behavior on export - no extra rotation should be added to the "bark" object as it is in the "BROKEN" hierarchy. Thanks for any help or clarification.
Mike-M-2 added the
Type
Report
Priority
Normal
Status
Needs Triage
labels 2023-05-27 19:19:09 +02:00
Author

This is a resubmission of the bug here:

blender/blender#107915

As requested by @lichtwerk

Thanks

This is a resubmission of the bug here: https://projects.blender.org/blender/blender/issues/107915 As requested by @lichtwerk Thanks
Member

It looks like both Bark Objects were parented to their respective Empties differently and the mesh data for each Bark Object is rotated differently. Notably, if you delete both empties, you can see that one Bark Object loses the rotation from its parenting and falls on its side, revealing that the mesh data itself is rotated to the side.
image

The parenting appears to have happened something like this:

bark.001 was parented to WORKING when WORKING had no rotation. Because the mesh data of bark.001 is laying down on its side, when WORKING was rotated 90 degrees on the X-axis, it makes bark.001 stand upright.

bark was parented to BROKEN when BROKEN was already rotated 90 degrees on the X-axis. Because the mesh data of bark is standing upright and it was parented after the rotation, there was no change in its rotation, so bark was still standing upright.

The parenting documentation has some information on the Parent Inverse that facilitates parenting to an Object that already has transforms: https://docs.blender.org/manual/en/latest/scene_layout/object/editing/parent.html#parent-inverse

If you re-parent bark to BROKEN with Object>Parent>Make Parent without Inverse (Keep Transform), it will clear the Parent Inverse matrix and reveal the same -90 degree rotation that you are seeing when you import the exported fbx.

It looks like both Bark Objects were parented to their respective Empties differently _and_ the mesh data for each Bark Object is rotated differently. Notably, if you delete both empties, you can see that one Bark Object loses the rotation from its parenting and falls on its side, revealing that the mesh data itself is rotated to the side. ![image](/attachments/d9f8d164-f3b9-4de3-b2ea-03f34a0ae945) The parenting appears to have happened something like this: `bark.001` was parented to `WORKING` when `WORKING` had no rotation. Because the mesh data of `bark.001` is laying down on its side, when `WORKING` was rotated 90 degrees on the X-axis, it makes `bark.001` stand upright. `bark` was parented to `BROKEN` when `BROKEN` was already rotated 90 degrees on the X-axis. Because the mesh data of `bark` is standing upright and it was parented after the rotation, there was no change in its rotation, so `bark` was still standing upright. The parenting documentation has some information on the Parent Inverse that facilitates parenting to an Object that already has transforms: https://docs.blender.org/manual/en/latest/scene_layout/object/editing/parent.html#parent-inverse If you re-parent `bark` to `BROKEN` with `Object`>`Parent`>`Make Parent without Inverse (Keep Transform)`, it will clear the Parent Inverse matrix and reveal the same -90 degree rotation that you are seeing when you import the exported fbx.
122 KiB
Sign in to join this conversation.
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#104641
No description provided.