- User Since
- Jun 24 2016, 1:06 PM (221 w, 6 d)
Wed, Sep 16
i'd like to tag this as "Known Issue" but seems i can't
@Todor Nikolov (ToshiCG) this is totally not supported by the old (and going to be deprecated) pitchipoy face. Unfortunately the face code is based on unique names, so duplicating a face in the same armature will end up appending .002 and so to bone names that then will not match what rigify face is looking for. This design is totally against all the rigify intents but since as for now there's no complete or easy solution to avoid that we kept it as is until it will be deprecated.
@Todor Nikolov (ToshiCG) seems correct. Probably migrating to new rig types some rigify property got lost. will double check asap
if i remember correctly this was due to a 2.7 rigify limitation in limbs child parenting. It was probably removed by some of @Alexander Gavrilov (angavrilov) clever limb rewrite.
@Alexander Gavrilov (angavrilov) is there a specific design reason for that? can't exactly tell if is a bug or an intended design.
Wed, Aug 26
another UI option could be using the same preference style as pie menus add-on:
i think there should be at this point some way of just disabling the external featureset rather than just removing it. Also a "restore defaults" options would be beneficial. We could include in defaults @Nathan Vegdahl (cessen) features and leave it disabled by default.
Aug 24 2020
if @Alexander Gavrilov (angavrilov) has no objection on code side, i'd accept the patch
This breaks backwards compatibility with previous uses of the rear_paw rig type. This is because the old rear_paw was just substituting in the regular paw, which requires a chain of 4 bones. This new implementation demands a chain of 5 bones. Fixing this backwards compatibility might be possible with some kind of versioning? All that would need to be done is switch any existing uses of the rear_paw rig type to the regular paw rig type. I have no experience with versioning code so I'm not sure if this is possible or a good idea.
The created rig seems to miss some copy rotation constraint that should be set on foot_heel.ik:
Aug 18 2020
Even if the suggested solution seems more UI consistent for an experienced blenderhead, i honestly find that the “install from file” and “remove” buttons makes more sense and are self explainatory for the user. Still there’s plenty of room for improvements. Would be nice to have some UI giudines for preferences from UI team.
Aug 8 2020
In my opinion this design proposal seems to join two separate threads:
Jul 8 2020
in my opinion the two column layout would be more readable.
One thing to consider is what happens if there's not enough room to display the two columns on the screen. Would blender in that case switch back to the single column? if not readability would be compromised.
Jul 6 2020
Jul 3 2020
so this is my proposal to handle the rear_paw. i am attaching a blend file with both metarig and reference rig to be generated.
The rear_paw as sample exists just to give the user a placement idea. It's basically exactly the same super_limb>paw type.
Jul 1 2020
closing it since the design proposal was approved and gone in master long ago
Jun 30 2020
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.
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.
Jun 29 2020
@Demeter Dzadik (Mets) if i remember correctly, palm should search for its siblings (meaning all unconnected bones that shares the same parent) and try to search for them in a direction starting from the one that has the app property. Naming shouldn't be relevant cause those are all siblings of the same parent. But this may have changed over time or this check is not happening correctly.
I am closing this as invalid since after inspection this sounds more likely a feature request rather than a bug.
Jun 28 2020
@Nathan Vegdahl (cessen), it’s always a great honor when you join a discussion about rigify!
As noted by @Robert Guetzkow (rjg) this sounds like a feature request. The bug tracker is not intended to be used like this.
That said afaik @Paolo Acampora (pkrime) is working on a basic solution to export rigify rigs in an as game friendly as possible way.
There are still some issues related to stretching that probably cannot be totally avoided but at least is a starting point.
Here’s the link:
Jun 26 2020
@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.
@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.
Jun 9 2020
@Alexander Gavrilov (angavrilov) the issue has been reported almost 3 months ago. If there aren't any other objections and you have no other solution on the table, i am going to accept the patch proposed here by @Demeter Dzadik (Mets).
May 20 2020
This raises a backwards compatibility concern; If you want the old behaviour, you have to express that in your metarig explicitly, by parenting your bone to the DEF bone in some way.
@Demeter Dzadik (Mets) i'd like to have some more information about this from @Alexander Gavrilov (angavrilov). I believe he changed the hierarchy for a reason, still this leads to an unintended behaviour (stretching and skewing).
Looking from a different angle, i believe that if the skewing/scaling issue is fixed, the general way the spine works now is pretty nice.
This has been around for a while. And is actually classified as a bug since skewing shouldn't happen. So if @Alexander Gavrilov (angavrilov) has no other clever solution right now i'd be prone to accept the patch.
@Demeter Dzadik (Mets) the only option i'd discard right now is C.
All rigify parts are meant to be moved apart from their socket.
not really sure this is related to rigify.
Can you replicate the issue with a simple armature, or even with the rigify metarig?
May 19 2020
May 15 2020
@Sybren A. Stüvel (sybren) as stated before, i'd prefer as you already did, "Rigify" or "Rigify Utils".
I agree adding this in blender itself would be nice (and would require some more work on the code in my opinion), but until then i think it's better to be clear about who put that in the ui.
May 12 2020
anyway you don't need to do all that stuff to replicate the issue.
this was probably done unintentionally.
I recall basic porting from 2.7 to 2.8 was done by @Dalai Felinto (dfelinto). Probably at that time 2.8 ui wasn't retained to be final. Since then nobody ever cared about moving it back to tools since everyone probably thought that dalai did put that there for a particular reason and/or nobody cared about.
Apr 16 2020
@Keith Boshoff (wahooney) can you please check that your dopesheet options are set like this?
@Keith Boshoff (wahooney) maybe i am missing something, but in your linked file i can delete, move and show all the keys after disabling the "only selected" end enabling "show hidden".
Still this isn't a rigify specific issue and i can't reproduce it on my system.
Moreover some more information are missing in this report and are required to investigate further:
thanks for the super quick reply, @Brendon Murphy (meta-androcto).
if you choose Tools as the default spacebar action, Animation switches to the shift+spacebar and the Tools to the spacebar.
@Keith Boshoff (wahooney) this has nothing to do with rigify itself. If you have suggestions or complaints about how keys have to be shown, please open a separate report so that blender devs can have a look at it.
Those channels are just hidden. By default blender is not showing in dope sheet and graph editor the hidden channels. You either disable the "only selected" end enable "show hidden" option to move and delete keys accordingly, or just avoid using "Whole Character" keying set.
The "Whole Character" keying set is designed explicitly to key all values, even if hidden.
Moreover this has nothing to do at all with linked libraries.
Apr 14 2020
@Sybren A. Stüvel (sybren) can be reproduced in few clicks:
- just add 2 connected bones.
- Enable auto-ik from the property shelf.
- select the last bone and move it using G + mouse
@Sybren A. Stüvel (sybren) as reported 2.82a works fine.
Issue confirmed on OSX. 2.82a isn't affected.
this is not directly related to rigify itself
Any armature with auto-ik option enabled will crash.
Should be reported as a separate issue.
confirm the issue. blender 2.83 alpha (blender-2.83-ad317a5ffdcf-macOS) crashes on OSX.
But this is not related to rigify. Any armature with auto-ik option enabled will crash.
Should be reported as a separate issue.
Apr 3 2020
this should fix the issue.
@Alexander Gavrilov (angavrilov), please just replace the horse.py in the metarigs/Animals/ rigify folder
Apr 2 2020
@Andy (MostHostLA) if you don't need all the new FK options in the new spine, you can use a temporary fix reverting to old spine system.
In order to do so you have to:
issue confirmed. It is probably related to the new rig types.
there are some difference in how the constraints are done in this spine setup vs the old one.
to make it work again as it was before this are the required changes:
Apr 1 2020
Jan 30 2020
Jan 29 2020
since almost every request has been addressed in 2.82 i am closing it as resolved
Are we still taking requests? If so...
Jan 23 2020
Jan 14 2020
discussed this with @Alexander Gavrilov (angavrilov), in his opinion it seems to be basically some kind of variation on gimbal lock or suchlike it for some reason computes the roll as +-180 degrees instead of near 0.
possibly it needs to use the proper swing+twist decomposition math (now that it is implemented elsewhere) instead of whatever it's doing now
Also the widget collection should append or prepend the rig name. If not, when linking multiple characters the collection with same name will be renamed to .001 .002 and so on.
another naming issue is related to overwrite option.
If in overwrite a new name is set (this option is often used to rename final rig after few raw generate tests) the tool work as expected and renames the selected rig and its correspondent python ui, but instead of renaming widget it creates a new set of widgets.