WIP: FBX: Preventing import of duplicate shape keys #104939

Closed
Mikhail Matrosov wants to merge 1 commits from ktdfly/blender-addons:fbx_prevent_dup_shape_keys into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
First-time contributor

Duplicate connections cause the same shape keys to be imported many times, resulting in a very long processing time (could be hours) and high memory usage, which is not something we expect from FBX files. The unreported issue happens with FBX files from #104909 (attached here as well).

This PR contains the part separated from #104910, but both are required to import FBX from Unreal:

MaleFace.fbx
facemesh.fbx

Duplicate connections cause the same shape keys to be imported many times, resulting in a very long processing time (could be hours) and high memory usage, which is not something we expect from FBX files. The unreported issue happens with FBX files from #104909 (attached here as well). This PR contains the part separated from #104910, but both are required to import FBX from Unreal: [MaleFace.fbx](/attachments/dea088f2-f973-4326-a22b-d0b0d9b6bfe7) [facemesh.fbx](/attachments/c71d5663-ae2f-4c8d-8e16-be3aefa2a682)
Mikhail Matrosov added 1 commit 2023-10-08 01:16:26 +02:00
Mikhail Matrosov changed title from Preventing import of duplicate shape keys to FBX: Preventing import of duplicate shape keys 2023-10-08 19:54:55 +02:00
Member

I think I've got to the bottom of what the issue is that causes all the duplicates.

There are a number of 1-many relations between FBX nodes that connect each Mesh to each Shape that the FBX IO addon imports as a Blender ShapeKey:

1 Mesh to many BlendShapes
1 BlendShape to many BlendShapeChannels
1 BlendShapeChannel to many Shapes

What FBX appears to do, which Blender is not doing, is to ignore or overwrite all duplicates on the 'many' side of each of these relations.

This also explains how these Unreal exported FBX get away with having 2 Shapes assigned to each BlendShapeChannel while also having a FullWeights array containing two elements where the second element is some unknown value. Both of the assigned Shapes are the same Shape, so FBX only considers there to be one Shape assigned to the BlendShapeChannel, so only reads the first element of the FullWeights array.

I should be able to put a patch together that does this within a few days if you want.

I think I've got to the bottom of what the issue is that causes all the duplicates. There are a number of 1-many relations between FBX nodes that connect each `Mesh` to each `Shape` that the FBX IO addon imports as a Blender `ShapeKey`: 1 `Mesh` to many `BlendShape`s 1 `BlendShape` to many `BlendShapeChannel`s 1 `BlendShapeChannel` to many `Shape`s What FBX appears to do, which Blender is not doing, is to ignore or overwrite all duplicates on the 'many' side of each of these relations. This also explains how these Unreal exported FBX get away with having 2 Shapes assigned to each `BlendShapeChannel` while also having a `FullWeights` array containing two elements where the second element is some unknown value. Both of the assigned `Shape`s are the same `Shape`, so FBX only considers there to be one `Shape` assigned to the `BlendShapeChannel`, so only reads the first element of the `FullWeights` array. I should be able to put a patch together that does this within a few days if you want.
Mikhail Matrosov changed title from FBX: Preventing import of duplicate shape keys to WIP: FBX: Preventing import of duplicate shape keys 2023-10-09 11:35:09 +02:00
Author
First-time contributor

Closing due to !104954 fixing the issue

Closing due to !104954 fixing the issue
Mikhail Matrosov closed this pull request 2023-10-18 19:11:49 +02:00

Pull request closed

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#104939
No description provided.