| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
This patch adds two new operators to the Rigify drop-down menu: Copy Parameters to Selected Bones and Mirror Parameters. I use both of these on a daily basis when working with Rigify, and I don't know how people live without it.
{F10171452}
To test the more unusual cases, you can grab my [feature set](https://gitlab.com/blender/CloudRig) and this file:
{F10178637}
There are two sets of symmetrical bones, with totally assymetrical parameters of all kinds of types. (CollectionProperty of PropertyGroups with just a couple strings, PointerProperty at Object datablock, BoolVectorProperty, EnumProperty, FloatVectorProperty, and the basic things like bools and ints, all seems to work!)
In a later patch if people like the idea, I would also add the Copy Rigify Parameters button to the Copy Attributes addon's Ctrl+C menu (that would only appear when Rigify is enabled, of course).
Reviewed By: sybren, angavrilov, #animation_rigging
Differential Revision: https://developer.blender.org/D11606
|
|
The master control rotated to match the limb rest roll, because
for an unknown reason the roll was reset in edit pose.
Inner tweaks could rotate if roll of master tweaks wasn't matched.
To fix this, compute and apply the interpolated roll.
|
|
After introduction of the Custom space it is possible to easily
use Limit Distance within rigs while accounting for rig scale.
This allows replacing the Stretch To + Limit Scale mechanism
used for the IK stretch switch in rigify.
Instead, use the freed bone to manually handle limb swing before
allowing the actual IK solver to handle limb contraction. This
improves stability in marginal cases of limbs nearly straight
in the rest pose, because previously the solver could destroy
the slight knee bend in the process of swinging the limb forward,
causing a flip.
|
|
After the custom shape scale property was split into an XYZ vector,
it is possible to generate truly mirrored widgets using the same
mesh for the left and right side. The widgets Rigify generates are
originally symmetrical, but in practice they usually need to be
tweaked to fit the character better, and proper mirroring matters.
This commit implements widget mirroring and enables it by default.
When reusing widgets left from a previous generation the code tries
to detect whether they were actually originally mirrored by checking
object scale to avoid flipping in pre-existing rigs.
As an aside, reusing pre-existing widgets is made more robust
to random name changes by building a table via scanning the old
generated rig before overwriting it.
|
|
Just in case the user wants to apply some custom changes to the
generated rig, allow executing a text datablock as a python script
after generation completes.
The script is executed with the generated rig active and in object
mode. When executed by rigify, the generator instance is available
via `rigify.get_generator()`. Outside of Rigify generation the return
value is None.
|
|
Rig generation fails if the target rig that is to be overwritten
is hidden, either directly or via collections. To improve usability,
try unhiding the object, and fail with an appropriate message if
it doesn't work.
In addition, slightly refactor code that selects a suitable
unhidden collection to use for generation.
This started as D11355 by @Mets, but was somewhat refactored.
|
|
This is a followup patch for D9697 which applies the changes to the
addon reporistory. Almost all of the changes are in rigify, but there
is one change in "curve_tools" and two trivial changes in IO addons.
Differential Revision: https://developer.blender.org/D9919
|
|
Accidental commit by misclicking in VSC, yikes!
This reverts commit 9a7afcbcae91978db8173e205f0ec73f1d6ad440.
|
|
The UX for this panel felt like it could use a facelift. It was extremely ugly to look at, nothing about it was done the correct way and it broke every possible modern Blender UI convention it could.
Before/After:
{F10135475}
{F10159077}
After generating a rig:
{F10159078}
- Removed the "overwrite/new" enum.
- If there is a target rig object, we overwrite. If not, we create. I think that's intuitive behaviour without the extra UI element.
- 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.
- Renamed the panel from "Rigify Buttons" to "Rigify Generation" in pose/object mode and "Rigify Samples" in edit mode.
- Changed the "Advanced Options" into a sub-panel instead.
- Single column layout.
- Added an info message to show the name of the successfully generated rig:
{F10159079}
Feedback welcome.
Differential Revision: https://developer.blender.org/D11356
|
|
This allows cleanly avoiding reparent propagation between mirror
siblings, which causes weird deformation in chains.
|
|
Converted from the script originally included in the feature set.
This operator aims to preserve compatibility with the existing weight
painting, but not animations, since the latter is impossible anyway
due to major differences in the rig chains.
|
|
Realized this can be simplified while writing wiki dev docs...
|
|
|
|
Apart from imports the files are identical to the latest version.
Ref T89808
|
|
In the process of re-generating a rig, drivers that reference it
from other objects can temporarily become invalid. This sets an
error flag in the driver, stopping its evaluation, so the error
doesn't clear out even when it becomes valid again.
To fix stuck drivers, loop over all objects in the file after
generation and refresh their drivers by fake modification.
|
|
|
|
If the metarig contains a bone called 'root', it is used as the
root bone for the generated rig instead of creating a new one.
This allows changing root location, orientation, size, widget, or
adding custom properties that show up in the rig UI via raw_copy.
|
|
To make it easier to call super(), instead of printing in the
dummy base method, detect and special case it in the caller code.
|
|
Move widget and driver utilities from the feature set and rewrite
create_circle_widget. Also increase the line length for autopep8.
|
|
- LazyRef utility class that provides a hashable field reference.
- NodeMerger plugin for grouping abstract points by distance.
- pose.rigify_copy_single_parameter operator for copying a single
property to all selected rigs that inherit from a specific class
(intended to be used via property panel buttons).
|
|
The line was missed when updating in rBA448eeb681 after rBf29a738e2.
Also remove an unneeded import.
|
|
This patch removes the Legacy Mode checkbox from the addon preferences and all associated code.
Ability to convert old legacy metarigs is not removed.
LegacyRig wrapper class is not removed.
Various legacy-only functions and imports were not removed, with the reasoning that they are still used by [this unmaintained feature set](https://github.com/cessen/cessen_rigify_ext).
Initially discussed in T88711, let's put any further discussion here, since that thread has many topics.
Reviewed By: angavrilov
Differential Revision: https://developer.blender.org/D11516
|
|
|
|
|
|
This or something like this is necessary because the new search menu doesn't search the sidebar nor the properties panel for UI buttons. I think the ability to run Add Sample and Generate from the search menu is useful, so being able to do it without having Developer Extras enabled is important.
I would also like to propose some new operators in the future, and this patch sets up a nice spot for them to go into.
I didn't remove any buttons in this patch, but would like to do in future, so these things will once again only exist in one place (which would be the header).
Reviewed By: angavrilov
Differential Revision: https://developer.blender.org/D9094
|
|
Use new properties introduced in rBfc5bf09fd88c33.
|
|
37af7e130b99865575f1fa2315ef806f815b0f42 missed this change.
|
|
|
|
The built-in layer button UI only draws dots if the property
belongs to an Armature, as a special behavior hard-coded in C.
This returns to drawing the UI from Python but using cleaner code.
|
|
|
|
|
