top of page
Matrix Math Rigs
"Eric" is an enemy robot from our game "Rage Quit". On the outside, this is a simple rig, but under the hood it has some interesting work. The entire rig was created using matrix math in Maya, meaning that NO constraints were used in the making of this rig. Learning matrix math opened my eyes to the underlying reasons why rigs work the way they do. The relationship between 3D space, the objects within it, and optimization was something that fascinated me and was a joy to learn more about.
Goals
Learning how to create a rig using matrices was an important step for me to take as Matrix based rigs are more optimized due to how the math is evaluated in Maya. Going into this project, I had 3 main goals:
1) Learn exactly why this is so important
2) Create a basic IK/ FK character rig with matrices
3) Make the rig compatible with an Unreal Engine 5 pipeline
Why?
Going into matrix-math styled rigging, I wanted to learn what makes these rigs so powerful.
1) Performance: Matrix rigs run significantly better than normal rigs due to how the math is evaluated and reduced dependency on original Maya constraints. Matrix connections are independent operations that can be evaluated across CPU cores, meaning that everything in the rig can be evaluated at once rather than getting held up in one-by-one bottlenecks like with traditional rig setups. Constraints are also heavier as they come packed with extra features that need to be evaluated first, meanwhile matrix connections simply process raw math. They're lighter, faster, and easier for Maya to evaluate, thus keeping file sizes smaller and viewport manipulation smooth for animators.
2) Cleanliness: Matrix rigs are both cleaner in setup but also in use. From a rigging perspective, this setup style eliminates the clutter of extra constraint features, offset groups, and other unnecessary complications that make a mess in the node editor and outliner. Instead, these setups have simpler connections that are easier to trace and comprehend the logic behind them. Using the rigs is also easier due to the lack of extra offset groups.
3) Troubleshooting: Fixing issues much easier due to the simplicity of the connections. Logic is easier to understand and nodes aren't trying to pack too much into one package. It's quicker to isolate a problematic node/ connection.
4) More Control: At first it seems limiting to only use simple math nodes instead of the feature-packed constraints, however in use you find the opposite is true. With matrix setups, the rigger has more freedom to make custom setups that go beyond the functionality of a regular constraint.
5) Understanding: Using the tools Maya provides is a great starting point for rigging, however the downside is that these constraints hide the logic behind the functionality. When going with a matrix based setup you have to understand why things work the way they do. You have to plan the connections accordingly and figure out how something would move if you took a certain step. This is huge for troubleshooting later as you can understand why something isn't working rather than taking a shot in the dark. The lower level comprehension of rigging is also beneficial for tool development. This skillset also translates to other software, this isn't a Maya only skill.
Getting Started
To begin, I had to "start over" from the beginning. The first issue I needed to tackle was how to make a simple FK chain with working controllers. This is where I learned about the "Offset Parent Matrix" in the attribute editor.
Instead of controlling transform attributes, I'm now working with the direct matrix of the joint. This is where the controller behaviors will feed into. The goal is to keep the joints perfectly zero so the rig stays clean and prevents potential issues.
The spine is where I have my first use of matrix math to connect controllers to joints. I want the joints to follow the controllers in world space. To do this, I connected the world matrix of the controller and multiply it by the parent inverse matrix of the parent joint, the pelvis. Let's take a look at the 3 numbers we're working with for this problem.
1) Local Matrix: The offset the spine joint has from the pelvis (X axis: 13.634)
2) Parent Matrix: The position of the parent being the new "center/zero" for the spine joint (parent mtx)
3) World Matrix: The world position of the controller & joint
If you connect just the controller world matrix to the parent offset mtx, you are essentially combining both the world and parent matrices, causing the joint to fly off into space. The spine joint is following the world matrix, but the "world zero" is the parent, which is a problem. This is where the parent inverse matrix cancels out that problem by taking out the parent mtx. This then "returns" the spine joint's world zero to the actual world zero. Lastly, make sure the controllers and joints follow the same hierarchy, so then the local position of the joint is accounted for.
This practice of connecting a matrix to follow and a matrix to cancel out the issues is what I carried throughout the rest of the rigging process, as each part of the set up is basically the same thing. The problem is always finding out how to cancel out a number so the object is in the desired position.
Finishing The Rig
Moving forward with the rig, there were a couple of behaviors I wanted to set up that were beyond simply following a controller. For example, I decided to use a blend matrix for the IK/ FK switches in the arms and legs. This showed me the basics of space switching with matrix math.
I unfortunately did not have enough time to create an IK solver myself so I still used Maya's built in solver, but I was able to support it with matrix nodes though. This is where I got to figure out how to use and obtain numbers for holdMatrix nodes, as they are crucial correctional nodes for spatial issues. An example of this is getting the IK pole vector to point towards the IK arm pole vector controller. I hooked up the controller world matrix and a hold matrix together. The hold matrix was a correctional node that set the pole to aim at the controller, and the world matrix is what moved that point in space. Like before, this was another instance of canceling out a number.
The resulting rig was a success! After completing the basic robot rig, I used this same method to rig the other robot enemy in the game, the "Security Bot", as well as the first person hands rig. In all, the rigs were controlled entirely with matrix math nodes, had no offset groups in the outliner, was animation ready, and was game engine ready.
Animation & Exporting
As the character tech artist on the team, I was happy that I got to use my rig from an animation perspective. Animating this character was a blast! I never experienced any lag in the viewport or any issues that completely prevented me from continuing to work. In total, I got to animate over 60 animations for the robots and the player character.
The next step was to export the characters and animations into Unreal Engine. I ensured all rigs were compliant with UE 5.6 and exported everything as FBX files. I also wanted animations to be shared across characters and not limited. Setting up the skeletons in UE to share animations was an easy process as both skeletons already had the same names and hierarchies.
In Unreal, I set each skeleton as compatible with the other, and I also set the Translation Retargeting options to "Animation Relative". This simple setup allowed for animations to be shared without having to create an extra retargeted animation.
Closing
With the game being completed, I can happily say I achieved my goals of rigging the characters with matrix math, understanding the usefulness of it, and using them for our game. This rigging process required a lot of intentional planning instead of blindly using tools, and I feel like a much better rigger because of it. I now understand how to approach math issues and I'm comfortable with the math nodes enough to build my own tools. While the characters were simple, I can easily see how in much more complex rigs, this rigging approach would be necessary for performance.
To recap everything I learned with matrix math:
1) How to connect joints to controllers
2) Creating FK chains
3) Supporting IK chains
4) Blending between IK & FK (space switching)
5) Matrix problem solving
This rig was a huge milestone for me! I had never gone this deep into rigging, this process was entirely new to me. I'm already looking forward to my upcoming projects where I get to learn the aspects I didn't have time to learn like creating my own IK solver, creating ribbons, and the various matrix nodes I didn't get around to using.
I would like to thank the entire team that worked on the game Rage Quit, and if you haven't played our game yet, we'd love if you checked it out and left a review.
Play Rage Quit here:
bottom of page