| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
This is no longer necessary, see: T98554.
|
|
change the icons for adding and removing Rigify bone groups. Reviewed By: Aaron Carlisle, Differential Revision: http://developer.blender.org/D11352
|
|
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
|
|
This reverts commit f0f48da209de08d66fd9e3b311e379687c7ba699.
|
|
|
|
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
|
|
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.
|
|
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
|
|
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.
|
|
|
|
To make it easier to call super(), instead of printing in the
dummy base method, detect and special case it in the caller code.
|
|
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
|
|
|
|
Since rigs like super_copy already support using widgets assigned
directly to metarig bones, implement adding them with the metarig.
|
|
Also make error handling more robust and extend constraint relink mixin.
|
|
|
|
`context.object` can be None, so a poll function should not access
`context.object.type` without prior check.
|
|
instead of tools.
|
|
|
|
Throwing an exception out of an operator seems to mess up the undo
stack entry created by it, so catch and report all exceptions.
|
|
By storing the Rigify advanced generation options (name, target rig,
target ui script) in the armature data instead of the window manager
as before, multiple rigs can have different options. Additionally,
these options are stored in the blend file, and not lost when reloading.
Also, the rig name is not automatically suffixed with `_rig`, which
doesn't make sense as far as I can tell.
Differential Revision: https://developer.blender.org/D5675
|
|
Due to dynamically loaded rig modules, Rigify has to implement
reload by purging all non-core modules from memory, or class
inheritance checks won't work right after reload.
|
|
New rigs provide the same buttons in their generated script UI,
and aren't compatible with the old panel code. To distinguish
rigs, remove old snap operators from the script.
Differential Revision: https://developer.blender.org/D4624
|
|
The main goals are to provide an official way for rigs to
interact in a structured way, and to remove mode switching
within rigs.
This involves introducing a base class for rigs that holds
rig-to-rig and rig-to-bone references, converting the main
generator into a class and passing it to rigs, and splitting
the single generate method into multiple passes.
For backward compatibility, old rigs are automatically handled
via a wrapper that translates between old and new API.
In addition, a way to create objects that receive the generate
callbacks that aren't rigs is introduced via the GeneratorPlugin
class. The UI script generation code is converted into a plugin.
Making generic rig 'template' classes that are intended to be
subclassed in specific rigs involves splitting operations done
in each stage into multiple methods that can be overridden
separately. The main callback thus ends up simply calling a
sequence of other methods.
To make such code cleaner it's better to allow registering
those methods as new callbacks that would be automatically
called by the system. This can be done via decorators.
A new metaclass used for all rig and generate plugin classes
builds and validates a table of all decorated methods, and
allows calling them all together with the main callback.
A new way to switch parents for IK bones based on the new
features is introduced, and used in the existing limb rigs.
Reviewers: icappiello campbellbarton
Differential Revision: https://developer.blender.org/D4624
|
|
|
|
Instead of adding the feature set installation directory
to the global path, and thus inserting the modules into
the top level namespace, add an empty rigify.feature_sets
package and use __path__ to redirect the module loader
to read its sub-modules from the feature set directory.
Now feature set modules are effectively installed into
that package and loaded as 'rigify.feature_sets.foo'.
As an aside, clean up loading code to avoid weird path
manipulations, add more safety checks when installing sets,
and add a way for sets to expose a user-friendly name.
|
|
Using obj.animation_data.drivers[-1] in driver creation is very
bad and error prone. After recent change in Blender, that won't
even work for drivers on Bone, so fix all such uses.
|
|
|
|
This can cause bugs where if the operator throws an exception, undo is not
properly enabled again. There have been maybe a dozen Blender bug reports
related to this. This could get worse now that we are autosaving preferences.
Some add-ons guard against this, but turning off undo should not be needed in
the first place. If the operator is set to do an undo push, any operators it
calls will automatically not do any undo pushes.
If this fail in some cases, it should be reported as a bug in Blender. I could
not find issues or a performance impact testing a few add-ons though.
Differential Revision: https://developer.blender.org/D4908
|
|
As suggested by @icappielo, and after discussion with @meta-androcto,
I start a public request to commit third-party contributions already
accepted to https://github.com/eigen-value/rigify/tree/rigify_0.6_beta
Specifically, this includes:
* User-defined rig package (feature set) support by @pioverfour.
This allows users to install pre-packaged rig sets via zip
files, which become accessible together with built-in rigs,
as discussed in T52758.
https://github.com/eigen-value/rigify/pull/1
* Modularization of python script generation, allowing rigs to
add their own utility functions and operators to the generated
script. This is critical to make custom rig support really
useful.
https://github.com/eigen-value/rigify/pull/5
* The utils.py file is split into multiple modules with a backward
compatibility proxy for old functions.
* Automatic verification that different rigs don't try to create
different rig settings with the same name to alleviate increased
risk of namespace conflicts with custom rigs.
https://github.com/eigen-value/rigify/pull/7
* New utility class that implements bone layer selection UI.
https://github.com/eigen-value/rigify/pull/6
* New utilities to replace copy & pasted boilerplate code for
creating custom properties, constraints and drivers.
https://github.com/eigen-value/rigify/pull/11
Some other random changes by MAD have likely slipped through.
These changes have already been extensively discussed and accepted
into the branch by @luciorossi, so I see no reason not to commit
them to the official repository to be tested during 2.8 beta.
Reviewers: icappiello
Differential Revision: https://developer.blender.org/D4364
|
|
|
|
|
|
Since some recent change in 2.8 the UI for rigify is no longer working.
Note: if your object has ANY custom property, the custom property shows as
a Misc. category, it is not particular to rigify, so I will not bother with
this here.
|
|
|
|
The UI is still using the toolshelf. So I did not bump the version to 2.80.
It seems to be working as far as the UI and the quat/euler operators is concerned.
|
|
Reason for rename is that 'set' is a python builtin data structure.
|
|
|
|
|
|
|
|
|
|
|
|
small fixes & UI improvements
|
