GLTF Export Bug: Skinning has errors

So I exported a GLB via BJS GLB serializer, and re-imported it back in BJS to test it. Turns out the mesh skinning has issues. I could show a video but it says “new users cannot upload attachments”

I think a PG will help looking for the problem on our end.

How should I do this then. Show a PG that loads the original mesh, then exports it as a GLB, then re-imports the newly exported GLB?

Probably easier if I just send the mesh itself?

Here’s the link to the “mutant.glb” btw

A nice repro would be to host your file in a server and udpate this PG to point to it:

https://playground.babylonjs.com/#SYQW69#391

This doc can help you regarding hosting the asset:

https://doc.babylonjs.com/resources/external_pg_assets

There you go https://playground.babylonjs.com/#SYQW69#397

1 Like

Thanks.

I think at this point I need to summon @Drigax :slight_smile:

1 Like

Bizarre, the gizmo is broken after reimporting and even throws exceptions if you try to see whats up with the bone node positions…
https://playground.babylonjs.com/#SYQW69#399

I’ll try to take a look today

2 Likes

I think I figured out what’s going on here, currently the vertices appear to be improperly skinned to joints in the skeleton:


https://playground.babylonjs.com/#SYQW69#405

Looking at the working source glb we can see that the joints array is in descending order:

Which breaks our output glb, since we didn’t modify the JOINTS_0 attribute to match the new joints array:

I’ll look at how we can rewrite this attribute to match the actual scene, this probably should not be preserved from the source mesh data.

1 Like

Problem was definitely with how we were exporting our joint order:

Turns out we shouldn’t assume that order of elements in Skeleton.bones is equivalent to the actual Skeleton joint order, which is indicated by the individual joints via Bone.getIndex().

Changing this logic so that we now properly export bones in increasing index value appears to address the issue properly.

3 Likes

YASSS!