Rigging essays and rants

This category contains my thoughts about rigging in general and in the animation industry specifically. It is all about loving what we do and getting better at it.

When it comes to rigging in a production or many productions the name of the game is reusability and automation. In that sense rigging is very similar to traditional software development, as we also have to build systems that are easily maintainable, extensible and reusable. There are a few ways to achieve that in rigging and today I am going to look at some of them. The reason I wanted to write this is that rigging systems are one of the big things I wished I had learned earlier.

Disclaimer: This post will probably come out very opinionated and those opinions are going to be based on my own experience, which really, is not that extensive. Additionally, even though there are going to be informative bits, I am writing this more of a way to share my thoughts instead of trying to teach anything as again, I am not really qualified in any way to do that.

Also, please bear in mind that the larger portion of this post is going to be very speculative since I am talking about tools that I have not really used myself.

A rigging system

I just want to briefly go over what I mean by rigging systems. Essentially, everything that takes a model and produces a rig out of it is a rigging system to me. That means if you just rig an entire thing manually you are the rigging system. If you use a tool similar to maya’s HumanIK that is your rigging system. That means that any system that by following a set of instructions can on it’s own produce a rig is a rigging system. Other than just building actual node networks, rigging systems should provide easy ways to save and load a bunch of properties and settings such as deformer weights, blendshapes, control shapes, etc.

Rigging system types

With the definition out of the way we can have a look at the types of rigging systems out there.

Auto rigging tool

Disclaimer: This is going to be the most speculative portion of this post, as I have never used one of these solutions, other just having a brief look at them.

The auto rigging tool is a rigging system which takes care of everything we talked above by providing you with some sort of a guiding system to define the proportions and often the type of a rig (biped, quadruped, wings, .etc) and then using these guides, it builds node networks which become rig components.

Some examples of auto rigging tools are maya’s HumanIk which I mentioned above and also a popular non-Autodesk one is Rapid Rig.

There are a lot of them online and also they are usually a big part of rigging showreels as it seems that every rigger who starts learning scripting, goes for an auto rigging solution at some point. Including me.

Now, the problem that I have with this kind of rigging systems is the lack of extensibility. I have not seen an auto rigging tool with any sort of an API so far. That means that, for every rig you built you have only a limited number of available components (that number might be a large one but still limited). What I mean by that, there is probably only one arm component available and even though there might be many options on how to build that arm, there is a chance you are not going to find what you are looking for and would like to insert your own logic somewhere in that component, but there is no way to do that.

Mentioning the many options brings me to the next issue I see with auto rigging tools – performance and clutter. The way I see it, the more options you want to support inside of just one single component, the more clutter you would introduce in the logic of that component, in order to accommodate those options. Additionally, if everything is happening behind the scenes, I have no other way of knowing what the tool creates than just opening the node editor and having a look at the networks, which as you could imagine is not going to be fun on large rigs. That opaqueness scares me, as I would not know about potential node clutter introduced in my scene.

That brings me to my next point about auto rigging tools, which is the fact that everything is stored baked down in the scene. What I mean by that is, the auto rigging tool might give you some options for rebuilding parts of the rig after they have been created, but ultimately everything we store is baked into node networks. Yes we can save our weights and maybe some properties outside of the scene file, but these would be things that go on top of the auto rig product. There is no way to store how we actually constructed that rig. Then if I need to change the position/orientation of a joint, how do I go about that? What if, god forbid, the proportions of the model have changed? Do I delete everything and rebuild it? And if I have to do that, what happens with the parts of the rig that I have added on top of the auto rig, do I need to manually rebuild them as well?

The last thing I want to mention about auto rigging tools is UI. I mean, it is usually bloody horrible. I think it is probably all down to the native UI tools that maya gives us, which all feel very clunky. They just don’t seem to work for anything as complex as a rigging system. All of the auto rigging tools I have seen make an extensive use of tightly packed buttons, checkboxes and text fields in loads of collapsible sections or tabs, which just doesn’t seem to cut it in 2017. Again, I think the main issue there is that Maya’s native tools are just not enough to build anything more intuitive. That being said, PySide has been available for a while.

Maya Human IK rigging system UI

So, if you are going to be building an auto rigging tool, please keep in mind the following ideas can improve your work with that rigging system a lot

  • creating some sort of an API for easily extending/modifying the functionality of the tool, mainly by creating new or editing existing components
  • storing information about the actual building of the rig instead of just the baked down version of it, in order to enable you to easily rebuild it when changes need to happen
  • create a more intuitive UI than what is already out there. Node graph maybe?

Rigging framework

Going beyond auto rigging tools, we have rigging frameworks. Those are systems which do not necessarily have any high levels components such as arms/legs/spines built into them, but instead they provide you with the tools to create such components and save them for later use. The only system of this type that I know of is mGear. Incidentally, it does actually provide a high level modular system called Shifter that does give you everything that an auto rigging tool would. The good thing here, though, is that using the actual framework you can build your own modular rigging system and extend and modify it a lot.

Now, since I have never actually used it take everything I say with a grain of salt, but from what I understand, similarly, to an auto rigging tool you would build everything in the viewport and then save it as a baked down version. I do not know how easy or difficult rebuilding components is, but if anything has been built on top of them it would have to be also manually rebuilt.

What I really like about mGear, though, is the open source aspect of it. The fact that you can grab it and build out of it a rigging system that would suit your needs perfectly, is amazing.

Guidable modules

Now, this one I think is the only system that you can create yourself without any scripting. Even though, it might be a bit slower to work with, I think in terms of results you would be able to get everything you get out of an auto rigging tool.

So, what I mean by guidable modules is, say, storing a rigged IK chain with all the controls on it in a file and then when you need an IK chain in a rig you bring the one from the file. The rigged IK chain would have some sort of guides (usually just locators) that would be able to reposition the joints and stretch the chain without actually introducing any values on your controls and also the stretch values would be recalculated so there is no actual stretch on the chain, but instead the modified version becomes the default state.

I know that sounds a bit weird and it probably won’t sit well with many of you, since referencing/importing files is often considered dirty because of all the stuff that gets carried across. That being said, if you clean up after yourself, that would not be an issue.

Additionally, if you are referencing the components in the scene, you can modify the components themselves and the changes would be carried across all of your rigs utilizing that component.

What is more, the same idea can easily be applied to a rigging framework or an auto rigging tool you built yourself, so it removes the issue which arises when changes need to be made.

Rigging framework with modular rigging system through an API

Now, the last rigging system I want to talk about is one that combines aspects of all previously mentioned ones, but in a way where extendability, maintainability and reusability are all taken care of. That comes at the expense of not having a UI, having rules and conventions and requiring a thorough programming knowledge.

The way an user interacts with this rigging system is entirely through an API. The way the rigs are stored is in actual building information rather than a baked down version, which means that every time you open the rig it is built on the spot, making changes incredibly easy and non-destructive. And the way the components are created is through an actual Python class, benefiting from all the benefits (and unfortunately negatives) of object oriented programming.

So, the rigging process with this sort of a system is going to be writing code. Of course, we still need to paint weights and store control shapes, but these are easily saved and loaded back in. Here is an example of what a rig might look like in this system.


initializeRiggingStructure() # Creates the boilerplate for a rig - top/god node, etc.

spine = bodyCommands.spine(spineChain)
arm = bodyCommands.arm(armChain, spine.end)

... ## Build all the components you would want


The loadGuides() function refers to a file which contains all our guides, similar to the previous rigging system. In this one, though, it is up to you what sort of guides you use. For example, for an arm you would just draw out your arm chain and the module will take it from there.

This is the rigging system that I like using. It feels much more intuitive to me as I do not feel any restrictions from anything, be that UI, pre-built components that I don’t have access to, etc. If I want a slightly different module I can just inherit from the old one and make my changes. If there is a model change I just need to reposition my guides and run my code.

The main downside of it is that it might get a while a new person to get used to such a system. Having a nice documentation and examples would help a lot. Another thing, people might feel uncertain about is the complete lack of UI, but again for me it is liberating to not be constrained by buttons, text field, etc.


I am very happy with the current rigging system I am using described in the previous section. That being said, though, I cannot help but think of things I would like to see in a rigging system.

For starters, let us go back at UI. Even though, I feel great about being able to do whatever I want with the code, having an UI for certain things would be much quicker. What ideally I would like to do is be able to have both working at the same time. Whatever I write needs to be reflected in the UI and, the harder bit, whatever I do in the UI I need to be reflected somewhere in my build file, so next time I build the rig it comes with the changes made from the UI as well. Having an UI modifying my code, though, does not sound amazing, so we need a different way of handling that, which could potentially be metadata. The one issue I have with relying too much on metadata is that it is not immediately obvious what is going on.

Another thing I would really like to see at some point is some sort of a rigging system standard where riggers around the world can exchange components and general bits from the rigs with each other. To be honest, though, I am both excited and worried about something like this, as introducing a standard might significantly hinder innovation.

The big thing that lies in the future, though, is getting a higher level of interactiveness while rigging. Complex builds using the rigging system from the last section can take minutes to build, which means that for every single change I make in the guides file or the build I will need to wait a lot to actually see the result. That is making the process a lot more obscure, when you just need to keep changing stuff in order to hit the right values. Imagine, though, that we have all that building happening in real-time. Say I have the guides opened in one window, the build file in my text editor and I have the product in another window. Ideally, what I would like is by moving something in my guides file, to trigger a rebuild of that “dirtied” portion of the build which would result in the changes applied in my third window without actually deforming my model.

I am saying this lies in the future, though, aspects of it are already taken care by the guidable components method described above. That being said, that full level of interactiveness is what I would ideally like to achieve.

As I said in the beginning, a lot of these are just my own speculations, which means that I am still trying to figure most of this out. That is why, I would love to hear your tips, opinions and ideas on rigging systems, so please do share them!

I was so amazed the first time I learned about the script node. Now that I look at it, I feel like it is a necessity, for sure, but back before I had no idea that they, callbacks and scriptJobs existed, I often thought that it would be amazing to have a way of running code at different points of interaction with rigs (and any other maya scene). So when I finally learned about them, naturally, I tried to think of cool things I could do with them as, and today I will have a brief look at some of these alleged cool use cases and some not really cool ones.

Disclaimer: Raffaele over at the Cult of rig has some great videos that go over callbacks, script nodes and a great explanation of how they fit in the overall maya event loop. Once I saw those videos everything started making much more sense, when working with callbacks and script nodes, so I cannot recommend them enough. He goes over the use of script nodes to manage callbacks and I will not be going over that, so definitely have a look at his latest videos.

Additionally, this post will be mostly speculative since a lot of these ideas are just that – ideas that I have not yet tried, but sound like they might be cool.

Also, there are a few examples of unethical behaviour mentioned as potential uses of the script node, so I want to make it clear that I DO NOT encourage them, but instead I want people to be familiar with them, in order to be able to protect themselves.

Table of contents

script nodes in rigging

When I think about script nodes I instantly picture animators opening/referencing scenes and cool stuff happening without them having to touch anything, and yeah, I suppose that is probably the major use case scenario. I wouldn’t imagine myself needing a script node in my files, since I can easily run the code I want to run whenever I want to.

Rigging systems

That being said, though, say we have a rigging system, where we script most of the rig, but we still do certain things in the viewport as well, quite possibly through some cool custom UI we’ve built. That UI will very likely rely on some metadata inside of the scene and probably some message connections between nodes. Wouldn’t it be nice if this UI auto-populates itself and pops up ready to be directly used, without you having to touch anything? Sure, you can probably do that with just pressing a single button after the scene is opened, but I think having it happen automatically feels cooler.

Additionally, I know a lot of people have debug modes of their rigs, which take care of what I am about to say, but if you don’t it might be nice to have a script node remove the restrictions you have added for animators and turn on any diagnostics you have in the scene.


Recently, I have been looking into running some minor analytics on rigs and I have to say I see why every marketing person out there praises analytics. It is an eye-opening experience seeing how many unitConversion nodes you have in the scene and maybe plotting that against the performance results you are getting to see if they are slowing you down (they probably are) and by how much (probably not much).

Again, this one is going to be purely speculative, but maybe we can gather some data on our own practices when rigging. Say for example, query the time spent working on a specific rig or maybe even run performance tests on opening or closing the file in debug mode and store that data over time.

script nodes in animation

So, even though, there might be some use cases for script nodes in rigging, I think they can be really useful for automating boring stuff for animators. Whether it is going to be related to building and loading certain UIs, creating certain connections between assets or similarly to the previous paragraph – analytics – we can use the script node to make animator’s and our work slightly easier, more intuitive and informative.

Attaching props

This is probably the best use case of the script node that I know of. I know different places and teams definitely have different approaches to this issue, whether it may be custom tools that are used to bring in and attach props or, god forbid, having all props in a character rig file and using switches to turn them on and off, it is a common aspect of pipelines. I think a nice solution are script nodes. Let’s imagine the following case.

Say we have a character that needs to have all kinds of different weapons, clothes and other wearable props. Let’s suppose all these are their own separate assets, so maintaining them is easier and nicer. The way script nodes would help us in this case is by executing a piece of code that would attach our prop to our character on bringing that prop in a scene where the character exists. That would be a nice and simple solution. Of course, it could lead to some issues, for example, having animators bring the prop in before the character or maybe have multiple instances of the character, so our prop does not know to which it should attach, but generally these issues are either solved or prevented by having some pipeline rules.

Building interfaces

This one is probably more appropriate for freelancers, free rigs and cases where the people working on a project don’t necessarily share a pipeline.

Animators often have to do a lot of animation in a short time. Anything we can do to help them out is going to be great for our production. A nice way we can do that is by giving them easy to use interfaces to speed up their workflow. I know a lot of animators use pickers, so maybe we can use script nodes to build them with all their jazz on the spot. Additionally, they might be like me and love marking menus. Wouldn’t it be great to be able to build it for them on the spot and maybe even show them a message, so they know how to bring it up? Then of course, clean up after ourselves when they close the scene, so we do not mess about with their other work.

script nodes in pipeline

Now even though script nodes can be quite handy for rigging and animation, I think where they really shine is in pipeline. Granted, pipeline would probably use scriptJobs to do most of the things I am going to mention, maybe small teams or even freelancers can sort of simulate a pipeline by using script nodes.


I talked about analyzing our behaviour when rigging, but I think it is much more practical to actually analyze the working files of animators and lighters, as the data in there will probably be a bit more interesting. For example, we can run performance tests on certain scenes when opening/closing them and then at the end of a production identify problematic areas, so we can potentially have a look at improving them.

Additionally, this one feels a bit unethical, but if we are upfront about it, it might be cool to store some data on how people interact with our rigs. Create some callbacks on nodes and attributes we are interested in, and have a look at how they are being used. Then when closing the file save that data somewhere we can have a look at it, or in any other way send it to ourselves. We might just find that 50% of the control we are adding to rigs is not actually being utilized.


How can we prevent our files from being used by people we do not want to use them? I think “do not let them have our files in the first place” is the reasonable solution, but maybe we cannot entirely prevent that. In cases like that, we can add a level of protection by using script nodes.

Since we can fire a script on opening a scene file, that means that we have some room for licensing our rigs. Now, while I am not entirely sure what the best way for forbidding access to a rig would be, I have a couple of ideas.

Inform us

This first option is not necessarily forbidding anyone from using our rig, but we might be able to setup a way of informing us of unauthorized access to our rig. For example, we can check if the user is unauthorized by looking for a specific environment variable that members of our team would have, looking up maya’s license or maybe even the OS username. If we find that the user should not be using our file we can send the information to ourselves by using a simple HTTP request.

I know this can easily be bypassed, but chances are it might just work in certain cases.

Obviously, this involves an amount of tracking users, which I really DO NOT encourage, but I could imagine certain people in certain cases might want to do that.

Break the rig

If the file is being opened as opposed to referenced we have the ability to break connections, delete files, etc. If that is the case we can easily destroy our rig on opening it, so people cannot even see it.

If it is being referenced though, we do not have that level of control. In cases like this it might be worth having an obscure way of breaking your rig, built into the rig itself. I do not think this could ever be bulletproof, but I think it is certainly possible to make it way too annoying for anyone to mess with it. That being said, it is likely that doing that is going to introduce some overhead in your rigs, so it is not an entirely too graceful way of going about it.

Close or hang maya

I feel like I am getting silly here, but I think that for people that really do not want anyone touching their rigs, they can certainly do a maya.cmds.quit(f=1) in the script node and be done with it. Additionally, if you would like to be extra nasty, I suppose you could do something along the lines of

import maya.cmds as mc

while True:
    mc.warning("All work and no play makes Jack a dull boy!")

Alternatively, if you do not want to be nasty I think the nicest way of denying access would be to just unload or remove the reference, but you would need to have a stable way of finding the reference node. If you cannot do that, you could also do a mc.file(new=1, f=1) to pop out of the scene.

script nodes security

So, escalating from the previous section, I am sure you could imagine that if we could hang and crash maya we probably can do much worse things. Since we are able to run python, even though we have a smaller than the default amount of packages included with maya, we are able to actually execute code entirely unrelated to maya. You know, create/read folders and files, run native OS commands, etc. What if we create and read files from the user’s machine that we really shouldn’t be? Additionally, there are included libraries in Maya that are making it trivial to send data over the internet. You can see where I am going with this.

I do not want to carry on mentioning unethical schemes, but I do want to raise your awareness about the extent to which script nodes can be used. Essentially, everything that is available to the user running maya is available to the script node and therefore to the person that published that file. Which leads us to the next point.


Now, depending on your OS, the ways that we can protect ourselves from malicious vary, but there are a couple of concepts that we can apply to all of them.

Careful when downloading files

The easiest thing we can do is to not use any files created by other people. Depending on what you are doing in Maya that might be okay, but I for example, very often open popular rigs to see how have they done certain things and how can I improve on top of them.

If you like me do occasionally load up files from the web, there is another check you could do. Open the .ma file with a text editor and check if there are script nodes in there. Since text editors can have a hard time with larger files, you can always write a small python function to check that for you. If the file is a binary file, though, you are out of luck and there is no way to check what is inside of it other than opening it.


The obvious one. If the user running maya does not have access to a certain directory, maya doesn’t and hence the script node doesn’t. Please DO NOT run maya as a super user or administrator as that would obviously give maya access to anything.

The practical way of doing it I would say is to create a specific user which is going to run Maya and give it permissions only under a specific directory where you would store all your Maya work. That way, everything else is out of reach.


Limit Maya’s access to the internet. That can be a reasonable solution, but Autodesk probably wouldn’t be happy with it, as that way you cannot sign into your Autodesk account.


As you can see script nodes can be really powerful in terms of use cases in a proper production or freelancing and also powerful in malicious ways. I like to believe, though, that people in CG are generally quite intelligent and nice, so therefore I can safely say I am not troubled by the potential exploits.

In most productions finalizing the rig is actually half the battle. Depending on the role of the asset, but most often than not, you will need to maintain that rig. Which means to constantly provide fixes for issues that the animators and you might have missed at first glance. Additionally you may need to adjust skin weights for better deformations or maybe some props need to be attached to a character. Things like that. Therefore it is very important to have good Communication with animators. It all starts when we present/publish our finalized rig.

Of course, you should not be making a big thing out of it, but if there is anything you are uncertain about in the rig it is always good to shoot a quick message or have a chat with the animators about it. They would appreciate it as well. So, I would like to go over some points to keep in mind when communicating with animators, which have helped me through my projects.


Even before the assets have been modeled, it is always great to grab some character concepts and pose/expression sheets and have a chat with the different departments. I cannot stress the importance of this, as often people tend to think of only their own little part in the big picture, which leads to lads of issues in other departments. Imagine having been passed a robot model that needs to move in a specific way, but in the place where you would expect a swivel mechanism or a ball and socket one, you have a solid plate. Happens way too often. Don’t do that to your animators.

At this early stage all you need to understand is what controls would they expect and how do they expect them to work. Obviously if the character is a standard biped you already know this and do not need to have this chat. But if your character has a long neck, more than two legs/arms, it is worth having a chat and seeing what the animators would expect from the rig. If you are asked to add a feature which you are not sure about, say so. Most of the time it would be something you can easily test within minutes, so if you are not pressured by time give it a go and come back with a clear answer. Never shoot yourself in the foot by saying you will add a feature without actually being sure how it would work. You would be surprised how well people respond to a reasonable explanation of why something would not work.

Old rigs and early model

In the past I have offered animators I have not worked with some of my previous rigs, just so they can see how I usually work and what I tend to provide in a generic rig. You do not have to do it of course, especially if you are not pleased with your old rigs, but it sometimes helps put context to what is being talked about.

Depending on the budget of the film you might be able to do some tests before starting the actual rigging process. If you are working on a personal project or a student group project, this is essential. Grab an early version of the model and build a basic rig around it. Think about where the joints will pivot from and test out what would give you best deformations. Do you need supporting joints? Maybe ribbons? Are you going to have to add some corrective shapes to areas? A lot of this can be identified very early on and the earliest you know about it the better. Obviously the more generic the character is, the more obsolete this point is.

The point of passing an early or older rig to the animator is to start getting the issues as soon as possible. You should always reasonably expect that there are going to be issues.

Publishing the rig

Once you are done with the rig, depending on the asset, you can either just publish it or do some explaining with it. In big productions there are so many assets that explaining them is not practical, and honestly having to describe how your rig works is something you should not have to do. The rig should speak for itself, through it’s controls, attributes, etc. In some cases though you might have a limited choice of control shapes. But I digress. The cases where you would explain things about your rig are when working on small projects with a couple of characters and you could really focus on them. In such small teams you are bound to have a chat about everything which is great.

Something that horrifies me is a rig with loads of features which end up not being used at all. It happens way too often. All these features do in that case is bog down the performance. So make sure the animators know about all the features and their benefits. It would make their lives easier and your time spent worth it.

You should not expect an animator to go through each and every control and make sure it works properly or has everything that it needs. That would be amazing, but you should not expect it. The way these things come up is by the animators actually posing the rig and seeing how it behaves. They cannot possibly know each pose needed, so you really should not be expecting them to have a look at everything. Let them play with the rig in front of you, while you mention all the good and bad stuff about your rig. This way they can have a bit of a clearer picture of what they have to work with.


From then on, rigs occasionally come back with the animators flagging up a missing or broken feature, messed up deformations, bad control shapes, etc. Needless to say, you should never get angry with an animator or feel like they are the enemy, because first that is stupid and second they are probably trying to get the best out of the asset just like you are.

Most of the time animators ask for features which are possible and sensible. Occasionally though, you would get asked to do something that just will not work. It might be a limitation of the software (Maya has plenty) or a limitation of the design. In either case, it is very important to learn to say no to animators and be firm about it. Of course, you should be trying to give them the best possible rigs, but when something will not work, you should say so. More importantly, you should explain and if possible illustrate why it will not work. Nobody will ever be convinced if you just say “Nah, that won’t work” and you will look like an asshole. You will find that everybody in the industry makes compromises, when you keep your cool and explain the problem. This is key.

As I mentioned in the What do we need from a model post, just remember to not be a dick and keep in mind you are all part of the team, trying to make the best possible project you can.

A lot of the time many beginner riggers complain that the bad deformations they are getting are down to the model. It is a possibility, but in any case we should examine the models we get before we start rigging them, so we can be relatively sure what we are working with can actually achieve what we want it to. Therefore I’d like to examine what do riggers need from a model.

We will go over the expectations that we should have from a model when we start rigging it. Most of these are really basic and I am sure you know them, but it is important to remember to look for them before we start working on an asset.


Obviously the big one. That is the first thing we were taught at university. It is the base of the technical part of modeling, as our whole production relies on deforming that topology.

What do we need from it then?

In my opinion we can split the most important aspects of the topology to:
– edge flow
– quads
– resolution

Edge flow

First and foremost, the edges should be following the features of the face and body. We will never be able to achieve a decent looking smile shape if the edge flow does not provide us with the circular loops around the mouth and the edges around the nasolabial fold. In beginner projects usually the faces look very very uncanny, and a major contribution to that is the bad edge flow.

What we are looking for in a good edge flow is a nice description of the anatomical structure of the model. We need to be constantly thinking about how would these verts look when we pull them in this or that shape.

Here is a nice example. Notice how the edges flow around the facial features

What do riggers need from a model - good topology example

And here is some bad topology. Notice how the edges just create a grid laid over on top of the face. None of them are actually following the shapes.

What do riggers need from a model - badtopology example

There are a lot of changes of directions of the loops in a good edge flow. These changes usually result in what is called a pole or a star, meaning a vertex which is connected to five other vertices instead of four. Take a look around the eye area of the good example and notice how the circular topology of the eye merges into the mask going around both eyes and eyebrows. This leads us to the next point.


This is the main thing people say when thinking about topology, that the model should consist only of quads. And yeah that is mostly true, but there are plenty of examples of good usage of triangles as well, so if you find that you need to have a triangle, by all means have it, provided that you have done your deformation tests and the triangle does not mess anything up.

That being said, I tend to keep all quads in my models as well.

Now another part of the conversation about quads and triangles is the poles I mentioned above. The thing with the poles is that they distort the quads around it quite a bit, making it easy to get shearing in that area which is a no no. If we are to have a proper edge flow, though, these are inevitable so we should make sure they are positioned at places where they will not have to be deformed a lot relative to their immediate neighbours. In other words, try to put these poles in places where the whole area will move more or less together.

Altogether though, I feel that the importance of all quads have been overstressed, mainly because it is an easy rule to define, and people tend to love having a solid rule to guide them. In this case though, if we really need triangles and we are smart about it there is no problem using them. Just again, make sure they do not get in the way of the deformation. Following the rule about poles – having the whole area move together – should be enough to make them work.


Another big thing with topology is resolution and we as riggers should learn to be very picky about this one, as it is easily adjusted in most cases, but can cause a world of pain when painting weights.

When rigging characters, if there is a problem with the resolution it is usually that is too high. A lot of people would argue that this should not a problem, but I strongly disagree. Yes, there are many workarounds of course, but it is still an issue.

Here are my two reasons for being aware of dense geometries.

They are denser than needed

I am a big proponent of doing everything with a specific purpose in mind, as otherwise you are just bloating your life. If the higher density does not have a specific purpose like fixing texture stretching or adding wrinkles, etc. just lower it. We should not be spending time nor mental resources on stuff we do not need.

Painting weights is a pain

It is tedious and annoying painting weights on very high res meshes. Yes we can get smoother results, but the price you pay is keeping track of much more vertices. Additionally, the brush size needs to be very small in order to paint precisely and that again slows us down. Additionally distributing twist along many edge loops is just a punishment.

Of course there are techniques to overcome these issues, but if we can completely get rid of them, for me that is the better choice. Some of these techniques include, having a lower res geometry which we actually rig and then either copy our skin weights on the higher res one or drive it through a wrap deformer. As for painting smoother weights, we can always create temporary geo, skin that and copy the weights to our models. I often do that for cylindrical parts of the bodies like legs, arms, spines, etc. Getting a nice twist distribution becomes very easy.


Riggers love housekeeping! We love stuff that is clean, elegant and makes sense. Who doesn’t actually? The difference is that we would usually go out of our way to make sure everything in the project is in order. Everything except our My Documents folders I guess.

So what does housekeeping mean in the context of a model?

It is more to do with the actual scene file than with the model, but it boils down to these few points.
– No history (except for the occasional lattice deformer for cartoony eyes)
– No transformations
– Proper normals
– Symmetry (except for cases where asymmetry is intended)
– No purposeless nodes
– Multiple shapes or multiple parents

No history

An obvious one. History makes the scene messy. And we do not like messy. Additionally, it slows down the scene quite a lot, because due to the nature of maya’s dependency graph all nodes that are upstream (are on the input side of a node) need to be evaluated before we evaluate the one we actually need. Considering, it is as easy as Alt + Shift + D, this one should never be a problem.

In some cases history is needed, like for having a character with non spherical eyes.

No transformations

This is not a deal breaker usually, but can cause issues sometimes, so generally a freeze transformations is considered a good practice. The issues that can be caused are mainly due to the inheritTransforms attribute we sometimes need.

Proper normals

99% of the time this is not a problem for us, but if we use some fancy setups that rely on normals, obviously it is important to have the normals working correctly. Additionally, this is going to be an issue for the further stages of the pipeline, so it is best if we catch it and solve it.


This obviously does not apply to models that are meant to be asymmetrical, in most cases of cartoony characters though, that should not be the case. The only area that might need asymmetrical features would be the face. Apart from that, having everything perfectly symmetrical makes our job much easier. Mirroring joints, skin weights, controls, etc. is a breeze.

No purposeless nodes

This is kind of similar to the No history one, but deleting history does not delete all unused nodes, as they might not be connected to anything. What we could do in cases like that is run the Optimize scene size command, but take a look at the potions and make sure you are not deleting stuff you might actually need. Additionally, we can always script something to clean up our scenes, but if there are native tools to do it, why bother.


With shape nodes, sometimes we might have more than one under a transform, depending on how the modelers arrived to that final shape. If that is the case, it would be best if these are deleted before they are passed to us. That being said, if they are needed for some special purpose, they can be left in there, although that should be kept in mind as there are a lot of scripts out there that grab the first shape of a transform and operate on that.

Additionally, a shape node can have more than one parent – it is instanced. Again, that might be needed for your production, but sometimes modelers forget they have instanced stuff that will need to deform in different ways, which will not work.


I keep reiterating that riggers should make sure rigs can achieve the desired shapes from the pre-production. Just take a look at the model side by side with the pose and expression sheets and think about whether the geometry will be able to support the necessary deformations. I know it is a bit arbitrary, but more often than not just taking a minute to think about that can be really helpful.

And lastly, I know this is a whole essay in itself, but please make sure you ask the modeler for changes nicely. We are all in the same boat together, part of the same pipeline, trying to get the best of our projects. Riggers are known to be kind and considerate and you should do your best to live up to the expectations!

As any other creative endeavour, rigging tends to have a steep learning curve. There is just so much to learn. But fear not, the steeper the learning curve the higher the satisfaction of going along.

Previously, I have written about how I got to be a rigger, but I do want to go over the thoughts that made me persist with it. Because, persistence and deliberate practice is the only way to acquire and cultivate a passion.

So, a lot of people getting into rigging for the first time start with trying to rig a character. I understand that, usually there is a need for that, so it only makes sense. It is unrealistic though to expect that the rig will be any good. Which is of course fine, considering it is your first time rigging. But making something that sucks is quite discouraging. To make it easier for yourself to persist with it, I would suggest to predispose yourself to winning. How do you go about doing that?

Well, a common example is making your bed. If you do it first thing in the morning you have started your day with a small win. If you setup more tasks like that you create a chain of success, which tricks your brain on expecting and predisposing yourself more towards the same thing.

So, instead of a character rig, how about starting with the bouncing ball? If the animators start with it, why not us? I did not rig a bouncing ball though, so preaching rigging one does not sit right. What I started with was a super simple anglepoise lamp like this one.

Anglepoise lamp

It is quite similar to pixar’s luxo junior, so I thought it would be a good fun and it really was.

After that I moved on to rigging an actual character. It still sucked, but I definitely felt good about it, because even though I had rigged something before, it was still my first character rig. Additionally I remember how excited one of the two rigging workshops that I had at uni got me. There was this setup of train wheels.

Train wheels pistons rigging

The lecturer asked us how to go about rigging this, so we only control the rotation of the wheels and the pistons would follow properly. If you have some basic rigging knowledge, give it a go. Pistons are always a fun thing to rig.

The reason this got me excited was that it actually opened me up to the problem solving aspect of rigging. You are presented with htis situation and you have to find a way to make it work in a specific manner. That’s it. There might be many ways to go about it, but in the end the desired result is only one. This means you cannot bullshit your way out of it, because if it does not work, it is pretty clear that it does not.

So after you have got some simpler tasks under your belt and maybe you have started rigging your first character there will be a lot of roadblocks. And I do mean a lot. Sometimes you might think that your problem is unique and you will not be able to solve it but I assure you, everything you are going to run into in your first rigs most of us have gone through, so you can always look it up or ask. Honestly, we seem to be a friendly and helpful lot.

The way I overcame most of my roadblocks was to open a new file, build an incredibly simplified version of what I am trying to do and see if I can build it, however messy it gets. This helps isolate the problem and see clearly all sides of it.

At about this point where you have some rigging knowledge I would suggest opening the node editor and starting to get into the vastness of maya’s underlying structure. I do not mean the maya API, although that is certainly something you’d need to look into at a later point, but more to get familiar with the different nodes, how they work and potential applications of them. If you are anything like me you would want to build your own “under the hood”. It is a blessing and a curse really as sometimes I feel too strong of an urge to build something that is already there just so I can have it built myself. It’s crazy and very distracting, but also it gets you asking questions and poking around which proves to be quite useful.

So seeing the actual connections of everything you do is really nice in terms of feeling that you understand what you are doing. For example, if you graph the network of a parent constraint you would see where the connections come from and where they go, which will give you some idea of what happens under the hood. Same goes for everything really – skinClusters, other deformers, math nodes, shading nodes, etc. What this is supposed to do is to make you feel like you have a lot to work with, because you really do. With the available math nodes, you can build most of the algorithms you would need. That being said, the lack of trigonometry nodes is a bit annoying, but you can always write your own nodes when you need them.

The last tip I can think of for keeping your interest in rigging would be to start scripting stuff and not use MEL to do it. There is nothing wrong with using MEL if you really want to, or to support legacy code, but considering that 99% of what is done with MEL can be done with Python and the other 1% is stuff you definitely do not need I consider using MEL a terrible idea for your future. Python is a very versatile programming language and also (personal preference) it is simple, very pretty and quick to prototype with. Honestly, I think The zen of python is awesome to live by.

Honestly, I think everyone should learn to code, not only because in the near future it will expose a lot of possibilities to make nice changes in your day to day life, but also because of the way coding makes you think about stuff. Some of the main benefits I find are:
– The process of writing a script to do something makes you understand how it is done
– The time saved is invaluable
– The satisfaction of seeing your code work is incredible

Then what I would do after having some rigging knowledge, some maya infrastructure knowledge and some scripting knowledge is build a face rig, and take my time with it. If you create a nice face rig, it will be loads of fun to play around with it, which is very satisfying. And I am sure, at that point you will be hooked.

That’s it. I covered most of the things that have kept me interesting in rigging while I was struggling with it. I am sure that if you have picked up rigging enough to read this post, you already are a curious individual so sticking to it will not be hard.

How does rigging fit in the pipeline? Where does it sit and how does it communicate with the other parts aspects?

The pipeline is being upgraded and changed to fit the specific needs of each production company or team. But these changes are not in terms of the big scale of the process, but more to deal with smaller things. Therefore, generally the path an asset takes would be something like:

Pre-production > Modeling > Texturing > Rigging > Animation > Lighting > Rendering > Compositing

Building the shaders, kind of goes throughout the production as an asynchronous process, because it is not restricted by anything to start doing tests.

Bear in mind that even though these are sequenced in a proper production there is and there should be a lot of going back and forth to make sure we get the best of the asset. Obviously, more than one task can be worked on at the same time. For example, there is no reason to do some lighting when animation is in it’s blocking stage, or to do the texturing while rigging, etc.

So what about rigging?

Well, it fits nicely between modeling and animation. If you think of this sequence as a node in a graph or just a function, it would take model as input and spit out something that animation needs as output. Riggers tend to always look for clear and absolute solutions which would always be valid, but of course that would be too easy. And also very repetitive and boring for us. Do you want to be a node in a graph?

Now, how does rigging expand beyond modeling and animation though? Well, how do we make sure that the director will be happy with every shot? We can never be sure, but the best way to go about it, is to go back to the stages which have already been approved and get from them as much as we could. So we could go back to pre-pro and look at the character sheets. Does the character in the animation move like it has been designed to move? Do the character’s facial expressions match her character sheets? Do you see where I am going with this? We as riggers need to constantly look back at the pre-production and make absolutely sure that we are creating a rig which can fit the purposes of these designs. And if for some reason that is impossible, it is our job to bring it up, so it can be decided whether it makes sense time-wise to go back to pre-pro and fix it or we have to scrap that particular feature of the character.

Similarly, looking ahead a rigger should not only be looking at the animator. Way too many people look at lighting as just placing a couple of lights, setting some render preset and pressing a button. Of course, you are in for a big surprise if you try getting a lighting job with these expectations. Lighters tend to work with a lot of caches that may cause issues. They need to come up with clever techniques to overcome problems like for example on my film Naughty Princess the lighter asked me to make a small camera rig, so we can always keep the character in focus properly. Or another one we have used was to rivet a locator to the character so following her is easier. Often, deformation issues would come up in the lighting process and good communication is crucial to solve them quickly. Additionally, in terms of housekeeping, the smaller we can keep the file sizes the better for everyone else, as loading them can become painfully slow.

So there we have it. It would be stupid and unrealistic to think that rigging only takes models and spits out rigs for the animators, without thinking about whether this model is coming from and where it’s going. As I wrote in the “Why I Rig” post, one of the reasons is the fact that rigging has such a central position in the pipeline, that we have to communicate and make decisions for different aspects throughout the pipeline.

Considering that my career can easily take over most of my time for the next 20 to 40 years, I believe having good reasons for getting into it is essential.

Even though I do not plan to be doing it for 20 years, I do feel there are some quite strong reasons for my being a rigger in the animation industry. From talking to rigging people I know I gather that some of these reasons are shared among most of us, so do not be surprised if you find them quite obvious.

Nobody else wanted to do it

I think most of us have a story to share on this one, so here is mine. During the second year at university we had a group project aimed at creating an animated short. We had to pitch ideas and request additional members with specific roles. So in my pitch I outlined that I intend to direct and take on modeling and lighting, and that I will need people to do pre-production and texturing, animation and techy stuff – rigging and water simulations. Then when my pitch went trough and I was assigned some teammates I realized I am the most technical person in it, so if I wanted to see my film come to life I would have to rig and run the water sims myself. That’s how I became a rigger.

Now, I was not psyched at all but I was sure I am going to do it, and do it as best as I can, as again that was the only way to realize my idea. From talking to some people who do rigging it seems like this is the most common way of getting into it. What we did not know, though, was that we are going to love it. I downloaded all the tutorials on rigging I could get my hands on (the university gave us access to digital tutors and lynda) and I got on with it. Very soon I was hooked.

Art and maths

Throughout my getting familiar with the process of creating computer animations, the concept of it being a combination of art and maths would keep coming up and understandably so. To add on that, I do find a lot of artistic beauty in maths and it is also no secret that art has greatly benefited from maths as well (rule of thirds, fibonacci spirals, etc.) Additionally, these two have always been my subjects of choice. Unfortunately, I am neither a great painter nor a great mathematician, but I find that exploring each of them individually or their combination gives me a great deal of pleasure and understanding of the world. What is more they converge incredibly well in some fields such as architecture and computer graphics.

Then there is always the discussion in the field whether you are more technical or more artistic as if one undermines the other. Either way, I find rigging to be the sweet spot between the two. We have to make rigs that perform as fast as possible and not break. On the other side we also need to provide the animators with the ability to hit the shapes and poses needed for the production. In other words I think a rigger should be spending half his time on the technicalities of a rig – how well it performs – and the other half on making sure the deformations as appealing as they need to be.

We can go as deep in maths and programming as we want to, or we can let maya handle most of it for us. Similar thing goes for the artistic aspect as we can ask for a very thorough pre-production and try to match that or get a design and explore it to see how it works. Obviously, anatomy is always a big thing in animation, so the more artistic training a rigger has, the better.

Problem solving

The most obvious one probably. I was never one of those kids who were opening up their toys or gadgets to see how they work. I wanted to be though, but it seems I was too easily distracted to keep at it. But then now, it is not unusual to find me awake well into the early hours trying to figure out a problem. I hate going to bed without having cracked it, even though in the morning I am at least twice faster at finding the solution. A couple of nights ago I stayed up until 3am to try and figure out how to make sure maya’s python interpreter would always take my latest code changes without having to restart maya or use python’s reload function.

Another big one was trying to figure out how to build and Ik/Fk matching function for the first time. I had some clues from a friend, but I still spent a long time on that one.

It is stupidly exciting though! Finding the solution to a problem is always an immense satisfaction. If I cant find the solution, I cannot let it go. My girlfriend says “I can hear you think!”.

Rigging lies in the center of the pipeline

It is always nice to see how much crossover riggers usually have in the other aspects. It is no secret that the best riggers are also knowledgeable in modeling and animation. Josh Carey from Reel FX said in an interview that being able to model and animate is one of the main requirements for getting a rigging job there.

As a rigger you would usually have to communicate with all other departments which puts you in a very central and responsible position. I crave these kind of jobs, you know ego and all that. I want to be responsible for a lot of important tasks, so I can always be pushing myself out of my comfort zone.

Additionally, people tend to respect riggers for this precise reason. What is more it, I found rigging helped me to stay on top of things more easily when I was working with other people on my two short films.


One could easily create rigs without writing a single line of code, but you will rarely if ever find such people rigging in the industry. It is just very very inefficient. In a production pipeline it is incredibly important to have a non destructive workflow, which could hardly be the case if not for programming. Imagine having to build an arm rig with all it’s bells and whistles – ik/fk, elbow lock, twist, stretch, etc. – manually each time you rig a character. Not only is it going to be incredibly boring after the 3rd time you do it, but also it is going to take a ton of time, that quite possibly you do not have. If you script it once though, you get it for free every time you need an arm. So obviously, most of the rigging workflows people are based around coding.

Why is that an important reason to me though? Learning the code is really an eye opening experience. It gets you thinking about being effective and efficient. It teaches you to break problems in smaller and recyclable chunks, which can be tackled one by one. The benefits of learning to program are a whole other subject, but I would strongly suggest to anyone excited about personal growth and development to consider learning some basic programming. After all, coding is the engineering of the 21st century and it is going to get even more beneficial as time goes, mainly because everything is slowly becoming programmable.

Better contracts

Disclaimer: This one is completely speculative, because it’s based on talking to my university teachers and my coursemates who are now working in the industry.

With the great responsibility from the Rigging lies in the center of the pipeline point, luckily comes another benefit. TDs of all sorts tend to be paid slightly better than some of the artists in other departments. Additionally, as rigging pipelines tend to need some getting used to, it does not make sense for companies to hire short term riggers. Therefore, we would usually get longer contracts which as most would know is very rare in the animation and VFX industry.

Now for many people this point would not matter, but for me that stability means that I can stop thinking about just surviving, but instead think about advancing and developing myself further in my areas of choice.

These are the main reasons for my deciding to get into rigging. Another one I did not include is rigging being so much fun in general, but I thought it is a bit vague, even though anyone who has ever played around with a good rig knows what I mean.

All in all, rigging has been an incredible journey for me so far, because it has taught me to think in a certain problem solving manner about everything in my day to day life. I am therefore very glad these reasons got me to apply for rigging positions.

As simply put rigging is the process of giving a computer generated asset the ability to move. Whenever a person not in our industry asks me what do I do I generally start with this. Then of course, you can go on to imitate puppets and puppeteers with your hands.

Now not so simply put, rigging is the process of building a system to be used by an animator to deform a CG asset in a very specific manner. This deformation takes place on multiple layers, providing all the needed controls for hitting shapes and poses designed in the pre-production stage.

Okay, let’s deconstruct this.

When I say “deform a CG asset” I mean the ability to translate, rotate, scale or make it squash, stretch, bend, etc. Generally the base of a character rig is it’s bone structure which allows for moving the limbs and body in a way similar to how we move in the real world. That is why researching and studying anatomy is very important for riggers who want to improve.

The piece about the “very specific manner” is in regards to being able to build different types of FK or IK chains, IK/FK blends, blendshapes, etc. The keyword here is specific, because every aspect of a rig needs to come from a need. Every choice in the process of rigging is to always be bound by a good reason for achieving a specific result. Otherwise, we are shooting in the dark trying to hit a moving target. Therefore, it is very important for a production team to be able to communicate exactly what they expect and want to get in the end. Because, if we add a module to a rig “just in case” we are bloating the rig, and please let’s not bloat our rigs.

The “multiply layers” bit refers to the ability of deforming objects in different, but again very specific ways, and then sequencing them in a chain to produce the final result. The face is the classical example of this, where in most rigs people tend to use a combination of a few local rigs – rigs built to deform only in local space and then add them via a blendshape to the world space rig.

Then “providing all the needed controls” is again crucial for keeping the rig as light and clear as you possibly can. In our day to day lives we are very much used to clutter everything we interact with – bedrooms, kitchens, your home folder, etc. But again, when rigging an asset we should be thinking as minimalists. Which is to say, only add controls or functions if they are going to add value to the rig. Also, it is very important to make sure the shapes of the control objects makes sense, so the animators can now instantly what they are about to pick.

And lastly, the part about “hitting the shapes and poses”. Now there are a couple of metrics that describe how good or bad a rig is. Ones that I have mentioned above are functionality, performance and clarity. But in the end of the day, rigging is just a part of the animation pipeline. Therefore, as always we need to have a clear reference point to keep us on the right track. Take a look at modelers and animators, they always have their reference opened up on the side to help them stay consistent. Why would rigging be any different? We should not be thinking that we can rigs that are absolutely perfect for our purposes, without having a clear idea of what those purposes are.

Therefore, making sure that we can get the shapes and expressions that we have received in the character sheets or animatic, or even our own sketches in a more casual production, is not only making it easier for the animator, but it is making it possible to realize the initial concept.