Important Math - Matrices

Alright. This is the big one.
If you can master matrix math, Maya will truly bend to your whims.

Let's start by going over Maya objects' transform data. An object's transform consists of four attributes, each broken down into three dimensions. You're perfectly familiar with the first three: Translate, Rotate, and Scale. But the forth? It's called Shear. You might have seen it in the attribute editor a few times but avoided making eye contact.

Take a moment to play with some shear values to see what it does. I always get confused and think it's called "Skew", because that's what it does. It skews the object

How odd. Why bother including that, Autodesk? Surely it can't be that useful.
Well you're right, it rarely comes in handy. I've made use of the Shear attributes a grand total of zero times.
The reason it's here is not because anyone at Autodesk really wanted specifically to include it, it's an emergent attribute from how Maya and most 3d programs process spatial information: with matrices. (singular: 'matrix', plural: 'matrices')

I strongly recommend taking the matrices course over on Khan Academy (it's free!) but I'll do my best to get you started and explain how matrices are useful in Maya.

https://www.khanacademy.org/math/precalculus/x9e81a4f98389efdf:matrices

A matrix is a table of numbers.
That table can have any number of rows and columns (a single number has even been described as a 1x1 matrix. It's weird. Don't worry about it.) We'll be talking exclusively about 4x4 matrices because that's what Maya uses. That's what's needed to describe the position, orientation, scale, and shear of an object in 3d space.

Have a look at this:

This matrix describes an object in three dimensional space that is - as we'd say in Maya - "zeroed out". It has a translate of (0, 0, 0), a rotation of (0, 0, 0), a scale of (1, 1, 1), and a shear of (0, 0, 0).
This is what's called an identity matrix. It's just a matrix with equal rows and columns and is all zeroes except for a diagonal strip of 1's going from top left to bottom right.
Here are some other examples of identity matrices:

Although, those describe the spatial properties of objects in other numbers of dimensions.

For Maya, in 3d space, we only care about 4x4 matrices.
There are also rules about how two or more matrices can interact with eachother, such as that two matrices can be added together ONLY if they have the same number of rows and the same number of columns, but as long as we're talking about Maya, you can safely ignore all of that, because any matrix you encounter in Maya will always be a 4x4 matrix.

So let's get back to that 4x4 identity matrix:

You might think "Oh okay, so that diagonal strip of 1's must be the scale values!"
Yeeeeeees... but also no. Notice there are four 1's in this matrix. What's the forth one for when there are only three scale attributes?
Understand that while a 4x4 matrix contains all thee same information as a set of translate, rotate, scale, and shear attributes, it's not simply those same values redistributed around a 4x4 grid. Obviously. I mean how does 12 attributes turn into 16 entries?
To illustrate this, let's look at the matrix of an object that isn't zeroed out:

 

 

Above is an example of an object, and bellow that are its transform attributes, and bellow that - inside the red outline - its matrix. The matrix represents all the same information as its transform inputs. But as you can see by looking at the values in the transform attributes and then at the values in the matrix, there isn't any immediately obvious logic to how one equates to the other. I mean, in the top left position of the object's matrix is the value 0.791. Where did that come from? There's no 0.791 anywhere in that object's transform attributes!
Well that 0.791 isn't simply a one-to-one representation of any one attribute. All the values in the matrix can be derived from all the transform data taken together, and vice-versa.

If you want to know how to make sense of matrices by hand, then like I said, take that course on Khan Academy. Great stuff. But for now Maya has some tools that will do the math for you. You need to know for now not so much what a matrix is but what a matrix does.
As I said before, a matrix is just a method of storing and organising all the translate, rotate, scale, and shear information. For our purposes, it's just a seemingly jumbled bunch of 16 values that in some way represent all that data. And we may not be able to make sense of it (not without a pen, paper, and some elbow grease) but it makes perfect sense to Maya.

So your next question might be "Why matrices at all then? Arranging those attributes like they are in the attribute editor works perfectly well, does it not?"
Well it works well for us humans, yes. Understand that matrices have been around for a lot longer than 3d software. Mathematicians found that matrices can make it easier to perform repetitive equations on large (often VERY large) arrays of numbers.
You know - like what a computer does.
"Why matrices" you ask? Because compiling all this transform data into matrices is more computationally efficient.

But you're right - what's easy for a computer to think about is not always easy for the human user. We have an easier time thinking about 3 dimensional motion as the combination of three separate 1 dimensional motions each in a different axis. Which is why Maya's interface converts an object's matrix into disparate transform attributes so we can have an easier time interacting with that object's transforms.

Converting and splitting up a matrix like that is called Decomposition.
And doing the reverse, compiling those values into a matrix is called Composition.

"Alright, that's fascinating and sexy and interesting and all that, but if Maya translates matrix math into my stupid human language and back again, then why do I need to care what goes on under the hood?"

Because there is certain additional, very useful information about transform objects in Maya that can be accessed ONLY via matrices.
An example:

I have an object. It has some values in its transforms. If I want to know what those values are, I can just look in the channel box. In the attribute editor if I also want to check out its Shear values. But that's only its local transform data; its transforms relative to its parent. But what if its parent has transforms of its own. What if I want to get the object's world transform data? I don't want to know where it is in space relative to its parent, I want to know simply where in the world it is. Not how far from its parent it is, but how far from the scene origin.
How would you think to get that information? You could take the local transform values of the objects and subtract the local transform values of its parent. That'd do it. But this quickly becomes impractical. Imagine having to do that when an object is 12 parents deep in a hierarchy. *shudder*. No thanks!
And furthermore, what if any of these parents has had its transforms frozen at some point? Then what of us?!

Well as long as you're cool with messing around with matrices, every transform node in Maya provides you with its world transform data already prepared for you. You just have to know where to look.
Node Editor awaaaaaay!

Look at all these matrices! What the for reals heck?
In this case, since we want the object's world transform data, we'd get it from the worldMatrix attribute.
But matrices can help us out in even more scenarios.

- parentMatrix gets you the local transform data of an object's parent. This is useful when you want to do math based on the different between an object's space and its parent's space, but you don't want to go straight to the object's parent because as soon as the object gets reparented, that information will be out of date, so you can instead use parentMatrix just get the node to contact its parent for you, whatever that parent happens to be.

- inverseMatrix gives you a matrix that contains transform data inverse to what the matrix would get you. Again, useful when doing math where you need to counter certain transform information. 15 in translate X plus -15 in translate X gets you back to zero, does it not?

- inverseParentMatrix. That's right! Did I stutter? A transform node will also happily give you the inverse matrix of its parent!

- And of course, regular old matrix will give the object's local space matrix which contains the exact same information as can be found in the channel box. But it's still handy to have an attribute that will give you the info in matrix form.

So now that we have these matrices, what can we do with them?
Well at any time you can convert a matrix to translate, rotate, scale, and shear data using the decomposeMatrix node, and back again with the composeMatrix node:

So if you need an object's world position, but you need it in the form of good old dependable translate values, you can take the object's worldMatrix attribute, pipe it through a decomposeMatrix node and get the values you need from that node's outputTranslate attributes.

If any of these noes don't appear to exist on your end, it's probably because the plugin has unloaded somehow. Matrix nodes are semi-native to Maya. They come from a plugin, but that plugin comes preinstalled with Maya. And honestly it's ridiculous that they aren't just a part of Maya's core code. But the name of the matrix in any case is matrixNodes.mll.

Other matrix nodes include:

addMatrix:
To get a new matrix that is the sum of two matrices, use this node. But I warn you, matrix addition doesn't yield the result you're probably expecting. The result is more like a matrix of the averaged position between the two objects whose matrices your adding together.

Quick tip with this node (and the next one), when plug in your first matrix, the second input often won't be generated until you collapse the node and expand it again. Doing so is the equivalent of giving the node a slap and yelling "Oi!"

To get a result more like adding two objects' transforms together, use...

multMatrix:
Okay this will definitely sound weird but to get the effect of adding the transform data of two objects together, you have to multiply one object's matrix with the other's.
I told you, matrices are out there, man! I mean, it checks out. It is logical - that's frustrating thing about math - when something doesn't make sense, you're the arsehole.
This can be accomplished without fuss using the multMatrix node. Perfectly simple, just plug any matrix attributes straight in. As many as you like, and it will spit out the a new matrix that corresponds to the sum of all those objects' transforms.

If this is weird to you I strongly recommend setting up a scene like this:

Move, rotate, and scale the two locators around around and see how the cube follows.
Then switch between using the output from the addMatrix node and the multMatrix node and see how their behaviuors differ.
The best way to get a feel for this stuff is to get your hands dirty.

fourByfourMatrix:

If you just need to compose a brand new matrix on the spot that isn't derived from any actual object, this node is simple. It had 16 inputs, corresponding to each place in a 4x4 matrix, so just fill them out and ka-plow! Brand new matrix output.

inverseMatrix:

In most cases somewhat redundant since any transform node will just give you the inverse of any of its available matrices, but if you ever need to flip a matrix to its inverse you can simply run it through an this node and the result will be that matrices inverse.

Maya 2020 had a real focus on updating how intuitive it is to work with matrices and introduced nodes like:

blendMatrix:

Exactly what is says on the box. Plug in some matrices, and adjust the weights the blend them. Example, plug in matrices from two objects, set both of their weights to 0.5 and it will split out a new matrix as from some hypothetical object whose transforms are half way between the original two objects.
At least one of the matrices to be blended needs to go into the attribute inputMatrix. The all subsequent matrices can go into targets [0], [1], [2], and so on.
We used to do this with a node called wtAddMatrix, which you can still use if you want, but so far my impression is that blendMatrix makes that node totally obsolete.

pickMatrix:

Translate, rotate, scale, and shear information can all be derived from a matrix, but while they're in matrix form, they have to go everywhere together. Maybe you want to filter out certain information from a matrix. Maybe a matrix has the translate data you want, but you need it to have zeroed rotate data. Well you could decompose it and then recompose it using only the attributes you want not zeroed, but that's a hassle and a half. Instead you can just run it through a pickMatrix node and from the attribute editor switch off/on any combination of translate, rotate, scale, and shear.

This might all seem dumb, but it's important to understand this stuff because several rigging techniques are built on directly manipulating matrices.
This will serve as the foundation for several dazzling do-hows I'll surely post about in future.
Hey. Are you still using constraints? You are? Did you know that makes you a sucker? It's true! And I'll show you how, soon... with matrices!