| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
This may be useful for things like mirroring. Since the parameter
name space is shared by all rigs, it would be inappropriate for
individual rigs to add their specific callbacks to properties.
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
|
|
|
|
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.
|
|
Otherwise the rig properties may not work correctly until blender restart.
|
|
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
|
|
|
|
The 'make annotation' spam also happens on addon enable
toggle, so apply the legacy toggle fix globally.
|
|
Registering and unregistering the class causes 2.8 to complain
about non-annotation properties, and this avoids the problem.
Plus, legacy and non-legacy shouldn't interact.
|
|
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).
|
|
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
|
|
CREDITS and README files
|
|
|
|
|
|
|
|
Python 3.4.0 deprecated the "imp" module, and replaced it with
"importlib". This changes imp.reload() into implib.reload().
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1016
|
|
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.
|
|
I have updated the rig type API to be a bit clearer based on my
interactions with Kfir from PitchiPoy.
I've also disabled the "delta" rig type, as it is very obscure and
mostly just confuses people.
|
|
This makes it much easier for e.g. someone to branch Rigify for
custom purposes, since there won't be weird name conflicts.
Also changed from using __import__() for dynamic imports to using
importlib.import_module(). This simplifies the code and should
be more robust.
Finally, misc pep8 cleanups.
|
|
The biggest fixes relate to keeping ID data modification out of
draw methods. This was breaking Rigify with the current API.
Secondary fix was to move widget meshes to match the bones, even
if the widget meshes already exist. It's nice for when the user
is progressively tweaking the metarig.
|
|
make addons blender versions consistent
|
|
|
|
|
|
Plus a few styling enhancements.
[[Split portion of a mixed commit.]]
|
|
|
|
- remove/comment unused variables
- remove unused imports
- fixed some bugs using incorrect variables
|
|
|
|
|
|
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.
|
|
|
|
- Added IK/FK snapping (both directions) for legs.
- Cleaned up another operator so that it works with undo.
- PEP8 cleanups.
|
|
|
|
Just required some misc updates due to python API changes.
|
|
|
|
|
|
addon next).
|
|
in bl_info
|
|
|
|
READ THIS TO AVOID A LOT OF WORK!
New way of linking to tracker pages: just use the parameter "aid" (artifact ID),
to avoid a lot of manual updates later in wiki and svn.
Example:
=========
OLD WAY TO LINK TO TRACKER
-----------------------------
Complete url of a script in Upload
http://projects.blender.org/tracker/index.php?func=detail&aid=25349&group_id=153&atid=467
If we move this in contrib this url will become
http://projects.blender.org/tracker/index.php?func=detail&aid=25349&group_id=153&atid=468
467 becomes 468, so we have to update this in wiki page.
Later on, when this moves into Trunk, the url will become
http://projects.blender.org/tracker/index.php?func=detail&aid=25349&group_id=153&atid=469
468 becomes 469, so we have to update the url in wiki page and svn.
Annoying!
NEW WAY TO LINK TO TRACKER
-----------------------------
Best way to link to tracker page is using:
http://projects.blender.org/tracker/index.php?func=detail&aid=25349
Use "func=detail"
Use "aid" (which is the "artifact ID")
DON'T use "group_id" (which is the project ID, bf-extensions is project 153)
DON'T use "atid" (which is the "artifacts tracker ID")
Like this, the url is unique, and we will avoid to update wiki pages and svn after moving pages
[[Split portion of a mixed commit.]]
|
