(when I mention "vertex keying" below replace that with "relative vertex keying"
its what I meant to say)
A bigger image can be found here:
http://www.bl3nder.com/UML/DesiredRelat ... lender.png
The original MDL (a CORBA standard UML description file format
that is produced by rational rose, I think its in a XML subformat,
but doesn't really matter unless you have Rose or some MDL
compatible CASE tool, I'll try to use ArgoUML next time..):
My desired relationship of Bones to Skin in blender..
I didn't include relationships with respect to handles/end effectors
as those are kind of implicit in understanding skeletons.
But I'll describe this graph which represents a class
relationship, but should represent a working relationship
between classes of stuff.. This is not a formal definition or
anything of that sort, just a relationship of the ideas presented
as a class diagram.. I did this in Rational Rose (ArgoUML wouldn't
have allowed me this much freedom).
Okay, the diagram:
A skeleton can have bones and joints, we understand this from
blender, the skeleton is ordered in a hiearchy, but this class
diagram just specifies what relationship can exist, each bone
has exactly two joints, and each joint can have one or two bones
(the multiplicity just requires at least one bone for every joint and
vice versa, but I'm describing this alteration here). Functionally,
the joint actually owns and transforms the bone, and the bone owns one joint.
A cluster modifies the model display, the model is virtually parented
to the bones and joints but functionally the model is bound with clusters,
one cluster (per bone) with 100% influence is assigned to modify
the display of the model. The assignment of the cluster to the
the model is made at bind time, by some closest-point algorithm.
Additional clusters influence the display of the model in other ways
that deform and perturb the surface in a desired way by the user. A
flexor is a kind of lattice that bends a cluster with respect to a joint
(I made the flexor a kind of lattice and a kind of cluster since it
combines the advantages of both, but it could be seen that the flexor is a lattice that
has a cluster that is deforms). So, the cluster controls points
in the model, and is bent by the flexor. The advantage of having
the cluster bend the model instead of the lattice bend the model,
is the cluster is independent of the model it modifies, it could modify
points in a surface, polygon, curve and so on (basically anything that has
vertices or points, regardless of implementation of points).
Flexors like lattices have sides. If you position a lattice
left to right, it works just as it does in blender on meshes
and surfaces. But in this case the lattice isn't deforming
meshes but clusters which indirectly control the form of the
geometry. However the flexors are aligned with the
joint its parented to and the bottom half of the parent bone and
the lower half ot the child bone. Consider the parent bone to be the
upper arm, and the child bone to be the lower arm. The flexor
remains aligned with these bones even when the elbow is bent..
The flexor bends with the elbow joint. But its the flexor that
bends the skin, not the joint. Just as bending a lattice in blender would
bend anything parented to it. The only difference is that here
we are defining the flexor as a lattice that affects clusters and the
clusters bend the geometry. There is a reason for this which I will talk
The model is assigned to the bone clusters and joint flexors
according to a closest point tollerance, initially, and can be
adjusted by the user by assigning points to the flexors or clusters
afterward. This is the same as the way blender assigns
skin groups to bones, but more formal and straightforward..
The clusters can be observed in relation to the bones
and tweaked, the tools necessary to do this can
easily be created to view the contribution of one or multiple
clusters on a geometry. And since the bones and joints
own these clusters, it makes it easy to access the clusters.
Also a controller, a kind of mathimatical expression
that controls one parameter by accessing multiple other
parameters as input. The controller may also have a slider with
it that is keyed to the time or anything else that has a single value.
The controller in this case accesses the joint angle every time it changes
to influence (or interpolation between) multiple cluster poses modifying one
or more models (or model displays).
This is like creating relative vertex keys for multiple muscles in a
arm muscle and interpolating the influence of the vertex keys with
respect to the orientation of the shoulder joint, or elbow with respect
to the upper arm, for example.
It may seem like a lot to do in realtime, but for the purposes of
interaction the influence over the clusters can be turned off..
Also clusters can be used like "puffers" (a term from animatronics)
that puff up or deform a surface with respect to an IPO curve, for instance,
or with respect to some expression influenced by time, or with respect to any
multiple number of inputs, given through a special expression called a mixer
(that combines the inputs of several expressions to produce one output). In
implementation the expressions may end up all being alike, so the distinction
of "controller" versus "mixer" is purely descriptive of the style of relationship.
A bit more on the Description of multiplicity between objects:
Joint --- Flexor
A joint can have zero or more flexors (I didn't
think about this when I made the UML graph above,
this should read 1 .. 0 for both relationships, as
a joint doesn't necessarily require a flexor to bend it, this is similar to
binding a surface statically to a skeleton in
Maya, to have a flexor means the joint will flex the flexor
at the middle of the flexor, which overlaps visually
with the the joint over the surface of the model).
Flexor -> Model
Zero or more flexors can modify the
model, flexors are detachable which describes the
zero relationship, but there can be multiple
flexors modifying the model at any time,
and the model does not have access to the flexor
that modifies it ( the arrow defines the accessibility, or navigability).
Any flexor, just as a cluster, can modify multiple
models (that means the upper end of the
arm could be a polygon model and the lower end
could be a surface, the flexor modifies both,
this is either not true of Maya or I haven't tested
it. But if blender was designed to treat
all vertices the same, it would be possible to
have this kind of relationship. )
Cluster ---> Model
Like with the Flexor, the cluster can modify
one or more models.. In general a
model may have zero or more clusters, but in
the case of a skeleton the model has at least
one cluster unless the model is not
close to any bones (we could assume that
the model is always assigned to the parent
bone unless otherwise assigned by way of the
closest point algorithm, just as a way of alerting the user
to the problem).
Morph ---> Cluster
(this is one to one the same as what the relative vertex
keying system does with meshes and surfaces, only applied to
clusters which pull on the points in the model, if you've
messed with Maya you know what I'm talking about)
Read as "a Morph Interpolator of a Cluster" can
affect the influence of one or more clusters to a
model, while the cluster can have zero or more
(this should read zero or one) morph interpolators.
It wouldn't make much sense to have multiple
morph interpolators fighting to control the same
cluster, unless somehow the cluster can distinguish
between the morph interpolators and combine them,
but this would nullify the need for the interpolator.
Controller ---> Morph
Controller controls the morph (interpolator) of the clusters.
Controller ---> Joint
Controller accesses the joint parameters to
make a decision on how to behave. The result of
this behaviour in relation to a Morph Interpolator
is to control the influence of particular
clusters by popping values into the morph interpolator.
I should leave this relationship here a little open, there
could be a controller that produces multiple outputs (a program,
such as a python script) or the controller could be a single
expression that outputs a value, in which case there may
be multiple outputs to the morph interpolator.
Controller -----|> expression
Controller is a kind of expression (this is a inheritance
relationship, it means that the controller takes on the
attributes and methods of the expression class/object).
Flexor ----|> Cluster, Lattice
Blender already has a object called a lattice that
influences the placement of points for models that are
parented to it.. The Flexor is like a lattice that
controls clusters, so it inherits from a cluster
or is a hybrid of the lattice and cluster. Haven't
determined the best relationship here, its purely interpretive
or descriptive of the relationship that flexors have different
The main difference between clusters and flexors aside from the
use of a lattice to deform the cluster, is the
flexor is directly influenced by a joint and aligned with
upper and lower bones. If its not influenced by a joint
its a lattice being applied to a cluster (unless there should
be a need to call it something else).
Another thing to mention, where there is a parenting
relationship, there is a transform, or a transform matrix..
Flexors are parented
to joints so whatever orientation there is of a
joint, a flexor is at least transformed by the
transformation matrix of the joint.
Also the clusters
that are parented to the bone are transformed by
the bone so they move and rotate with the bone, because
matrix transformations are applied to them,
as are the flexors to the joints.
The flexors however
are aligned with the bones that the joints are
The Cluster will not be affected by
the joints unless through a morph interpolator
driven by a Controller, or by way of being part of a flexor.
Since the controller
knows about the morph interpolator and the
morph interpolator knows the Cluster, the cluster
doesn't need to know of the influence other things
have on it. Nor does the model.. It keeps the relationship of the
bones and joints to the cluster types, simple
without over complicating the relationship by considering
other data types that can be transformed and deformed by the
bones and joints.. It also allows the rigging and configuration of
skin groups to seperated in the middle of the process,
so that bones can be adjusted apart from skin groups..
The model shouldn't have to be transformed
by the bones or joitns directly, this is the responsibility
of the clusters and flexors. Also the model doesn't
even have to know that its being deformed at all..
The skeleton doesn't have to know its modifying
a mesh/surface/curve/... . The flexor/clusters
only have to know about affecting models and the
bones/joints only have to know how to deform
cluster types (including the flexor).
What is the order of application?
First you determine the joint rotations via your IK solver,
after the joint rotations are computed,
The bone and joint transforms are applied to clusers and flexors.
(note the model's display has not been modified yet)
Then the cluster types that are parented to the bones/joints are
evaluated (they modify the model display database).
Then secondary clusters are applied (pose morphs, modify the model display database).
In the event that a skeleton is applied to the deformation of the
model, will the model display be replaced with the actual model.
This assumes that the model display and model share the same
kind of vertex type, but not the same vertex database.
Also if there is any additional transformers and deformers outside of
the skeleton structure, those should be applied to the skeleton if
the skeleton is being deformed. Or after the dekeleton deforms the
mesh if the mesh is being deformed.. Utimately there should
be precedence that can be determined by the user. The
scoping of this operation could be limited by a concept like a group
(maybe it could be called a scope or a focus, I don't know) that limits
the orders precedence of a group of objects,
transformers and deformers. Precedence is a programmers
terms for an order of operation. Precedence is often defined ahead
of time and used to simplify the representation code by assuming
an order of operation.. Like in C: a = 3 + 4 * 2; by precedence rules
multiplies come before adds, so 4 is multiplied by 2 before being added to
3, and last the value is assigned to a. But it should be possible for
in blender to the user to rearrange precedence to achieve
different results.. Like if multiply was a "scale" transformation and add
was a "translation" (or move) operation, we could make our object
four times its size and move it 3 spaces to the right, or we could
redefine precedence and make it so that objects are moved
3 spaces to the right and scaled 4 times (with respect to the
origin). If you use Maya, this is a little like defining order of application
of rotation, scale, translation.
See Ton, ain't it beautiful what you can do with some UML and
a little though?
PS- How this flexor/cluster, bone, skinning relationship is different
from Maya or Wavefront products.. Wavefront's Kinemation did not
support the deformation of Surfaces/Polygons by the same flexor/cluster.
The concept of the cluster is really a "Alias" concept.. Wavefront called
them "Flexors" in Kinemation, but Wavefront had no actual
deformers outside of what could be had through dynamation with
particle forces. Alias invented features like Relative Keying using a
average of clusters as poses, controlled by sliders that
could be keyed. I represent the sliders here as controlling expressions,
and the flexors are a combined lattice (which blender already supports)
with a cluster that is a concept I stole from Alias Power Animator 8,
which I have used.. Its also in Maya. Also Kinemation had the ability
to key flexor positions according to keyframes or joint keyframes (like
keyframes according to time, only time = joint rotation). And
Alias power animator used a similar idea with clusters driven by
joints, only the amount of interpolation could be controlled with a kind of
IPO per relative key, and the time-line for the morphing between
clusters was controlled by the joint rotation).. In both Poweranimator
and Kinemation, you could controll at cluster with a joint anywhere in
the skeleton. With maya you can possibly control any relative keying
anywhere in a skeleton or elsewhere with a joint or a slider..
Sliders in poweranimators were really defined as two objects that
changed a value in relation to each other and the slider part had
constrained values on two axis, so it could only move up and down,
and could be constrained on the remaining axis, and parented to the
slider-base so the tranformation was local.. This is only if you
wish to implement sliders that have multiple dimensions, like a
dial, button, switch, etc.. in the 3D space.. The expressions allow
a sort of freedom to define strange interfaces, this should be left up to the
user to define.. But there can be input from a Panel in blender,
should the user need something more solid and dependable.
I'm going to work on the graphical representation of this structure
in relation to blender types..