| Age | Commit message (Collapse) | Author |
|---|
|
Introduce a method to annotate types and names of entries in the
`bones` container of rig components and apply it, and other type
annotations, to a number of not very complex rig classes.
- Introduce BaseRigMixin as a typed base class for mixins intended
for use in rig classes (using BaseRig as a parent causes issues).
- Introduce TypedBoneDict that does not suppress the unknown attribute
analysis in PyCharm, and use it in a system of subclasses to
annotate the bones in various rigs. BaseBoneDict is necessary
because the annotation affects all subclasses, so TypedBoneDict
cannot inherit from BoneDict with the annotation.
- Add or adjust other type annotations of rig methods and utilities.
- Fix other warnings, e.g. undeclared attributes, excessively long
lines, whitespace style issues and typos.
|
|
CloudRig has a feature that allows the user to automatically generate
Action constraints that move bones of the rig based on the position
of other bones. This is done by adding and configuring the actions
in a UI panel of the metarig. The feature also supports corrective
actions that activate based on the state of two other actions.
This ports the feature to base Rigify with the necessary changes in
code organization and style, and replacing CloudRig-specific code.
There are also some functional changes:
- The order of action constraints is reversed.
- The way symmetry of LOCATION_X is handed is changed to
match how Paste Pose Flipped works.
- The action slot UI is shown even without a generated rig.
- More alerts in the UI, e.g. for duplicate rows.
Differential Revision: https://developer.blender.org/D16336
|
|
|
|
|
|
Also declare stage names for auto-completion.
|
|
When we enable the Rigify add-on with installed feature sets, we were
trying to register those feature sets as well, but failing because the
feature set list wasn't populated yet; It would ALWAYS be an empty list.
Moving refresh() inside get_enabled_modules_names() might be better.
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D15646
|
|
Group the three reference fields that have to be cleared to
generate a completely new rig in a box. Also clarify the name
and tooltip for Force Widget Update.
|
|
Requested by @dexon, see rBAece39d809ce#339214.
This patch tries to improve a workflow that was hurt by D11356.
One of the goals of that patch was to make the connection between
metarig and generated rig stronger and more reliable, by using
datablock pointers rather than text-based matching. This allows
users to rename their datablocks as they would do with any other
datablock in Blender, so there's much more freedom with naming
when working with one metarig per generated rig per file.
However, this made it hard to duplicate the metarig, make changes
to it, and make a new rig out of it within the same file. Renaming
several datablocks in this case is not an "option", but an unintuitive
necessity.
With the patch applied, when the metarig has no target rig, there is
an option to input a rig name. If something is input by the user, that
name will be used for the rig, the widget collection (by extension the
widget objects) and the rig script, as long as they are not specified.
So, while still requiring a few more clicks than before, the workflow
for duplicating metarigs to make new ones is now much more reasonable:
- Duplicate metarig, make changes
- Remove the datablock references
- Input a rig name
- Generate
If the a rig object with the same name already existed, it will NOT be
overwritten, and the generated rig will have a .001 suffix. This matches
the "new" option of the removed "new/overwrite" options.
Meanwhile, the other workflow of having one metarig per generated rig
per file is not affected at all: The text box for the name input can
simply be ignored on the first generation. It will not show up after
that, since you would never remove the target rig in this workflow.
Differential Revision: https://developer.blender.org/D14757
|
|
|
|
Only consider local datablocks when searching for the rig object,
widget collection and widget objects themselves during generation.
|
|
|
|
Edit mode represents bone orientation via their head and tail
locations, plus a roll value. This math has a singularity in
the -Y direction, resulting in instability and discontinuity
for bones exactly aligned to the Y axis (the tail flips the
deform bones, so +Y is also bad).
The only reliable way to avoid problems is to un-align the
bones via very small offsets in the Z direction.
|
|
Set parent of eye and nose bones to head instead of left ear.
Differential Revision: https://developer.blender.org/D15347
|
|
|
|
Since this feauture is likely only useful for some cartoon-style
characters, make it optional.
Also, move the copy scale constraint from the IK control to a new
child bone; additional complexity is mitigated by being optional.
|
|
This is no longer necessary, see: T98554.
|
|
Split the parent mch bone and its rigging together with the control.
|
|
|
|
change the icons for adding and removing Rigify bone groups. Reviewed By: Aaron Carlisle, Differential Revision: http://developer.blender.org/D11352
|
|
|
|
Some files needed to be changed manually.
|
|
For backward compatibility the option technically defaults to
old behavior, but all metarigs are changed to the new mode.
|
|
For IK controls that move freely in space without being tied to
a parent it makes sense to align the location channels to world
(or root), while keeping rotation channels aligned to the limb
end orientation.
Blender already has a Local Location parenting option for this
very use case, but Rigify wasn't using it. This adjusts the
switchable parent mechanism so that the option works as intended,
and provides a Rigify option that controls its value for IK controls.
Note that now it is possible to enable the Local Location option
directly on the control bones after generation and it will work
correctly - it is not required to enable IK Local Location.
|
|
|
|
|
|
|
|
|
|
If the coordinate space of the eyelids is computed only from the
eye rotation center points and corners, it fails if the center is
close or in front of the line connecting the corners.
Instead, compute the space based on the main eye axis plus the line
between corners, which only slightly changes the result compared to
the previous method, but is more robust.
|
|
See T95597
|
|
Before, 3 Rigify panels:
{F12837079}
After, single Rigify panel with sub-panels:
{F12823002}
Originally mentioned in T88711, where it didn't spark much discussion, hopefully meaning it's non-controversial.
This patch proposes moving the many panels of Rigify into sub-panels under a single Rigify main panel, in order to reduce clutter in the Properties Editor's Armature tab. This also makes it easier to add more Rigify features in the future, since new panels won't make the overcrowding of this tab even worse.
It also unifies some of the available functionalities between edit and pose mode, where limiting a workflow to only pose mode didn't seem necessary.
Reviewed By: angavrilov
Differential Revision: https://developer.blender.org/D13914
|
|
This patch is a continuation of D8519, was also suggested in T88711#1170152.
It adds a checkbox for each feature set in the Rigify Preferences, to disable/enable that feature set without having to completely remove it from the file system.
Challenges that were hopefully successfully tackled:
- Keep list in sync when user manually adds or removes things through the file system instead of the "add/remove feature set" buttons in the UI.
- Avoid re-building the feature set list all the time so that the checkbox states can actually be stored when the user exits Blender.
- Disabling a feature set means calling its unregister function, then rebuilding the rig types and metarigs lists/menus.
- Some renaming slipped in because I found the variable name "feature_set" a bit confusing. If needed, I could split this change into a separate patch or just forget about it, but I think the longer names help here.
Testing would be welcome, since things turned out a bit more tricky than expected.
In a follow-up patch I would like to do a code quality pass, to split the code a bit better here. There is a bit too much stuff in __init__.py in particular. I will get started on that when this gets close to being finalized.
Reviewed By: angavrilov
Differential Revision: https://developer.blender.org/D12260
|
|
|
|
- Clear the IK toe control animation in the relevant operator.
- Allow changing the euler order of finger master control via metarig.
|
|
This reverts commit f0f48da209de08d66fd9e3b311e379687c7ba699.
|
|
|
|
|
|
|
|
Currently the leg rig tries to share one control between IK and FK
modes, which looks as a nice optimization at first, but makes it
impossible to IK/FK snap correctly if the IK foot is rolled forward.
This commit adds an option to generate separate toe controls.
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D5801
|
|
|
|
Existing IK & FK controls only allowed squash and stretch scaling.
|
|
|
|
The overall goal of this patch is to improve the UI/UX of the panel previously known as "Rigify Buttons" which presumably takes its name from the old "Buttons Panel" which is now known as the Properties Editor.
Before:
{F10511640}
After:
{F10511624}
- Make Rigify less reliant on name matching when it comes to maintaining the link between the metarig, the UI script, the generated rig, and the widgets collection. (Use pointers only, names shouldn't matter!)
- Change the "Advanced" toggle button into a real sub-panel.
- Split up the "Rigify Buttons" panels into "Rigify Generation" and "Rigify Samples" panels in non-edit and edit mode respectively, to better describe what the user will find there.
Changes in the Rigify Buttons panel:
- Removed the "overwrite/new" enum.
- If there is a target rig object, it will be overwritten. If not, it will be created.
- If a rig object with the desired name already existed, but wasn't selected as the target rig, the "overwrite" option still overwrote that rig. I don't agree with that because this meant messing with data without indicating that that data is going to be messed with. Unaware users could lose data/work. With these changes, the worst thing that can happen is that your rig ends up with a .001 suffix.
- Removed the "rig name" text input field. Before this patch, this would always rename your rig object and your rig script text datablock, which I think is more frustrating than useful. Now you can simply rename them after generation yourself, and the names will be kept in subsequent generations.
- Single-column layout
- Changed the "Advanced Options" into a sub-panel instead.
On request:
- Added an info message to show the name of the successfully generated rig:
{F10159079}
Feedback welcome.
Reviewed By: angavrilov
Differential Revision: https://developer.blender.org/D11356
|
|
|
|
|
|
|
|
|
|
|
|
The copy_custom_properties() function needs to check if a property is actually a custom property created by the user, or a property defined by an addon. I think we don't want to copy addon-defined properties here, since that's not what is usually meant by "custom property".
Reviewed By: angavrilov
Maniphest Tasks: T92530
Differential Revision: https://developer.blender.org/D13084
|
