Skinning issue in blender but not in unity. How is it possible?

Hi, I spent my day try to resolve this twisting skinning issue but didn’t solve it.

My tail bones are not twisting as you can see, the Z axe is always up. The deform bones have copy transform constraints on bones which have “damped track” and “stretch to” constraints. If I disable the constraints and move manually the def bone of my tail base, it’s ok but since I activate the constraints the skin twitst but not the bone. I exported it with the twist skinning issue to see what happends in unity.And surpris! In unity the skinning is fine. So I re-import my fbx on blender et as in unity the skinning is correct too.

So I deduce that blender misscalculate the skinning of def bones sometimes because of the constraints : the bones have correct rotations but the skinning dont get it, or I miss something ? Is someone can help me tu understand please ?

Thank you.

P.S: the twist skinning happens only in a short range of rotation, I think it’s linked to the damped track solving P.S2: sorry for my bad english

I suspect you have a weighted control bone, which you forgot to disable deform on, and that the weights on this bone are dropped on export to Unity, since it only supports 4 vertex groups, and the accidental weights are too low to keep. To test? “Limit” operation in weight paint, limit to 4 groups, see if issue persists.

Another possibility is you’re using preserve volume in Blender, but not in Unity (I don’t believe Unity supports quaternion skinning.)

Hi thank you for your answer.

I already did the limit vertex group to 4 and I only export deform bones. I checked for the preserve volume option and it’s unchecked as I thought. Or may be there is another option somewhere else ?

I don’t know. Those are the two ideas I have for why the original would deform differently than the reimport, with the same pose.

If you’re willing, I wouldn’t mind looking at the file to see if I could troubleshoot it further. If Blender is doing something wrong, it would be a really weird place for it. Regular old skinning is the simplest algorithm in the world, hard for any bugs to find a foothold.

How can I send you my file ?
My rig is based on rigify. I modified it in order to export it in game editor with less bones as possible. And I reversed the tail def bones order because I had issue in blend animation in the animator controller of unity. I dont know why rigify did generate bones with a non conventional directions. I’m new blender user. May be I did a wrong thing but I can’t find what it is.

Thank you.

If it’s deforming differently on export and reimport, there’s probably nothing you did wrong-- I’m curious as to what it might be though. Rigify generates bones based on the axes you give it with your metarig. You can share a file by hosting it someplace and posting a link, if it’s too large to host right here on BA (although it’s usually a good idea when troubleshooting a problem to reduce the file to the minimum needed to reproduce the problem anyways.)

you can find it here :

Thank you for your time :slight_smile:

I’m still looking. I’m not very familiar with the rigify rig at this point, and even less familiar with a rigify quadruped rig. But part of the problem is that the Blender .fbx export is really poor. It’s not accurately representing your deform transformations. The armature in the export/re-import has very different transforms than the armature prior to export. When you give it the same transforms, it shows the same problems. (The main issue is that defTail.001 has some translation, when it probably should not. The question that I’m still working on is, where does it acquire this translation from? And also, why is translation apparently turning into twist? Even in regular deformation, with constraints disabled?)

There are paid addons that purport to give improved .fbx export, and people that I know that have purchased them have reported that they do. Of course that’s not going to help you here-- your problem issue isn’t poor .fbx export, it’s weird rigging. If anything, the poor .fbx export is protecting you from this problem.

Edit: and, I suppose I’m going to take a break. Which means there’s every chance I won’t get back to it-- maybe I will, I dunno. Thanks for sharing the file, I find that weird situations like this are how I end up learning best.