Hi there, my name’s Matt and I’m a content designer here at Autodesk.
In this video I want to quickly go over a game-changing new feature for riggers in Maya 2020.
So, scrolling down the Maya What’s New (which you can find in the link below),
you’ll come across this entry about a new Offset Parent Matrix feature.
While perhaps not as flashy and in-your-face as other features
like Cached Playback enhancements or Bifrost,
Offset Parent Matrix has the potential to be one of the most powerful and versatile new features
when used correctly.
However, to understand it, I’ll need to teach you a bit about how 3D programs actually work.
In math, a matrix is a just a structure of rows and columns filled with numbers –
think of a spreadsheet like you might see in Microsoft Office or Google.
For math-y reasons that I won’t get into, it turns out that you can use these matrices
to represent the position and orientation of any point in 3D space.
So for example, you’re probably already familiar with X, Y, and Z –
the simple coordinates that define a point or vector.
Well, as a matrix, I can write them like this.
Now suppose I wanted to move that point over and rotate it…
…it turns out I can do that by multiplying it with a bigger matrix like this.
This beefy guy here is called a Transform Matrix.
He may look scary with all these seemingly random numbers,
but again this is all math-y stuff that you don’t necessarily need to know how to come up with
(though if you’re curious you can find plenty of resources on the web).
All you need to know is that multiplying a Transform matrix with a point
transforms that point to a new spot.
This is actually the secret to every 3D software ever made.
Whether it’s doing simple transform operations like Move, Rotate and Scale,
complex deformations, keyframe animation, or almost anything else in 3D –
all of it is actually just different ways of building, multiplying, and applying these matrices
to points on a screen.
It’s no wonder they called a movie about living inside a 3D world “The Matrix,”
and had its main character see everything as a bunch of columns of data.
So, this brings us back to the beginning of this video and the Offset Parent Matrix.
This new feature allows you to manually apply one of these transform matrices to a node
BEFORE its own Translate, Rotate, and Scale.
So for example, take this basic cube sitting at the origin.
If I open the Attribute Editor and go to the Transform node,
I’ll find this new Transform Offset Parent Matrix section.
There are two tabs here. Matrix is the pure math matrix I showed you earlier.
However, recall how I said that you didn’t need to know how to come up with this?
That’s because we also offer this much more streamlined version called the Composition.
This distills that complicated Transform Matrix into simple Translate, Rotate, and Scale
attributes just like the ones you’re used to up here.
As expected, applying a transform here moves the cube.
But now watch what happens if I apply an additional translation up here.
It moves based on the Offset Parent Matrix we applied!
Basically, this lets me define the local space of an object without needing to parent it,
constrain it, or alter its pivot.
It also let’s me change that reference point AFTER the fact,
even if my Translate/Rotate/Scale channels are animated or constrained elsewhere.
There’s a LOT of real world uses for this.
For example, suppose you had an animated skeleton,
and needed to move some joints on it (maybe the model’s proportions changed).
Previously this was hard to do without breaking animations, changing joints,
and re-keying things.
Now you can just tweak the Offset Parent Matrix.
This is also a MUCH more powerful way of doing constraints.
For example, suppose I wanted to constrain this cube to the end of a cylinder.
Usually I’d have to create a Parent Constraint...
…and also a Scale Constraint.
And if I go into the Node Editor, those two simple constraints have created this mess.
Not only that but notice how all the cube’s Transform channels are now occupied.
That means if I try to change any of them...
...but then move the cylinder…
…the cube snaps back into place.
See?
The only way to get this working is to delete the constraints...
...group the cube under an extra transform...
then constrain that group to the cylinder.
Of course, this makes everything even more complex.
Now let me show you how to do this the matrix way.
So here I have the exact same cylinder and cube setup.
This time instead of creating a constraint,
I’m going to go to the Node Editor and simply plug the cylinder’s “World Matrix”...
...into the cube’s Offset Parent Matrix.
This feeds the Transform Matrix currently applied to my cylinder
to my cube as well.
Which gets me the same behavior as a Parent / Scale Constraint,
without all the crazy connections!
Not only that, but I can even change the cube on TOP of that without it resetting
and without the need for any extra groupings – something that wasn’t even possible before!
I can even add a pickMatrix node between the two
to choose specific Transforms I want to carry over –
similar to a Point and Orient constraint, but again without the complexity.
Now that you’ve seen what this means in general terms,
let’s take a look at it in a practical setting.
So here we have the Emma rig that we built together in my
"Creating a Comprehensive Character rig" tutorial.
Recall that as part of that, we built compound finger controls
that allow you to set some common poses on them both individually...
...or as a group…
…as well as FK controls that allow you to make tweaks on an individual finger joint basis.
As a little refresher, the way we accomplished this
was by creating extra “compound” movement joints in both the control...
...and result fingers.
We had to do this because setting driven keys for the compound movements would occupy
the Rotation attributes of our FK controls, rendering them useless for individual posing.
Hence these acted as an extra inbetween
(much like the extra grouping I showed in the example earlier).
However, this this approach has a couple of problems.
For one, it requires a bunch of extra compound joints in both our control and result hand.
Secondly, because those compound joints are mixed in with the FK joints,
you’ll end up selecting them by accident when pick walking up or down the FK controls.
This is confusing at best, and potentially rig-breaking at worst
since animators might modify these compound CTRL nodes by accident.
Let’s fix this using Offset Parent Matrix.
Starting with my result pointer finger, I’m going to
re-parent all the result joints to each other while deleting all the “Orient” joints.
These are the joints that were being fed the compound rotations.
As expected, this temporarily breaks the compound control’s functionality.
Meanwhile, on the control hand, I’m going to re-parent FK joints to FK joints
and compound joints to compound joints until the two chains exist side-by-side, like so.
To get them working on the result chain again, I'll just display them in the Node Editor...
...then plug the world_matrix of the compound control joint...
...into the Offset Parent Matrix of the corresponding FK control.
Except now where are my control joints?
Whoa, okay something has gone terribly wrong. Why didn’t this work like before?
Well, one thing I neglected to mention is that the World Matrix attribute
doesn’t just represent the transform matrix of the node it’s coming from.
It actually represents the transformations of all its parent nodes too!
In this case, notice how some of the finger’s parents are translated or re-oriented.
All of this turns the finger’s world topsy-turvy and upsidedown!
But we don’t want all this extra baggage up the chain.
We just want to say, relative to THIS joint, transform these two guys the same way.
Thankfully, I can use the Matrix attribute instead of the World Matrix to do that.
This takes the node’s Transform values as seen here
and applies them as a matrix to whatever I plug it into.
It doesn’t care about parents or orientations or anything else.
Likewise, I’ll have to create the exact same connection between the compound control
and result joint as well.
And now if I run a quick test you can see that my compound control moves both the FK
and result joint at this first segment…
...while I can also make additional FK tweaks on top of that too.
Now that I know it works, I can apply that to the rest of the finger as well.
So again, I’ll take the compound joint’s Matrix...
...and plug it into the FK control’s Offset Parent Matrix…
And then repeat for the result joint.
This time, the connection has pushed my FK joint out a little bit in the X direction.
That’s because unlike the first joint in the chain, this FK joint has a pre-existing translation on it.
But since the Offset Parent Matrix is now taking care of that, all this is doing is doubling it.
So I’ll zero it, to put it back in the right spot.
And then do the same for the result joint.
And then I’ll repeat this entire process one more time for the third segment.
And once I’m done, you can see that all my original compound
and FK controls work again…
I can even make the exact same pose as before.
And because the compound joints have been separated out from the FK joints,
I can pick walk up the FK chain without running into those
annoying intermediate joints anymore.
However, pickwalking down is still a little annoying,
but that’s just because of these NURBs shapes we used as controls curves –
it has nothing to do with the joint setup.
I can get around that by either using both down and right when walking down…
…or by deleting the curves entirely and activating the joints’ handles instead.
Then I can hide the compound joints,
leaving just the controls that the animator SHOULD be interacting with.
And here’s what it looks like on the entire hand.
Using this approach, not only does the rig perform faster,
but we’ve cut 20 joints out of this one hand alone without losing any functionality!
And this is far from the only place where we offsetParentMatrix is useful.
You can use it to replace all the parent constraints, improve space switching,
and simplify the way you do global transforms just to give you an idea of what’s possible now.
I’ll try to get to come back to these sometime in the future,
but for now I recommend checking out the Maya Documentation for a list of all the
matrix-related utility nodes at your disposal to practice your newfound skill.