Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLTF import alters scene hierarchy for skinned items #1652

Closed
Mondkalb1 opened this issue May 24, 2022 · 4 comments
Closed

GLTF import alters scene hierarchy for skinned items #1652

Mondkalb1 opened this issue May 24, 2022 · 4 comments

Comments

@Mondkalb1
Copy link

Mondkalb1 commented May 24, 2022

Describe the bug
When importing a GLTF file in Blender, it forces all objects that are skinned to a specific Armature to be children of that Armature in the hierarchy.

Contextual image:
The left side shows the scene how it was constructed in blender natively.
The right side shows that same scene after being saved to gltf, and then imported again into a new empty scene in Blender.
issue

To Reproduce
Steps to reproduce the behavior:

  1. Download the attached cubeBones.zip and extract it
  2. Open the cubeBones.blend file in Blender
  3. Observe the hierarchy. We have "Cube" under LOD_0 node, and "Cube.001" under LOD_GEO node.
  4. Export this complete scene as .gltf
  5. Clear the workspace so that you have an empty scene without default cube
  6. Import that newly saved .gltf file
  7. Observe the hierarchy. We now have both "Cube" and "Cube.001" under the "skel" armature. They don't belong there.

Expected behavior
The scene hierarchy of the objects shall be preserved. They must not be force-moved to be in the hierarchy under the skeleton, but remain where they were.

.blend file/ .gltf
cubeBones.zip

Version

  • OS: Win 10
  • Blender Version 3.1.0

Additional context
This may be by convention and design, as we noticed the FBX import does this also. However, it is critical for us that the actual structure is maintained. We were also able to determine that the gltf export accurately writes this hierarchy correctly, only during the import into blender does this reshuffling happen.

Ideally this would be an optional boolean toggle to disable this default behaviour.

@julienduroure
Copy link
Collaborator

Hello,
There is no easy answer.
Current way of working, with scene hierarchy change, is an intentional behaviour, trying ot follow both guidelines.
glTF and Blender are not using the 100% same convention for skinned mesh.

@Mondkalb1
Copy link
Author

Mondkalb1 commented May 24, 2022

@julienduroure Thank you for the insight. I had a suspicion it would be by convention.

We may look into a small modification ourselves then, would imp\gltf2_blender_node.py be the place to start looking? Any recommendations/suggestions? Thanks again.

If we get anywhere we'll shoot a PR back for review.

@scurest
Copy link
Contributor

scurest commented May 24, 2022

This is done for correctness. The main reason is it achieves the glTF requirement that only the joints in its skin (not the node where it is instantiated) affects the transform of a skinned mesh. The notion of a skinned mesh being a child of LOD_0 and affected by LOD_0's transforms does not exist in glTF.

The place where it is actually moved is move_skinned_meshes. node.py and mesh.py files also currently assume an arma will have been created before the mesh it affects, and mesh.py skins meshes into its arma space on the assumption it will be a child of the arma.

@julienduroure
Copy link
Collaborator

No issue here, not sure there is something that can be done. Closing. Don't hesitate to comment if you want to add some extra infos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants