[Bf-extensions-cvs] [c60d7e32] master: Rigify 0.5 advanced generation options, fixes and improvements. removed CREDITS and README files
Lucio Rossi
noreply at git.blender.org
Sat Jun 10 14:31:31 CEST 2017
Commit: c60d7e325716a308a7663428df5b5be04ef0d6cc
Author: Lucio Rossi
Date: Sat Jun 10 14:29:54 2017 +0200
Branches: master
https://developer.blender.org/rBAc60d7e325716a308a7663428df5b5be04ef0d6cc
Rigify 0.5 advanced generation options, fixes and improvements. removed CREDITS and README files
===================================================================
D rigify/CREDITS
D rigify/README
M rigify/__init__.py
M rigify/generate.py
M rigify/ui.py
M rigify/utils.py
===================================================================
diff --git a/rigify/CREDITS b/rigify/CREDITS
deleted file mode 100644
index 38f6de46..00000000
--- a/rigify/CREDITS
+++ /dev/null
@@ -1,32 +0,0 @@
-A big thank you to all the people listed here for supporting Rigify.
-
-Original prototyping and development, and Python API support:
-- Campbell Barton
-
-Development:
-- PitchiPoy Animation Productions
-- Kfir Merlaub
-- Tamir Lousky
-
-General financial support:
-- Benjamin Tolputt
-- Nesterenko Viktoriya
-- Jeff Hogan
-- PitchiPoy Animation Productions
-
-IK/FK snapping financial support:
-- Benjamin Tolputt
-- Nesterenko Viktoriya
-- Leslie Chih
-- Isaac Ah-Loe
-- Casey "TheLorax" Jones
-
-### Rigify Version 0.5 ###
-Development:
-- Lucio Rossi
-
-Design:
-- Ivan Cappiello
-
-General financial support:
-- Mad Entertainment Animation
\ No newline at end of file
diff --git a/rigify/README b/rigify/README
deleted file mode 100644
index f8cb7656..00000000
--- a/rigify/README
+++ /dev/null
@@ -1,250 +0,0 @@
-INTRODUCTION
-------------
-Rigify is an auto-rigging system based on a "building blocks" paradigm. The
-user can create a rig by putting together any combination of rig types, in any
-configuration that they want.
-
-A rig type is something like "biped arm" or "spine" or "finger".
-
-The input to the Rigify system is something called a "metarig". It is an
-armature that contains data about how to construct the rig. In particular, it
-contains bones in the basic configuration of the rig, with some bones tagged
-to indicate the rig type.
-
-For example, a metarig might contain a chain of three bones, the root-most of
-which is tagged as being a biped arm. When given as input to Rigify, Rigify
-will then generate a fully-featured biped arm rig in the same position and
-proportions as the 3-bone chain.
-
-One could also have another chain of bones, the root-most of which is tagged as
-being a spine. And the root-most bone of the arm chain could be the child of
-any of those spine bones. Then the rig that Rigify generates would be a
-spine rig with an arm rig attached to it.
-
-
-THE GUTS OF RIGIFY, SUMMARIZED
-------------------------------
-The concept behind rigify is fairly simple. It recieves an armature as input
-with some of the bones tagged as being certain rig types (arm, leg, etc.)
-
-When Rigify recieves that armature as input, the first thing it does is
-duplicate the armature. From here on out, the original armature is totally
-ignored. Only the duplicate is used. And this duplicate armature object will
-become the generated rig.
-
-Rigify next prepends "ORG-" to all of the bones. These are the "original"
-bones of the metarig, and they are used as the glue between rig types, as I
-will explain later.
-
-Rigify then generates the rig in two passes. The first pass is the
-"information gathering" stage.
-
-The information gathering stage doesn't modify the armature at all. It simply
-gathers information about it. Or, rather, it lets the rig types gather
-information about it.
-It traverses the bones in a root-most to leaf-most order, and whenever it
-stumbles upon a bone that has a rig type tagged on it, it creates a rig-type
-python object (rig types will be explained further down) for that rig type,
-and executes the resulting python object's information gathering code.
-
-At the end of the information gathering stage, Rigify has a collection of
-python objects, each of which know all the information they need to generate
-their own bit of the rig.
-
-The next stage is the rig generation stage. This part is pretty simple. All
-Rigify does is it loops over all of the rig-type python objects that it created
-in the previous stage (also in root-most to leaf-most order), and executes
-their rig-generate code. All of the actual rig generation happens in the
-rig-type python objects.
-
-And that's pretty much it. As you can see, most of the important code is
-actually in the rig types themselves, not in Rigify. Rigify is pretty sparse
-when it comes right down to it.
-
-There is one final stage to rig generation. Rigify checks all of the bones
-for "DEF-", "MCH-", and "ORG-" prefixes, and moves those bones to their own
-layers. It also sets all of the "DEF-" bones to deform, and sets all other
-bones to _not_ deform. And finally, it looks for any bone that does not have
-a parent, and sets the root bone (which Rigify creates) as their parent.
-
-
-THE GUTS OF A RIG TYPE, BASIC
------------------------------
-A rig type is simply a python module containing a class named "Rig", and some
-optional module functions. The Rig class has only two methods:
-__init__() and generate()
-
-__init__() is the "information gathering" code for the rig type. When Rigify
-loops through the bones and finds a tagged bone, it will create a python
-object from the Rig class, executing this method.
-In addition to the default "self" parameter, __init__() needs to take the
-armature object, the name of the bone that was tagged, and a parameters object.
-
-A proper rig-type __init__() will look like this:
-
- def __init__(self, obj, bone_name, params):
- # code goes here
-
-At the bare minimum, you are going to want to store the object and bone name
-in the rig type object for later reference in the generate() method. So:
-
- def __init__(self, obj, bone_name, params):
- self.obj = obj
- self.org_bone = bone_name
-
-Most rig types involve more than just that one bone, though, so you will also
-want to store the names of any other relevant bones. For example, maybe the
-parent of the tagged bone is important to the rig type:
-
- def __init__(self, obj, bone_name, params):
- self.obj = obj
- self.org_bone = bone_name
- self.org_parent = obj.data.bones[bone_name].parent.name
-
-It is important that you store the _names_ of the bones, and not direct
-references. Due to the inner workings of Blender's armature system, direct
-edit-bone and pose-bone references are lost when flipping in and out of
-armature edit mode. (Arg...)
-
-Remember that it is critical that the information-gathering method does _not_
-modify the armature in any way. This way all of the rig type's info-gathering
-methods can execute on a clean armature. Many rig types depend on traversing
-parent-child relationships to figure out what bones are relevant to them, for
-example.
-
-
-Next is the generate() method. This is the method that Rigify calls to
-actually generate the rig. It takes the form:
-
- def generate(self):
- # code goes here
-
-It doesn't take any parameters beyond "self". So you have to store any
-information you need with the __init__() method.
-
-generate() pretty much has free reign to do whatever it wants, with the exception
-of two simple rules:
-1. Other than the "ORG-" bones, do not touch anything that is not created by
-the rig type (this prevents rig types from messing each other up).
-2. Even with "ORG-" bones, the only thing you are allowed to do is add children
-and add constraints. Do not rename them, do not remove children or
-constraints, and especially do not change their parents. (Adding constraints
-and adding children are encouraged, though. ;-)) This is because the "ORG-"
-bones are the glue that holds everything together, and changing them beyond
-adding children/constraints ruins the glue, so to speak.
-
-In short: with the exception of adding children/constraints to "ORG-"
-bones, only mess with things that you yourself create.
-
-It is also generally a good idea (though not strictly required) that the rig
-type add constraints to the "ORG-" bones it was generated from so that the
-"ORG-" bones move with the animation controls.
-For example, if I make a simple arm rig type, the controls that the animator
-uses should also move the "ORG-" bones. That way, any other rig-types that are
-children of those "ORG-" bones will move along with them. For example, any
-fingers on the end of the arm.
-
-Also, any bones that the animator should not directly animate with should have
-their names prefixed with "DEF-" or "MCH-". The former if it is a bone that
-is intended to deform the mesh, the latter if it is not.
-It should be obvious, then, that a bone cannot be both an animation control and
-a deforming bone in Rigify. This is on purpose.
-
-Also note that there are convenience functions in utils.py for prepending
-"DEF-" and "MCH-" to bone names: deformer() and mch()
-There is also a convenience function for stripping "ORG-" from a bone name:
-strip_org()
-Which is useful for removing "ORG-" from bones you create by duplicating
-the "ORG-" bones.
-I recommend you use these functions instead of manually adding/stripping
-these prefixes. That way if the prefixes are changed, it can be changed in
-one place (those functions) and all the rig types will still work.
-
-
-THE GUTS OF A RIG TYPE, ADVANCED
---------------------------------
-If you look at any of the rig types included with Rigify, you'll note that they
-have several functions outside of the Rig class.
-THESE ADDITIONAL FUNCTIONS ARE _NOT_ REQUIRED for a rig type to function. But
-they can add some nifty functionality to your rig.
-
-Here are the additional functions relevant to Rigify, with brief decriptions of
-what they are for:
-
-
-RIG PARAMETERS
---------------
-For many rig types, it is handy for the user to be able to tweak how they are
-generated. For example, the included biped arm rig allows the user to specify
-the axis of rotation for the elbow.
-
-There are two functions necessary to give a rig type user-tweakable parameters:
-add_parameters()
-parameters_ui()
-
-add_parameters() takes an IDPropertyGroup as input, and adds its parameters
-to that group as RNA properties. For example:
-
- def add_parameters(params):
- params.toggle_param = bpy.props.BoolProperty(name="Test toggle:", default=False, description="Just a test, not really used for anything.")
-
-parameters_ui() recieves a Blender UILayout object and an IDPropertyGroup
-containing the parameters added by add_parameters(). It creates a GUI in the
-UILayout for the user to tweak those parameters. For example:
-
- def parameters_ui(layout, params):
- r = layout.row()
-
@@ Diff output truncated at 10240 characters. @@
More information about the Bf-extensions-cvs
mailing list