Answered

Horse Animset Pro - Incompatible rig error

Anonymous 11 months ago updated by Peter - Soxware Developer 11 months ago 9

After opening the horse model from MalberS Horse Animset Pro, I select an animation clip from out of its animator, and drag it into the Import Clips dialog.  For what appears to be every animation clip on the horse model, it gives an error saying "this clip of type "generic" uses a different rig than the animated GameObject and is thus not compatible."

Well, no, it doesn't.  If the rigs were incompatible, it would not animate the model properly in Unity, but it does animate it just fine.  And even if that were true, you would think that an animation editing tool would come with a feature to remap the bones of the animation's rig onto the object's rig in order to make it compatible, rather than just shutting the user down cold like that!

Unfortunately, as UMotion does not come with source code, I'm unable to do anything to track down the problem besides reporting an asset that reproduces it.

UMotion Version:
1.22p14
Unity Version:
2019.4.12f1

Answer

Answer

Hi,

thank you very much for the additional information. Meanwhile, thanks to Malbers (the creator of "Horse Animset Pro") I also got access to the demo scene and take a deeper look.

Solution

The error message UMotion is throwing is kinda correct, a detailed explanation follows below. In order to edit the horse animation, just instantiate the horse model (not the prefab!) and use that for your animation work. You can find the model in the "7 - Models" folder:

Explanation of whats going on

The error message UMotion is throwing is correctly indicating, that the rig used in the animation is indeed different to the rig of the horse prefab. You can see this in the following screenshot (H_Walk Right is the rig of the animation):

Notice how the animation's rig starts with a bone named "CG", while in the prefab the "CG" is somewhere deeper down the hierarchy. Animations use "transform paths" that are relative to the Animator component for addressing. A transform path looks something like this "CG/Pelvis/L Thig". UMotion validates those paths when trying to import a generic animation. As the prefab has no "CG" bone as a child of the animator component, it correctly shows the error that the rig is not compatible. I am going to improve on the error message so that it indicates this in a more clearer way in a future version of UMotion.

Also please notice, that the original model has the correct rig (see first screenshot). That's why it works when you use that.

So why is Unity still able to play this animation on this prefab with the modified rig? I honestly don't know because even Unity's built in Animation Window displays the bones as "missing":

Another thing, as I mentioned earlier, would be if instead of shutting you down cold, UMotion gave you the opportunity to remap the bones in the animation so that they would fit now.

Yes remapping the paths would solve the import issue, but note that all the paths would also be changed in the exported animation. That would mean that your animation would only work with the prefab's rig, not with the original model anymore. In most cases, you do not want that and instead want to use the correct rig for editing the animation.

Thanks for reporting this. Let me know in case you have any follow-up questions.

Best regards,
Peter

Answered

Hi,

thank you very much for your support request.

When assigning the horse to the Pose Editor (for the first time), you need to make sure that you drag & drop the correct transform. You need to drag & drop the transform that has the Animator component assigned (the same animator component that also contains the animations). If you drag & drop a different transform (e.g. a parent transform of the Animator component), then the rig in UMotion is not compatible with the imported animations rig as it contains one more transform in the hierarchy.

Hope this makes sense.

In case you are not able to solve this, I would love to take a closer look (either by sending me a small repo project, or by providing some further information in the form of screenshots or a video).

Best regards,
Peter

Not sure what happened, but I replied to this 3 days ago with a video showing that I was doing exactly what you suggested and the message was still coming up.  It said it was being held in moderation, but now it appears to have vanished.  Any idea what's going on?

Strange, I did get an alert that you've posted something. But when I wanted to check the message, it wasn't visible to me (so I thought you might have solved the issue and meanwhile deleted the message). Could you try to post your message again, please? If it doesn't work (maybe it's due to the video?), you can also use the email support form.

I'm sorry for the inconvenience.

Best regards,

Peter

Here's the video again, in a 7z archive because the original didn't fit under your software's size limit. It shows me selecting a clip from the animator on a root-level GameObject, then setting that object as the object to animate in the Pose Editor, trying to drag the previously-selected clip into the Import Clips box, and getting the error.  The scene is a stock demo scene from Horse Animset Pro, as mentioned in the first post, and can be easily reproduced if you have a copy of the asset.

record_000002.7z

Unfortunately I do not have a copy of Horse Anim Set Pro, but I'm going to contact the asset's publisher, maybe I get access to that demo scene.


UMotion does simply compare the transforms that are within the UMotion project and the transforms of the animation one by one. If they do not match from the beginning, then you are going to get this error. So while waiting for a response from Malbers, could you show me a screenshot of the horse's transform hierarchy (ALT + click on the arrow to expand the whole hierarchy)? Please also select the transform that has the Animator component attached and make a screenshot of it.


Thanks.


Best regards,
Peter

There's more, but I assume the bones are what you're looking for.  What did you want to see in the screenshot?  Hope this is enough.

One thing that would really help is if the error box reported useful information, such as the nature of the mismatch that it detects.  Another thing, as I mentioned earlier, would be if instead of shutting you down cold, UMotion gave you the opportunity to remap the bones in the animation so that they would fit now.  (Editing the animation is kinda something you expect an animation editor to be able to do, no?)

Answer

Hi,

thank you very much for the additional information. Meanwhile, thanks to Malbers (the creator of "Horse Animset Pro") I also got access to the demo scene and take a deeper look.

Solution

The error message UMotion is throwing is kinda correct, a detailed explanation follows below. In order to edit the horse animation, just instantiate the horse model (not the prefab!) and use that for your animation work. You can find the model in the "7 - Models" folder:

Explanation of whats going on

The error message UMotion is throwing is correctly indicating, that the rig used in the animation is indeed different to the rig of the horse prefab. You can see this in the following screenshot (H_Walk Right is the rig of the animation):

Notice how the animation's rig starts with a bone named "CG", while in the prefab the "CG" is somewhere deeper down the hierarchy. Animations use "transform paths" that are relative to the Animator component for addressing. A transform path looks something like this "CG/Pelvis/L Thig". UMotion validates those paths when trying to import a generic animation. As the prefab has no "CG" bone as a child of the animator component, it correctly shows the error that the rig is not compatible. I am going to improve on the error message so that it indicates this in a more clearer way in a future version of UMotion.

Also please notice, that the original model has the correct rig (see first screenshot). That's why it works when you use that.

So why is Unity still able to play this animation on this prefab with the modified rig? I honestly don't know because even Unity's built in Animation Window displays the bones as "missing":

Another thing, as I mentioned earlier, would be if instead of shutting you down cold, UMotion gave you the opportunity to remap the bones in the animation so that they would fit now.

Yes remapping the paths would solve the import issue, but note that all the paths would also be changed in the exported animation. That would mean that your animation would only work with the prefab's rig, not with the original model anymore. In most cases, you do not want that and instead want to use the correct rig for editing the animation.

Thanks for reporting this. Let me know in case you have any follow-up questions.

Best regards,
Peter

So why is Unity still able to play this animation on this prefab with the modified rig? I honestly don't know because even Unity's built in Animation Window displays the bones as "missing":
If I had to guess, it probably does a search for the root bone by name if it isn't there as a direct child, in order to support scenarios exactly like this one. (If you add in a bit of special-case logic that does exactly that, does the animation load correctly?)
Yes remapping the paths would solve the import issue, but note that all the paths would also be changed in the exported animation. That would mean that your animation would only work with the prefab's rig, not with the original model anymore. In most cases, you do not want that and instead want to use the correct rig for editing the animation.

Well sure.  You'd probably want to do this on a copy of the original animation clip for exactly the reason you just gave, (or even have UMotion warn you that this is a destructive edit and you should probably make a copy,) but it would still be very nice to able to do it! Especially as such a feature would make it possible to do more interesting things, such as adapting this animation to another quadruped model with most of the same bones that just have a few different names. That's trivial with a Humanoid rig, but with a generic one you really need a remapping solution!

If I had to guess, it probably does a search for the root bone by name if it isn't there as a direct child, in order to support scenarios exactly like this one. (If you add in a bit of special-case logic that does exactly that, does the animation load correctly?)

The strange thing is, that the Animation window also does not treat this special-case which makes me wonder if it is really an intended use-case. Generally speaking, I think it's a cleaner approach to keep the rigs equal.

Especially as such a feature would make it possible to do more interesting things, such as adapting this animation to another quadruped model with most of the same bones that just have a few different names. That's trivial with a Humanoid rig, but with a generic one you really need a remapping solution!

Just re-naming the transform paths won't enable animation re-targeting from one generic to the another generic model. Bones can (and will) have completely different local axis between the two generic models. A one to one transition of the animation curves is thus not possible. If you want to learn more about how Unity's humanoid animation system does animation re-targeting, I highly recommend this blog post: https://blogs.unity3d.com/2014/05/26/mecanim-humanoids/

With that being said, there are definitely some edge cases where remapping just the paths would be useful, but it might also cause lots of confusion on the end-users side (they will also think that this can be used for generic animation re-targeting). So for the moment, I do not have plans on adding this feature.

Best regards,
Peter