Process/Addons/Rigify/FeatureSets
Feature Set Package Structure
Feature sets are packaged as a ZIP archive containing a valid Python module package, with specific required sub-packages:
- feature_set_name
- __init__.py
- metarigs
- __init__.py
- feature_set
- __init__.py
feature_set_metarig.py
- rigs
- __init__.py
- feature_set
- __init__.py
custom_rig.py
When an archive containing these files is installed, it will add
a Feature Set -> Feature Set Metarig
template to the Add Armature menu,
and, provided custom_rig.py
contains a valid rig class, a feature_set.custom_rig
rig component will become available. The metarigs
subpackage is optional,
while rigs
is required.
The rigs
and metarigs
packages of all feature sets and Rigify itself are
merged into a common flat namespace, so feature sets should explicitly use
sub-packages to group and separate the provided rigs, as demonstrated above.
The root directory of the archive must be a valid python module name
(i.e. an identifier); however as a special exceptions the characters '.'
and '-'
will be automatically replaced with '_'
when the archive is installed. The
exception is provided to allow using archives produced by the Download ZIP
button on GitHub as-is.
The root __init__.py
of the feature set may contain the following global
variable definition to provide a user-friendly name and other metadata for
the feature set:
rigify_info = {
"name": "Custom Feature Set",
"description": "More detailed description.\nSecond line of description.",
"author": "Author Name",
"warning": "Warning message, e.g. the set is experimental.",
# Web site links
"link": "https://github.com/repository/link",
"doc_url": "https://documentation/link",
"tracker_url": "https://bug/tracker/link",
# Feature set version
"version": (1, 2, 3),
# Minimum supported Blender version
"blender": (4, 0, 0),
# List of other feature sets this one depends on, if any
# (must be an exact copy of their "link" values)
"dependencies": ["https://github.com/other-repository/link"],
}
It can also provide register
and unregister
functions, like stand-alone
add-ons, in order to implement more complex utilities for editing the meta-rig
than passive properties in the rig settings UI. The generated rig should not
depend on objects provided this way.
def register():
print("Registered")
def unregister():
print("Unregistered")
Feature sets are loaded as sub-packages of the rigify.feature_sets
placeholder package.
If you need to import modules from another feature set, you should look it up using the same "link" value you declared in "dependencies", using code similar to this:
target_set_root = rigify.feature_set_list.get_module_by_link_safe("https://github.com/other-repository/link")
target_module = importlib.import_module(".rigs.feature.rig_type", target_set_root.__name__)
This should provide resiliency to e.g. GitHub zip download including the branch name in the directory name.
Such imports should not be triggered by importing the root __init__.py
file of the feature set,
because that is necessary to build the link to feature set mapping itself.