Bug SkinnedMeshRendererConversion, Bindposes, and Reparenting

Alright. I'm really stumped on this one.

So the Hybrid Renderer currently converts skinned mesh renderers by taking the mesh and material, and creating a new entity for it reparented to the root bone with and identity LocalToParent.

This suggests to me that the bindpose of the mesh is computed relative to the root bone regardless of the transforms of the renderer in the broader hierarchy. Given that the bindpose calculation is engine-side, I just want to confirm if this is really the case?

 

Alright. So I figured out what is going on, and I believe this is a bug. The behavior that would make more sense is as follows:
If the SMR is attached to or the child of the root, leave it where it is in the hierarchy and use existing logic, as animations to the root will affect the whole RenderMesh.

If the SMR is independent to the bone hierarchy, then each SkinMatrix needs to be computed by computing the local-to-(root's parent), rather than the local-to-root. But then the RenderMesh doesn't have to be reparented and so it can preserve its transform offsets.

And lastly, if the SMR is attached way down the bone hierarchy, that is nonsensical and should throw an error.

But reparenting currently can break prefabs with transform offsets on the SMRs independent of the bone hierarchy.

 

I'm on latest public release. For reference, this isn't me running into an issue as much as it was me encountering a discrepancy between the Hybrid Renderer and a custom solution I am working on. However, while it is pretty rare, there are cases where having a transform offset be applied to the mesh separate from its skeleton is useful. I believe (but haven't tested) if you were to have an animated character where the smr is a sibling to the root bone, then duplicated the smr, moved it along the z axis, and scaled and offset it such that it was a "big clone with matching movements", I suspect this would work correctly in GOs but completely break with the Hybrid Renderer. (It definitely wouldn't work in the Hybrid Renderer 0.11.) I also believe this may be the cause for this issue: https://forum.unity.com/threads/ava...onverted-during-authoring-conversion.1112773/

 

Alright. So I just tried this with Game Objects, and it turns out that Game Objects exhibit the same breakage issue. So the Hybrid Renderer is correct in that it matches Game Object behavior. However, this is a gross misunderstanding of skinning across the entirety of Unity (and you aren't the only ones which I will explain in a bit).

To understand the real problem, you need a prefab structure with a hierarchy somewhat like what I have:

• Character (with Animator)
  • Body (SMR)
  • Skeleton Transform (skeleton ref space)
    • Hips (root bone)
      • Spine (bone)

Now let's assume that Body has the identity transform. If you modify that local transform of the Body in the editor, the transform moves, but the actual skinned mesh stays put. Now, reset that transform back to identity, and add a cube as a child to the Body. Now modify the local transform of the Body again. Notice how the cube moves will the skinned mesh stays put? The transform relationship is completely broken. This is fundamentally incorrect. The skinning process should only affect the raw mesh data, and have nothing to do with the local-to-world transform. Yet here we see it completely nullify the local-to-world transform for the skinned mesh.

The reason this likely happens is two-fold. First, Unity does not correctly differentiate between the root bone and the skeleton reference space (the parent of the root bone or world space if the root bone doesn't have a parent). And second, DCCs also exhibit a misunderstanding by making the skinned mesh renderer either attached to or a child of the root bone. This is nonsensical, and it completely defeats the purpose of the root bone actually being a bone with a bind pose and vertex influences. But it is easy to correct for by multiplying the bind pose by the local-to-root to get the skin matrix instead of multiplying by the local-to-skeletonReferenceSpace which would be the correct transformation. And really, DCCs should be putting the skinned mesh objects as children to the reference space. I know of at least one DCC that does that, and usually certain objects need to have identity transforms in order for Unity to import it with correct results.

The problem here is that Unity forces all skinned meshes to behave similarly to the nonsensical interpretation by discarding the mesh's transform and treating it as a child of the root bone.

 

Yes. I am doing that in my solution, in which I rewrote skinning from the ground up: https://github.com/Dreaming381/Kinemation-Skinning-Prototype

I fully understand what is happening now. But for a long time, Unity's behavior has made it difficult to debug other skinned mesh import issues. It wasn't until I understood what the Hybrid Renderer conversion was doing and why that I understand the cause of many past frustrations. To be clear, there were other issues in those imports. But this behavior obfuscated them.