# Rigging

## Maya matrix nodes – Part 1: Node based matrix constraint

This post is a part of a three post series, where I will try to implement popular rigging functionalities by only using maya’s native matrix nodes.

Following the Cult of rig lately, I realized I have been very wasteful in my rigs in terms of constraints. I have always known that they are slower than direct connections and parenting, but then I thought that is the only way to do broken hierarchy rigs. Even though I did matrix math at university, I never used it in maya as I weirdly thought the matrix nodes are broken or limited. There was always the option of writing my own nodes, but since I would like to make it as easy for people to use my rigs, I would rather keep everything in vanilla maya.

Therefore, when Raffaele used the `matrixMult` and `decomposeMatrix` nodes to reparent a transform, I was very pleasantly inspired. Since then, I have tried applying the concept to a couple of other rigging functionalities, such as the twist calculation and rivets and it has been giving me steadily good results. So, in this post we will have a look at how we can use the technique he showed in the stream, to simulate a parent + scale constraint, without the performance overhead of constraints, effectively creating a node based matrix constraint.

### Limitations

There are some limitations with using this approach, though. Some of them are not complex to go around, but the issue is that this adds extra nodes to the graph, which in turn leads to performance overhead and clutter. That being said, constraints add up to the outliner clutter, so I suppose it might be a matter of a preference.

#### Joints

Constraining a joint with `jointOrient` values, will not work, as the `jointOrient` matrix is applied before the rotation. There is a way to get around this, but it involves creating a number of other nodes, which add some overhead and for me are making it unreasonable to use the setup instead of an orient constraint.

If you want to see how we go around the `jointOrient` issue just out of curiosity, have a look at the joint orient section.

#### Weights and multiple targets

Weights and multiple targets are also not entirely suitable for this approach. Again, it is definitely not impossible, since we can always blend the output values of the matrix decomposition, but that will also involve an additional `blendColors` node for each of the transform attributes we need – `translate`, `rotate` and `scale`. And similarly to the previous one, that means extra overhead and more node graph clutter. If there was an easy way to blend matrices with maya’s native nodes, that would be great.

#### Rotate order

Weirdly, even though the decompose matrix has a `rotateOrder` attribute, it does not seem to do anything, so this method will work with only the `xyz` rotate order. Last week I received an email from the maya_he3d mailing list, about that issue and it seems like it has been flagged to Autodesk for fixing, which is great.

### Construction

The construction of such a node based matrix constraint is fairly simple both in terms of nodes and the math. We will be constructing the graph as shown in the Cult of Rig stream, so feel free to have a look at it for a more visual approach. The only addition I will make to it is supporting a maintainOffset functionality. Also, Raffaele talks a lot about math in his other videos as well, so have a look at them, too.

All the math is happening inside the `matrixMult` node. Essentially, we are taking the `worldMatrix` of a target object and we are converting it to relative space by multiplying by the `parentInverseMatrix` of the constrained object. The `decomposeMatrix` after that is there to break the matrix into attributes which we could actually connect to a transform – `translate`, `rotate`, `scale` and `shear`. It would be great if we could directly connect to an input matrix attribute, but that would probably create it’s own set of problems.

That’s the basic node based matrix constraint. How about maintaining the offset, though?

### Maintain offset

In order to be able to maintain the offset, we need to just calculate it first and then put it in the `multMatrix` node before the other two matrices.

#### Calculating offset

The way we calculate the local matrix offset is by multiplying the `worldMatrix` of the object by the `worldInverseMatrix` of the parent (object relative to). The result is the local matrix offset.

##### Using the multMatrix node

It is entirely possible to do this using another `matrixMult` node, and then doing a `getAttr` of the output and set it in the main `matrixMult` by doing a `setAttr` with the `type` flag set to `"matrix"`. The local `matrixMult` is then free to be deleted. The reason we get and set the attribute, instead of connecting it, is that otherwise we create a cycle.

##### Using the Maya API

What I prefer doing, though, is getting the local offset via the API, as it does not involve creating nodes and then deleting them, which is much nicer when you need to code it. Let’s have a look.

``````import maya.OpenMaya as om

def getDagPath(node=None):
sel = om.MSelectionList()
d = om.MDagPath()
sel.getDagPath(0, d)
return d

def getLocalOffset(parent, child):
parentWorldMatrix = getDagPath(parent).inclusiveMatrix()
childWorldMatrix = getDagPath(child).inclusiveMatrix()

return childWorldMatrix * parentWorldMatrix.inverse()
``````

The `getDagPath` function is just there to give us a reference to an `MDagPath` instance of the passed object. Then, inside the `getLocalOffset` we get the `inclusiveMatrix` of the object, which is the full world matrix equivalent to the `worldMatrix` attribute. And in the end we return the local offset as an `MMatrix` instance.

Then, all we need to do is to set the `multMatrix.matrixIn[0]` attribute to our local offset matrix. The way we do that is by using the `MMatrix`‘s `()` operator which returns the element of the matrix specified by the row and column index. So, we can write it like this.

``````localOffset = getLocalOffset(parent, child)
mc.setAttr("multMatrix1.matrixIn[0]", [localOffset(i, j) for i in range(4) for j in range(4)], type="matrix")
``````

Essentially, we are calculating the difference between the `parent` and `child` objects and we are applying it before the other two matrices in the `multMatrix` node in order to implement the `maintainOffset` functionality in our own node based matrix constraint.

### Joint orient

Lastly, let us have a look at how we can go around the joint orientation issue I mentioned in the Limitations section.

What we need to do is account for the `jointOrient` attribute on joints. The difficulty comes from the fact that the `jointOrient` is a separate matrix that is applied after the `rotation` matrix. That means, that all we need to do is, in the end of our matrix chain rotate by the inverse of the `jointOrient`. I tried doing it a couple of times via matrices, but I could not get it to work. Then I resolved to write a node and test how I would do it from within. It is really simple, to do it via the API as all we need to do is use the `rotateBy` function of the `MTransformationMatrix` class, with the inverse of the `jointOrient` attribute taken as a `MQuaternion`.

Then, I thought that this should not be too hard to implement in vanilla maya too, since there are the quaternion nodes as well. And yeah there is, but honestly, I do not think that graph looks nice at all. Have a look.

As you can see, what we do is, we create a quaternion from the joint orientation, then we invert it and apply it to the calculated output matrix of the `multMatrix`. The way we apply it is by doing a quaternion product. All we do after that is just convert it to euler and connect it to the rotation of the joint. Bear in mind, the `quatToEuler` node supports rotate orders, so it is quite useful.

Of course, you can still use the `maintainOffset` functionality with this method. As I said though, comparing this to just an orient constraint it seems like the orient constraint was performing faster every time, so I see no reason of doing this other than keeping the outliner cleaner.

Additionally, I am assuming that there is probably an easier way of doing this, but I could not find it. If you have something in mind, give me a shout.

### Conclusion

Using this node based constrain I was able to remove parent, point and orient constraints from my body rig, making it perform much faster than before, and also the outliner is much nicer to look at. Stay tuned for parts 2 and 3 from this matrix series, where I will look at creating a twist calculator and a rivet by using just matrix nodes.

## Maya performance test – Follicle vs Classic rivet

The classical rivet was a really popular rigging thing a few years ago (and long before that it seems). I am by no means a seasoned rigger, but whenever I would look for facial rigging techniques the rivet would keep coming up. What is more, barely if ever people suggested using `follicle` to achieve the result, generally because the classical rivet evaluates faster. So, I thought I’d do a maya performance test to compare them.

#### Prerequisites

I will be looking into the performance of a `follicle` and a classical rivet, both on a NURBS sphere and on a poly sphere. NURBS because I tend to use a lot of ribbons and poly, because it’s a popular feature for attaching objects to meshes.

I will be using Maya 2017’s Evaluation Toolkit to run the performance test, as it gives nice output for each evaluation method, even though I cannot imagine using anything but parallel.

The way the tests are going to work is, I will create two files, each containing the same geometry with 10 rivets. In one file I will use follicles and in the other the classical setup. The deformation on the geometry will just be keyed vertices and it will be identical for each setup, so we can be sure that the only difference between the two files is the riveting setup.

Then, the test will be done in a new scene where I will reference the file to test a 100 times. For each setup I will run the evaluation manager’s performance test and take the results and compare them.

Okay, let us have a look then.

#### NURBS

##### Classical rivet setup

So, the way this one works is I just loop from 1 to 10 and I create a `pointOnSurfaceInfo` node with `parameterU` set to `iterator * .1` and `parameterV` set to .5. Then, I plug the output position directly to a locator’s `translate` attr. Additionally, the output position, normal vector and a tangent vector go into an `aimConstraint` which constraints the rotation of the locator.

##### Follicle setup

This one is fairly straightforward, I just created 10 follicles, with `parameterU` set to `iterator * .1` and `V` to .5.

##### Results

Bear in mind, `EMS` refers to serial evaluation and `EMP` is parallel.

``````NURBS surface
Classical Rivet
Playback Speeds
===============
DG  = 13.1694 fps
EMS = 11.1359 fps
EMP = 20.7469 fps
-----------------------------
Follicle
Playback Speeds
===============
DG  = 11.3208 fps
EMS = 12.6263 fps
EMP = 27.8293 fps
``````

Even though I expected the follicle to be faster I was surprised by how much. It is important to note that we have `10 * 100 = 1000` rivets in the scene, which is obviously a big number. Therefore, in a more realistic example the difference is going to be more negligible, but still `7.8fps` is quite a bit.

What is also quite interesting is that in `DG` the follicle is slower than the classic rivet. So, the stigma of the old days that the classical rivet is faster, seem to be deserved, but parallel changes everything.

#### Polygons

##### Classical rivet setup

So, when it comes to polys the classical rivet gets a bit more complicated, which I would imagine results in a larger slowdown as well. The way this setup works is, we grab 10 couples of edges, which in turn produce 10 surfaces through a `loft` node. Maintaining history, the nurbs surfaces will follow the poly geometry. So, we can perform the same rivet setup as before on the nurbs.

###### Follicle setup

On a mesh with proper UVs the follicles are again trivial to set up. We just loop 10 times and create a follicle with the appropriate `U` and `V` parameters.

##### Results
``````Polygon geometry
Follicle
Playback Speeds
===============
DG  = 1.7313 fps
EMS = 3.32005 fps
EMP = 9.79112 fps
-------------------------
Classical rivet
Playback Speeds
===============
DG  = 1.05775 fps
EMS = 1.52022 fps
EMP = 3.31053 fps
``````

As expected, follicles are again quite a bit faster. I am saying as expected, as not only do we have a riveting setup as in the NURBS case, but also there is the edges and the `loft` which add to the slowdown. I am assuming, that is why even in DG the classical rivet is still slower.

#### Conclusion

So, the conclusion is pretty clear – `follicle` rivets are much faster than classical rivets in the latest maya versions which include the parallel evaluation method.

## Rigging in Maya – Main concepts

Rigging in maya tends to be a very straight forward and no bullshit process, so getting a grasp of the fundamentals will pretty much be enough to let you build your knowledge further by experimenting with different approaches and techniques. Therefore, in this post I’ll describe all the essential building blocks of a rig.

Disclaimer: This post is going to be a continuous work in progress, as I will keep adding rigging concepts as we go.

#### Nodes

Now, even though the dependency graph is not an essential knowledge for a beginner rigger who just wants to build rigs, it is absolutely crucial for grasping the fundamentals of how rigging in maya works. As such, it is vital for understanding the following points of this article.

In a most broad aspect the dependency graph is the place where the scene is described in terms of it’s building blocks – nodes. A node is essentially similar to the concept of a function or method in traditional programming. If you are not into programming, then you can think of a node as a sort of a calculator, which takes in some data in the form of an input, modifies it and it returns the output data. Nodes seem to be used in a lot of the major packages in the 3D industry – Maya, Houdini, Nuke, Cinema 4D, etc., so it is a concept which is useful to understand.

Every object in a maya scene is described by one or more nodes. And when I say object I do not only mean geometries, but also locators, cameras, deformers, modeling history (polyExtrude commands, polyMerge, etc.) and a lot of other stuff we don’t need to worry about. If you are curious about everything that’s going on in a scene, you can uncheck the Show DAG objects only checkbox in the outliner.

A simple example is a piece of geometry. You would expect that it would be described by one node containing all the information, but there actually are two. One is a transform node, which contains all the transformation data of the object – translations, rotations and scale (world transformations). The other is the shape node, which contains all the vertex data to build the actual geometry (local transformations), but we don’t need to worry about this one just yet.

A very cool thing about nodes is that we can actually create our own. The Maya API allows us to write custom nodes in Python and C++.

Further reading: Autodesk User Guide: Node types

#### Joints

In a non-technical aspect a joint is incredibly similar to a bone of a skeleton. A number of them are chained together in order to create limbs, spines, tails, etc., which in turn together form exactly that, a skeleton. These joints then are told to influence the body of a character or any other object and that’s how you get a very basic rig.

In a more technical approach to describe a joint, we can start off by saying it is a transform node. Therefore it has all the usual attributes – translation, rotation, scale, etc., but there also are some new ones like joint orientation and segmentScaleCompensate.

The segmentScaleCompensate essentially prevents the children joints in the hierarchy from inheriting the scale of the parent joints. And it is generally something we don’t need to think about at all, if you are not rigging for games. If you are, you will need to turn this off and work around it in your rigs.

The joint orientation on the other hand, is absolutely crucial for rigging. It is such an extensive subject that I am considering writing a whole post just about it. Here is a good post on the topic. Describing it briefly, joint orientation describes the way the joint is going to rotate. That is the reason it is called orientation (I think), because in a sense it shows us which way is forward, which is up and which is to the side.

So to summarize, a joint is a transform node with extra attributes, used to create hierarchies (joint chains) which in turn form a skeleton, used to drive the deformations of a piece of geometry.

#### Skinning

In non-technical terms skinning is like creating a sock puppet. You stick your arm (the joint chain) inside the sock (the geometry) and by moving your hand and fingers the sock is being deformed as well.

In a more technical manner, skinning is the process of binding a geometry to a joint chain. In maya nodes terms, this action is described by a skinCluster node. Essentially, when skinning a piece of geo, maya calculates all the vertex positions of the mesh relative to the joint they are influenced by and stores that data in the skinCluster. Then when the joint is transformed in any way – moved, rotated or scaled, the vertices of the mesh follow that transformation, by applying their relative positions on top of the transformed positions of the joint.

#### Other deformers

A skinCluster is what maya calls a deformer. It makes quite a lot of sense if you think about it as a skinCluster does exactly that – it deforms the geometry using the joints. Now, there are other deformers as well and even though they work in many different ways, essentially what they do is, they take a version of the geometry as an input (they can take as input the output of other deformers which allows us to chain deformations), deforms it and outputs the new deformed points into the shape node. Some good simple examples are the nonlinear deformers.

Just like with nodes (deformers are essentially nodes themselves) we can write our own custom ones, which is very useful. For example I have written a collision deformer which makes geometries collide and prevents intersections.

#### Weight painting

Remember how in the skinning section I said “maya calculates all the vertex positions of the mesh relative to the joint they are influenced by“? Well how does maya know which joint a vertex is influenced by? You see, each component of the geometry can be associated with one or more joints. On creating the skinCluster maya will assign some joints to the components, but more often than not you won’t be satisfied with that assignment. Therefore, you need to tell maya which joints should be driving a specific component. The way you do that is by a process called weight painting.

When we say weight, we basically mean amount of influence.

It is called painting, because by doing so, we are creating weight maps for each joint. As with many other aspects of CGI, these maps range from 0 to 1 although we can choose to go above and below if we want to, but I wouldn’t advise doing so, just because it’s much harder to keep control of your weights this way. So a value of 0 means that this specific region of the geometry will not be deformed at all, by the current joint. Obviously then, 1 would mean that the region will be deformed entirely by the current joint. Values in between mean that the joint will influence the component some but not entirely. It’s important to note that any component needs to have a total weight of 1 (again if we are chosen to work with normalized weights, but as I said this is the suggested approach), therefore if you lower the influence of one joint over a specific component, another or a combination of multiple other ones will receive that remaining influence.

Additionally, all deformers can have their weights painted. SkinClusters seem to be the most complex ones to paint because they have multiple influences, but generally with most other deformers – nonlinears, blendShapes, deltaMush, etc. – there is a single weight per vertex describing how much influence the deformer has over that specific vertex.

Some very useful features of weights are that they can be mirrored and copied. Additionally, they can be stored and loaded at a later point, though maya’s native options for doing that have been very very limited, but this article gives some good tips about it.