Vertex IDs & Vertex Order

Polymesh objects in Maya are made up of components, like faces, and edges, and such. And the king of components - the most fundamental - is vertices.

Every vertex in a mesh has a unique identifier called an ID that helps Maya tell them apart.
And it's important to understand a few things about these IDs...

Vertex IDs

The reason Maya is able to tell one vertex from another is because every single vertex in a mesh object has a unique number assigned to it called a vertex ID.
The quickest way to see a vertex's ID is to select that vertex and look up at the very top of the Maya window. The name of the object will be displayed followed by a number enclosed in brackets:

What's a Reference?

Referencing files into other files is a powerful feature in Maya.
When incorporated into rigging it allows for a way more non-destructive workflow.
This post will just be an intro to references for the uninitiated.

But first, let's review importation. We need to be sure we understand that so we can appreciate how referencing is different. And then we'll look at some of cool shit you can do in a reference workflow.

So I have two files here. Scene A:

and Scene B:

Joint Placement: Clavicles

Most people's first instinct is to pivot the clavicles from the top of the sternum, which is only sensible as that's where the clavicles pivot from in real life.

And if you were rigging a really, honestly, realistically proportioned human character with corrective systems emulating the muscles and such, that would be right. But 9 times out of 10 that's not the case, even if you might think it's the case.
Look at this character. Looks pretty accurate to reality, no? A reality in which people have time to work out, but still.

Joint Placement: Spine

There's an amusing Simpsons gag I'm very fond of. I'm sure you know it -
Some local children are watching a member of a film crew paint a horse in cow-print. One of the children inquires,
    "Sir, why don't you just use real cows?"
    
    "Because cows don't look like cows in the movies - you gotta use horses",
comes the reply, matter-of-factly.
And for good measure, another of the children then asks,
    "What do you do if you want something that looks like a horse?"

    "Hm... usually we just tape a bunch of cats together."

I find myself thinking about that statement often. "Cows don't looks like cows in the movies"
You'd be amazed just how often that kind of thinking comes up when trying to make something that needs not necessarily to look real under scrutiny but to feel real in the moment.

Knowing how to properly place points of articulation in a rig is about knowing when to use a cow and when to use a horse painted to look like a cow. That is - when to mimic reality and when to spit in its face.
Another way of thinking about this is the difference between simulation and emulation.

Constraints Are Not The Answer To Every Problem

We use constraints a whooooooole lot in rigging, don't we?
They're a no nonsense catch-all solution for when you just want an object to follow another object. Don't care about its hierarchy or none of that, I just want it to follow! Why all these questions? I just want life to be simple!

Well fine. But need I remind you, we are riggers. "Simple" was never in our future.

You may have heard people online saying "Ew! Constraints! Don't use constraints! Constraints are terrible!" So let me fill you in on what they're talking about.
Look at your average constraint in the node editor:

That's an awful not of connections. And that's just a vanilla constraint - once you start messing around with multiple targets, the number of connections increases. Constraints are a nuclear solution to a surgical problem. They take in all kinds of information from the driver object(s) and driven object to make sure that there are a very few curve balls one can throw at it. Every single connection in a network adds a little extra to a rig's evaluation time (how quickly Maya runs and responds when the animator is using the rig). So it's because of all these connections that people say constraints are "slow" or "heavy.

Matrix Constraint

If you don't understand how to manipulate matrices in Maya, have a look at this post first:

https://rigjuice.blogspot.com/2021/08/important-math-matrices.html

A big chunk of how matrices are useful in Maya is in achieving constraint like effects without heavy constraint nodes.
Let's talk about how the actual effects of constraints are uniquely useful over direct connection.

When trying to get an object to follow another, there is often a lot of messy context and complication that means a direct connection just won't cut it. If two hierarchies are spatially identical then direct connections from members of one to members of the other would usually be enough. But what if the hierarchies don't match? Perhaps you need a joint to follow the orientation of a control but the orientation of said control isn't coming form just that control's rotate values? Perhaps the parent above that control is also rotating, and maybe that parent has a different pivot position than the control, so you've gotta do a bunch of trigonometry to figure out how much rotation of that parent ends up being how much shift in the orientation of the control, and then add that to the rotation coming directly from that control with some math nodes and then who knows what else!
Or you can throw up your hands and say "Orient constraint!" [mic drop]

Such a shame there's no other way when things get that complicated...
Oh wait. Matrices.

This is super handy and I want to make sure nobody gets left behind, so I'll take it one step at a time.
Let's make a cube and... I dunno, a locator.