Age | Commit message (Collapse) | Author |
|
See T95597
|
|
|
|
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Just removing some unused imports.
I tested generating every built-in metarig to make sure I didn't remove any imports that were actually used. I also tested installing and using a feature-set.
Reviewed By: angavrilov
Differential Revision: https://developer.blender.org/D8026
|
|
|
|
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.
|
|
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
|
|
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
|
|
Differential Revision: https://developer.blender.org/D5240
|
|
|
|
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
|
|
|
|
Since they are specific to the selected armature/bone, they
match that tab better, and the animator would want to have
them next to the built-in transforms and custom properties.
|
|
Panel identifier naming restrictions are now enforced more strictly.
|
|
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
|
|
|
|
|
|
With those changes the addon is working in some functional state.
Thus I'm bumping its version to 2.80.
TODOS:
* Handle collections (put all the new objects in a collection).
* We should also replace the old WGT_LAYERS with subcollections.
* Move toolshelf operators out of there (make tools or move to sidebar).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Arm/leg rig upgrades:
- Arms and legs no longer scale with their parents, which was
problematic when e.g. the torso of a character did
squash-and-stretch causing the arms/legs to distort and shear.
- Squash-and-stretch for both FK and IK rigs.
- Rubber hose controls.
Misc changes/bugfixes:
- Rigify now locks all pose transforms for non-control bones
automatically.
- The README file now correctly reflects the new rig-type API.
- Scrubbed the code for unused variables and imports.
- PEP8 cleanups.
|
|
|
|
|
|
|
|
|
|
|
|
The layer names are then used in creating the custom rig layer UI. This is
useful for users that do not want to--or do not have the knowledge to--edit
the generated python script by hand. It is also handy even for more advanced
users when regerating the rig over and over (which over-writes the script
and any hand-made edits).
Also misc bug fixes in some of the rig types.
|
|
|
|
Matrix().Scale --> Matrix.Scale
|
|
- Flipped the roll values on the default human metarig spine and neck. This
makes bending the rig forward have a positive rotation value, and bending
back have a negative one. More in line with user expectations.
- Improved get_pose_matrix_in_other_space() to account for bones with
"inherit rotation" and/or "inherit scale" turned off.
- Added a text file giving credit to people who have contributed to Rigify
financially or otherwise.
|
|
Moved operator registration for rig UI into the register function. Not
really necessary, since the generated script doesn't act as an addon. But
it keeps everything in one place.
Also added an unregister function for absolutely no reason.
|
|
Clean-up of the IK/FK snapping code. Should be much more maintainable now.
Also changed rig id generation. Rig id's now consist of a random
alphanumeric string 8 characters long, with the smallest 8 digits of seconds
since the epoc (in hex) at the time of rig generation appended on the end.
This results in a 16-character string that is ludicrously unlikely to
have any collisions between rigs. 36^8 * 16^8, with the 16^8 being very well
distributed over time. Ah... paranoia.
|
|
- Added IK/FK snapping (both directions) for legs.
- Cleaned up another operator so that it works with undo.
- PEP8 cleanups.
|
|
Also cleaned up how some of the operators work. They weren't playing nice
with undo.
|
|
So far just IK->FK for biped.arm.
|
|
|
|
|