| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Normally properties are copied to controls and made accessible
in the rig UI, so they should be overridable. Properties created
via make_property are already marked as such.
|
|
|
|
Improve auto-generated UI naming and update basic.pivot, basic.raw_copy
and basic.super_copy. Also allow raw_copy to generate builtin widgets.
|
|
This preserves the standard widget naming even with custom widgets.
|
|
|
|
Register the most generic widgets in the list and add a few more.
Use it to assign a nicer looking shoulder widget in human metarigs.
|
|
Since rigs like super_copy already support using widgets assigned
directly to metarig bones, implement adding them with the metarig.
|
|
As pointed out in comments to T73114, using the same name has downsides.
In addition, remove the widget parent object that was inherited
from the old pre-collection way Rigify worked and has no other
purpose than grouping objects like the collection already does.
Rename the widgets and the collection when renaming the rig.
Finally as an aside add a couple of options to create_widget.
|
|
Also make error handling more robust and extend constraint relink mixin.
|
|
- Don't try to add an update callback to CollectionProperty.
- Restore exact alignment of the super_finger master control to 1st bone.
- Add an option to run a sub-object after all methods of the parent.
- Fix wrong identifier in SideZ.from_parts.
|
|
This is for convenience of more complex utilities, since
the functions themselves immediately force the closures.
|
|
Also fix metarig Inherit Scale support in limbs.super_finger.
|
|
Add support for 5 bone chains to the limbs.paw rig.
Implement a new limbs.rear_paw rig, which provides a three bone IK
mechanism designed to keep the first and third bones nearly parallel
by default (based on a YouTube video by @Pieriko as suggested by
@icappiello).
Implement a limbs.front_paw rig with automation that aims to
keep the angle between second and third bones mostly stable
by default (has influence option), as suitable for front paws.
The horse and wolf metarigs are updated to use these new rig
types, with the horse rig further overhauled by @icappiello.
Maniphest Tasks: T78463
Differential Revision: https://developer.blender.org/D8496
|
|
|
|
In 2.90 derived bone lookup was tightened to fix certain issues when
bone names use the .001 suffixes by using explicit data about which
bone is derived from which one. Unfortunately, legacy rigs don't
provide that info, so add a special case using matching by name.
Also fix incorrect error reporting method name.
|
|
It seems like the make_constraint() function was designed to allow fully
defining a constraint with a single call, but currently when creating
Armature constraints, its targets have to be created separately after
the make_constraint() call.
This patch addresses this, allowing you to pass a "targets" dictionary.
Armature constraint targets only have three properties, which are "target",
"subtarget" and "weight". For convenience, since 99.99% of the times the
"target" will be the rig, that doesn't have to be specified, but it can be.
Differential Revision: https://developer.blender.org/D9092
|
|
rig script
In days of old, Custom Properties couldn't store datablock pointers, so a driver variable was used to reference the script datablock, thereby keeping it attached to the rig when the rig is linked or appended. This can now be achieved much more elegantly with one short line of code.
Reviewed By: angavrilov
Differential Revision: https://developer.blender.org/D9082
|
|
This class exists specifically for the purpose of defining and drawing the UI for bone layer assignment parameters, as seen in other rig types like super_chain, limb_rigs, simple_tentacle, etc. Only super_face was missing it for some reason.
Although the way it is used may be questionable, it's consistent with the rest of the codebase.
No functional changes.
Note for future: I would also like to use the ControlLayersOption class in even more places, and also maybe rename it and make improvements to it as needed. This would also be part of a bigger design of how Rigify handles bone organization, which I should write down.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D8802
|
|
Instead of implementing the 2 rows of layer boolean toggles, we can just use the 'LAYER' subtype on the BoolVectorProperty.
No functional changes.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D8801
|
|
Just removes an empty file and redundant function definition. No functional changes.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D8804
|
|
|
|
|
|
|
|
It is not really safe to assume that by swapping ORG to DEF you will
get a deform bone derived from the given ORG bone. The new base rig
API already tracks copying of bones, so polish it up and use here.
Note however that this tracking doesn't work with bones created
without self.copy_bone, e.g. by legacy rigs.
|
|
Currently there is 'subtype', but allow everything to future proof.
|
|
|
|
This will likely be useful in the upcoming new face rigs.
Also fix a bug in the bones module.
|
|
Implement options to generate a parent switch mechanism for the
main pivot control, and to register the pivot as a parent for other
rigs to use (including support for one level parent injection).
|
|
The control itself is simply a pivot around the end of the hand
bone, similar to those in the foot and paw. However, the main
point of it is that it allows future finger IK to use the IK
control as the parent, while still allowing the wrist to be moved
relative to it.
|
|
|
|
Allow tagging parents with arbitrary strings to be later used
in selecting the best default parent for a child control.
Also add a tagged parent point at the limb IK control.
|
|
The operator itself simply snaps a chain of bones to a different
chain, so nothing in it in fact is specific to IK or FK. To make
this even more explicit, rename the operator and add some extra
options to control the tooltip and which properties are changed.
Also include some other minor enhancements in the script utilities.
|
|
|
|
|
|
Instead of collecting all possible parents in a list, use
buckets indexed by the owning rig, so that parents injected
by other rigs are ordered correctly. Otherwise the Head
parent injected into the spine hierarchy gets in the way.
|
|
|
|
- Add an optional custom pivot between torso and the rest of the spine.
- Add a custom pivot rig that can be used as a parent of the spine.
- Add an optional custom pivot under limb IK controls.
|
|
The layer selection for the spine tweaks happens to be the default value,
so simply copying the data does not overwrite non-default garbage values
remaining in some of the bones. To fix it's necessary to clear params.
|
|
- Add a parent switch to the main spine control, to allow using the
key baking operator to convert between moving and fixed root bone.
- Add hips, chest and head as parents for children of the spine.
- Use 'Fix Shear' Inherit Scale and 'Make Uniform' Copy Scale in limbs.
- Switch code to use the new inherit_scale parameter of set_bone_parent.
- Allow local matrices in adjust_widget_transform_mesh.
|
|
The idea is inspired by similar shapes in other rigs like BlenRig.
The actual used shape is simply a circle deformed into a parabolic
shape when viewed from the side, added to create_circle_widget.
Using the new shape for the main controls allows adding extra FK
controls to the spine without visual confusion.
As an aside, fix a minor issue in handling bone_transform_name,
and remove redundant bone_transform_name=None parameters.
|
|
Toes behave as FK, but are needed both in IK and FK mode.
|
|
Support easier setting of bone orientation via matrix, inherit_scale,
invert_x/y/z constraint properties, computing a matrix from two axis
vectors, adjusting widget positions, and add a pivot widget.
|
|
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.
|
|
Allow easily inserting constraints and support rotation mode.
|
|
|
|
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
|
|
Patch suggested by @pioverfour.
|
|
Patch suggested by @pioverfour.
|
