-
-
Notifications
You must be signed in to change notification settings - Fork 21.5k
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
Blender to Godot Import - Skeleton3D node not created when using objects parented to bones #81601
Comments
The bone has to be weighted to vertices of a mesh or exported using the "fake skins" method KhronosGroup/glTF-Blender-IO#822 to be converted to the "blender style" armature. From a technical point of view, I'm not how to make your request work. Suggestions welcome. |
Okay I read through it, but still unsure if I understand everything. I think what I did in the second part of my post is basically a fake skin? I'm just not sure why the child objects of bones create new bones inside of Godot. The BoneAttachement nodes are created as they should, but why are new bones instanced in their place? With a simple model, this is a bit annoying, but still manageable, but with a more complex rig, all these new bones really makes a mess. I understand that most models/rigs uses armature deform and are not affected by this issue, but the workflow to assign vertex to vertex groups in Blender is quite tedious, as opposed to parenting, which can be done in bulk and with separate objects (not mentioning the "parent to closest bone add-on"). For "hard surface" models such as robots, mechanical devices and other props, it would be nice for the parenting workflow to also properly generate the Skeleton inside Godot on import. I'm not well versed enough in all this stuff to provide suggestions, but wouldn't there be any way to use suffixes? I know we can create colliders by adding "-col" at the end of an object name for instance. Wouldn't there be a way to have it so that if we add "-skel" or "-bone", then Godot could still create the skeleton and bones properly? I apologize if this isn't a Godot issue, or if it's not an issue at all. Perhaps I'm simply using the wrong workflow. |
IIUC simply put, Blender/glTF/Godot use different bone coordinate systems, so you always have to create some fake visual bones. If you export selected armatures + cubes, as it was explained there, you will get I think at least similar and same animated structures: |
Ahhh I see! Then it is all expected behavior. I think the reason my armature looks a bit messy is because I applied location to all objects, so the origins were all in the same location, so the new bones were all pointing towards it. I think the issue can be closed then. Thank you all for your help. Should I close the issue myself or does someone else need to do it? It's my first time actually creating an issue on GitHub. |
Feel free to close the issue yourself, if you believe, that it is resolved. |
What I thought was an issue is actually normal behavior. Issue closed. |
Godot version
4.2.dev4
System information
Godot v4.2.dev4 - Pop!_OS 22.04 LTS - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2080 (nvidia; 535.104.05) - 12th Gen Intel(R) Core(TM) i5-12600K (16 Threads)
Issue description
When an asset only has objects parented to the bones of an armature, a skeleton won't be created and the bones are simply treated as Node3D objects:
A workaround for this is to create another mesh, or a single vertex, and do a "Set parents to - Armature Deform - With automatic weights". Then the skeleton will be added to the scene tree. However, all parented objects will have a duplicate of themselves created in the form of a new bone. This is as opposed to what the documentation says here, "A bone can be the parent of an object in Blender; this relation is exported as a BoneAttachment node in the Godot scene."
I only created a single issue for these two things as I think they might be related.
Steps to reproduce
No Skeleton Issue:
New bones from objects:
Minimal reproduction project
N/A
The text was updated successfully, but these errors were encountered: