Bug SkinnedMeshRenderer Conversion failiure/quirks

Not really sure I understand whats going on behind the scenes but conversion will fail in the following scenario:

In my tests, a character where there is the following setup, if GameObject B or C is deleted, and then "recreated" by manual means, the data within it is somehow different from dragging out the default imported character from the project window. Note I am replacing the mesh with the original, as well as updating the root bone field and ensuring the material is compatible.

Character Root [GameObject A]
- SkinnedMeshRenderer [GameObject B] | MeshA
- SkinnedMeshRenderer [GameObject C] | MeshB

The bindposes and bones list will be mismatching, causing the mesh conversion to fail in both the hybrid renderer conversion system and animation's own conversion. If you drag out the appropriate prefab child gameobject and replace it, the bindposes and bones will match, but there is a further failure within the skeleton map & SkinnedMeshToRigIndexMapping that is a bit hard to decipher.

Of course the easy fix would be dont delete and recreate anything in the child hierarchy, but for situations where a model undergoes revisions, there's not really an easy way to avoid this? Also seems a bit brittle of the conversion system or something going on that isn't readily apparent with how unity treats skinned meshes.

 

It could be that the SkinnedMeshRenderer Component's hidden hierarchy of bones does not match the bone hierarchy of the 'updated' Mesh. Even though it can seem that the Mesh's hierarchy has not changed, it can occur that it has incidentally.

I have encountered this myself and used the following sources to write my own tool to reorder the hidden bone list in the SkinnedMeshRenderer Component.

https://forum.unity.com/threads/replacing-mesh-in-skinnedmeshrenderer-causes-deformation.351474/
https://gist.github.com/tsubaki/ea6ece1cd9a851ff977e#file-skinnedmeshupdater-cs

 

Thanks, I suspect this is correct but some quick testing of this results in the same errors(will definitely need to investigate further).
- edit; I was just forgetting to set the bone array after making a new ordered copy , errors fixed.

Is the bone hierarchy being reordered a bug or something? In that original thread and hippo's subsequent one, I haven't seen once instance where this obscured change of format is actually useful, intended or serves some purpose?

 

I am glad I was able to help you resolve the issue.

When I encountered this, I suspected it was due to the source .fbx being imported in a 3D modeling software for editing and eventually exported, that was different from the 3D modeling software it was originally exported from.

An unexpected reordered bone hierarchy is far from useful in this instance, especially due to the lack of a built-in reordering tool. But I guess that is the risk we take when switching between 3D modeling software.

 

Though I listed cases where models undergo DCC edits, this particular case was just me deleting unused SkinnedMeshRenderer containing gameobjects at the time(as I didn't know then how to find the associated entity from the conversion process split), and then upon learning how, attempting to recreate them. There werent actually any source model changes or imports.

Tempted to report the behaviour as a bug but its seemingly survived for so long, not sure if its worth the trouble.