I have been using the Mixamo YBot for quite some time now. The YBot has TWO meshes as children: Alpha_Joints and Alpha_Surfaces. Notice the ybot hierarchy
Here is an even worse example where it look like the gltf is actual RE-PARENTING the secondary duplicate to another mesh altogether. Take a look at the robot hierarchy:
Yes this cause problems, can’t find proper mesh or node by name.
Even screws with GLTF my parser… I get a reference to the node, expecting a mesh now is a transform node
What about re parenting the node, how can that be in purpose
That really screws thingy up… loving for my mesh under the parent it was designed with , now all of the sudden it’s move to another node all together . That has to be a big
Yo @bghgary … Man this change really sucks for me. Now i am going to be stuck on an ALPHA version babylon.js. Even the override mesh was better than this
May some workarounds can be put in place.
First and foremost, cant have duplicate names, that is just screwy. Maybe append “Skin” to the additional mesh node you are creating (STILL SCREWY). Just to change my hierarchy like that. Still WOW
And second… maybe put some like linkSkinnedMesh reference on the transform node so i at least know where you moved my skinned mesh to
Or can we have a LEGACY mode and go back to that override mesh. That was way better than just reparenting my hierarchy and having all these duplicate nodes/skinned meshes
Just trying to think of a way to salvage my toolkit and YEARS OF WORK
I can update the name, but it’s a bit tricky because I don’t know which name would be the right one to replace. The extra transform node is there in case that node is being targeted for animation. You can distinguish between them as one is a TransformNode and one is a Mesh.
Maybe, let me think about that.
Override mesh has many issues also. That’s why we did it this way.
I’m sure we can find a solution that works for you.
I think if it was reliable… all skins moved under bones or not. And keep some kind of reference to the skin node on the transform node… Then i could at least make a getter for this.transform and do the checking if this is Really the node i attached the script to.
Here is another example loading a ReadyPlayerMe character. None of the mesh nodes are under the HIPS
That is what is really messed up for me and the way i attach script components to nodes
BTW… Thanks you @bghgary for continued help and efforts with my GLTF Parser and Script Component system (PAST AND FUTURE). I am sure we can work out something
The way the algorithm works right now, it always updates the skinned mesh as a child of the parent of the skeleton root (except when the skinned mesh is the skeleton root parent). The skeleton root is either computed via common ancestor or specified by the glTF via the skeleton property. The skinned mesh is supposed to be a sibling of the skeleton hierarchy not inside the skeleton hierarchy.
I like this idea but I’m not sure a reference will be good. It might cause some lifetime issues. Would a callback that fires when the glTF skin node is split into TransformNode and Mesh help?
If there was a link to the skinned mesh on the original transform node, then i guess it would not matter if the the skinned meshed was moved under the root bone or not.
So it comes down to keeping a reference to the skinned mesh on the original transform node.
Even if you give me callback that GLTF is spitting things into a TransformNode/Mesh combo… I would still need to store that reference, right… I guess i could also APPEND Skin to the mesh name then as well ?
Just to clarify… If the skinned mesh and the root bone (skeleton) are siblings (have same parent)
then it WILL NOT reparent the skin under the root bone.
But if the ARE NOT siblings (have different parents) then the WILL be reparented so the skin is under the root bone
Yes, depending on what you are doing. I’m worried adding reference from one node to another will cause them to stay around longer than they should, but maybe it’ll be fine.
Almost.
The first statement is effectively true. The original glTF skin node will be created as a TransformNode. A new skinned mesh will also be created whose parent will be assigned to the parent of the skeleton root, which effectively makes this new skinned mesh a sibling of the skeleton root and the transform node, for this case.
The second statement is not quite right. It should say:
But if they ARE NOT siblings (have different parents) then they WILL be reparented so the skin is undera sibling of the root bone
I think we can start with using the metadata property to hold a reference to the mesh. I will need to be careful to make sure the reference is removed when the mesh is disposed.