GLTF Parsing Is Creating Doubles And ReParenting meshes

Yo @bghgary , @sebavan and @Deltakosh

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

Now as of Version 5.X the Babylon GLTF Parsing screwing things up a bit… Even in the sandbox out side of any of babylon toolkit…

this is how sandbox is now rendering that gltf

For years this model rendered just fine. But as of Version 5 official releases, things are screwy

so something must have changed in the core babylon gltf parsing

Here is sample GLB

ybot_test.glb.zip (1.6 MB)

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:

and in the the Version 5 sandbox

As you can see the Armature_Meshes have actually been moved/reparented to the Skeleton transform node.

This is broken :frowning:

I will investigate tomorrow.

@MackeyK24 This is the new expected behavior. Please check out this doc page.

Are you seeing any issues with this other than the structure changes?

Wait, duplicating transform nodes is on purpose?

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

Read docs … wow… how can that be. How can I reliably know my hierarchy after exporting :worried:

What version number did this change ?

This is a huge issue. This ruins my entire scripting system that relies on doing stuff like this.transform

YO @bghgary … If its supposed to move the skinned mesh UNDER the skeleton. How come these Alpha_Joints and Alpha_Surface is NOT moved under skeleton ?

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 :frowning:

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

Or am i still not quite right there?

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 under a sibling of the root bone

Can we try with a linked reference to mesh node on the original transform node ?

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.

Thanks @bghgary … please let me know as soon as i can test it :slight_smile:

Would have been a good use case for WeakRef - JavaScript | MDN a shame it might not be widly supported enough

PR: Add skinned mesh reference when loading glTF skins by bghgary · Pull Request #12506 · BabylonJS/Babylon.js (github.com)

@MackeyK24 The transform node will have metadata.gltf.skinnedMesh pointing to the associated skinned mesh.

2 Likes

Thanks @bghgary working out great so far. I can tell where my skinned meshes ended up after being split part :slight_smile:

2 Likes