Page MenuHome

Addon feature incorrectly built - Malfunctioning Rigify Horse
Closed, InvalidPublic

Description

System Information
Operating system: Windows 10
Graphics card: NVIDIA GTX 1060 6GB

Blender Version
Broken: v2.82.7

Worked: ?

Rigify Addon Version
Broken: 0.6.1

Short description of error

Rigify addon built the horse part anatomically incorrect. Hind leg is missing an important joint at the lower hinds. Forelegs and hindlegs are built the same way in that area. See screenshot sketch.
Trying to fix the issue myself didn't work/resulted in advanced rig not being creatable, trying to fix in the advanced rig is beyond my knowledge and understanding, screwed up the tweak bones, bone relations, rig was completely broken. Nobody else on the Blender Discord Server could help me with this, either.

Exact steps for others to reproduce the error
Open up a new file. Import the horse rig. Enter edit mode. Subdivide the toe legs on the hinds and pull them to the same joint height and angle as the forelegs.
Advanced rig creation will fail.

This is NOT a feature request. It is a report to fix this malfunctioning bone setup that cannot be fixed by an average user. People cannot properly work with this! I've asked dozens of horse people and searched through sources and all agreed with me that there indeed is a joint missing where the hind fetlocks of a horse would be. Just like it does already have a front fetlock, it also does have a hind fetlock. See resources. Please fix this. It might be easier for the addon developers than someone who doesn't know how to change the addon properties at all.

Revisions and Commits

Event Timeline

Demeter Dzadik (Mets) changed the task status from Needs Triage to Confirmed.Wed, Jun 24, 7:15 PM
Demeter Dzadik (Mets) claimed this task.
Demeter Dzadik (Mets) triaged this task as Low priority.

Would it be correct to simply copy-paste the set-up of the front legs to the hind leg? Here's what that gives me:


If that seems more correct for you, I can submit a patch with a modified metarig for review (perhaps I should also rename the bones to be a bit more... horse?) and we'll see what happens from there.

Rigify addon built the horse part anatomically incorrect.

I guess whether this can be considered strictly a "bug" will depend on whether it's just a matter of an incorrectly built metarig or a matter of not having a rigify type that can fulfill the purpose. If the case is the latter, then Rigify is doing the best with what it's got, and improving this would require adding a new feature. But it doesn't sound like that is the case, so I will mark as bug for now.

If you'd need any suggestions about the bone names, I'd "translate" their names if you could give a list about them (if that's not too much work). So you can implement them accordingly.
I mostly want this to be officially changed because it would make life so much easier for so many horse creators out there. Thank you!

For now, can you confirm that the metarig in my file gives you the desired results?

I just tested it, and yes, that looks way better. The functionality seems to be okay for me now. If I stumble upon anything troublesome alike, I might come back to this, though.
Just a suggestion, but changing the display preset of "foot_fk.L" and "foot_fk.R" to have the shin object "WGT-rig_shin_fk.L" / "WGT-rig_shin_fk.R" would make it easier to select. (If it just takes a click you might want to change, otherwise just keep it as a feature request).
Thank you for the instant reply back then. My apologies for not checking the file and giving feedback sooner.

@Demeter Dzadik (Mets) i believe would be better to add finger bones at the end of the limb rather than on top of the ik chain. the ik of rear limb would act strange if you do so.
Horses are unguligrades so the reported missing bone, if needed, has to be considered as a finger bone and should be appended after the existing chain.
This is the fix on your file.

J. O. (Papercut) added a comment.EditedFri, Jun 26, 3:21 PM

@Demeter Dzadik (Mets) i believe would be better to add finger bones at the end of the limb rather than on top of the ik chain. the ik of rear limb would act strange if you do so.
Horses are unguligrades so the reported missing bone, if needed, has to be considered as a finger bone and should be appended after the existing chain.
This is the fix on your file.

That is a correct point of view, regarding that horses walk on their toes. However, the hoof has to be grounded. As far as I can see, the IK bone is not on the same height as the foreleg one which would result in weird control mechanisms. Artists also learn that usually all comparable leg joints roam around the same Z value (Blender-wise) for front and back. This could even be transferred in the upper joints not lining up exactly.
(I am not entirely a rigging expert neither is English my first language so I hope I understand you correctly, nevertheless.)
If you're going for the hoof as a finger bone, I am not sure, where you would make the horse move its leg accordingly (Also, front and back do not differ in this exact situation, so why is there a difference?). I'd also consider involving someone else who could say more about the motion itself. (Can ask externally if you'd like).

Edit: Here's an attachment about the hinds when I use the first one of the two test versions.

Whereas the second attachment shows about the same try to get the position as in the one above; resulting in wrong behavior.

Reference:

@J. O. (Papercut) i think you are just using the control in a bad way. That position is easily achieved by rotating the foot.ik in one direction and the heel in the opposite.
All paws in rigify act like that. This is not an issue, could have better automations, but the pose is easily achievable (we animated 3 awarded feature animation with horses, cats and birds using this setup).
I am attaching a screenshot and a posed file to illustrate that.

@J. O. (Papercut) i think you are just using the control in a bad way. That position is easily achieved by rotating the foot.ik in one direction and the heel in the opposite.
All paws in rigify act like that. This is not an issue, could have better automations, but the pose is easily achievable (we animated 3 awarded feature animation with horses, cats and birds using this setup).
I am attaching a screenshot and a posed file to illustrate that.

Ah, alright, yes; now I understand how you mean it, sorry about that. I just got it working for my rig as well.
I still believe that the foot ik positioning is a bit off with this method, though. I imagine trying to put the hooves at an exact point on an uneven ground by using artificial animation, for example would result in quite a struggle since the IK controller is not at the same point where a horse's hoof is placed. Animations would need to be adjusted to a certain offset, which adds up workload for animators and coders who would use game engines to realize that concept. Imagine a human rig trying to place a foot exactly on the ground and having to find an offset position at first because the controller is off.
By duplicating the front leg setup and applying it to the hinds, we'd have a result of all four controllers sharing about the same Z-Location. This would make it easier for written code to detect a position and placing it correctly. It would block people that plan doing this in the later run, making it a harder issue to tackle than using the first setup version. For keyframe animation, people would go for the visible setup, but a machine cannot see this and has to be adjusted. Not very practicable in my pov.

Ivan Cappiello (icappiello) closed this task as Invalid.EditedMon, Jun 29, 9:16 AM

I am closing this as invalid since after inspection this sounds more likely a feature request rather than a bug.

We consider a bug something that the tool is designed to do and doesn't. In this case the tool is doing exactly what it was designed for. So either you consider this a current limitation or a feature request (as i do).

@J. O. (Papercut) fixing the foot controller placement is easy after rig generation:
• select the controller
• enter edit mode
• position it where you need

front_paw and rear_paw samples has to be general purpose rig_types. So it's rather difficult to forecast what the user is trying to achieve. I am not saying this is the best solution in the world but from our experience (as reported in my previous posts) there is no current limitation on the pose to be achieved and body mechanics.

some upgrades can be considered, but always looking at the whole picture first. I think the tool will benefit of an extended ik control placement method on metarig itself but there are already lots of option to cover this including the post fix i described few lines above.

feel free to file a feature request to open a discussion about it.

Alright, please let me explain.
I see that you might have misunderstood the original reason I was asking for a fix, because there was a missing joint, in the first place.

I do understand how to fix the foot controller, and I appreciate your quick guide to doing so.

What I was aiming for to achieve by submitting this report is a rig that contains all vital joints in the hinds, just like the front leg does, so that there is correct control over its feet. You can't remove a joint at the human ankle and say it all works fine because you don't use human rigs often. The file from Demeter Dzadik (Mets) with just the copy of the front leg was okay, enough, fixed it. It was a simple idea, but that was just what was necessary. I was hoping this would get implemented because I know how horses walk like and how they work. The first one was the fix already and it leaves me completely saddened that this was not just seen as done, implemented, shared for everyone to use. It was a bug to fix, simple as that. I was further on trying to explain to you why the second try to approach this one is incorrect - because the front and hind leg work similar and thus should be rigged similar in that region.
Your approach about the walking mechanism of a horse in general is not incorrect about the theory of a horse walking on its fingernail - but a horse needs to stand with full weight on that toe on all times it's standing still. It cannot lift its hoof that easily. The approach you did was confusingly complicated and I wouldn't have seen this as a beneficial improvement at all.

Only the part where a human upper arm or upper leg is would be different for the horse.
I wouldn't have reported this as a bug if I wasn't having issues with animating a horse as realistically as I could with the current rigify input, if it was just an idea about further improving the rig I would have made a feature request. But this is something vital, in my point of view, as it limits the animation further down. We don't have horses like in "My little pony" where there is not such thing as a horse's pastern that is between hoof and fetlock. I know a lot of places where horses are not known as well as humans and being animated incorrectly, rigged incorrectly, modelled incorrectly. It is normal because we are no horses and there are less people knowing about horses than there are for humans.
I hope you understand me correctly, now.
Look at the original attachments and think about it. Why does the rigify horse have no fetlock joint if the real horse does have one and bends its leg at that position? I am not asking for a super fancy new creation. Copy/Pasting the front lower leg setup is enough to make it all work as it should. I know, the change looks minor in your point of view and is barely noticeable if you're not a horse enthusiast and know a huge lot about them, but it is missing indeed and it's limiting us horse people that are working with rigify.

I know nothing about horses, but you sound like you do, so in hopes that you've convinced Ivan, I've submitted the patch, but I'm not calling any shots here :p

Although I did take the liberty to rename the bones, see the patch for that and feel free to make suggestions there if I missed the mark.

as i stated this is not a bug. The metarig acts as designed.
We can debate rigify rear paw has a poor design and create limitations, but the reported issue is not considered a bug.
Moreover this limitation are not restricted to Horses (and other unguligrades) but extends to all quadrupeds setup.

let's try to make some light on why this is done like this:

• the setup is based on comparative horse-human anatomy, so the bone naming and placement reflects the corresponding human setup. This has been done like this to make easier for basic users understand how rigify works. That setup is a derivative of arm and leg.
• in a comparative anatomy setup, the patch by @Demeter Dzadik (Mets) moves the knee off its position making the whole ik ignore the upper part (equivalent to human thigh). This is not applicable to front leg since in the same comparative setup that part correlate to shoulder and arm and the ik should stop before shoulder.

• i don't think a bone is missing here. in my opinion this is a lack of automation at control level. In effect would be better to auto-counter-rotare the heel according to the foot. If we do so, the setup should work as expected. If still needed a super_copy (hoof) bone can be appended after the chain as described in my first proposal.

I am attaching a video of the resulting setup and the rig, including the source mesh upon which the metarig was designed. I just added manually the automation. If it works we can decide how to handle this in code.

After further analysis on the test rig i believe there is an issue that persists in this setup. There is one movement that cannot be achieved with the current (and modified) setup that is possible with @Demeter Dzadik (Mets) first one: the rolling back and is the last pose before stance. The heel rotation cannot be compensated by the foot_ik since it should stay in place on the floor.

F8655310
the green arrow shows the impossible movement.

i will test further improvements to the unguligrades limb.

This discussion should continue in a correct design thread though since this is a design issue.
Will create a design task and link this page.