My rigging tool has been progressing at a good pace recently. The most obvious improvement came to the UI. Previously I used the basic Maya window stuff, but I’ve now switched everything over to PySide QT. I did this because QT is easier to use, more flexible and jives better with Python (I can extend QT classes for example).
The UI is broken up into four sections; Bits, Components, Modules, and Characters. Each section is a custom QWidget that contains all the functionality.
This section is where the user creates the framework used to generate a rig. In the tool I provide some highly customize-able OpenGL locators, but any type of object could be used.
I spoke about components in my previous post so I’ll skip the low level details. This section of the UI is where the user assigns and edits components.
Whenever the user goes to this section a ScriptJob is created that tracks object selection. This allows me to update the UI instantly to show the components applied to the selected object. There is also a option to lock the focus (little padlock icon) so the user can select other objects without updating the UI.
Each component is a Python class. Within each of these classes is a custom tailored QT UI, and it is this UI that is displayed in the Rigging tool. Keeping the UI in the component class is critically important for keeping the whole system modular and easy to extend/edit.
A good example of the flexibility for this approach can be seen when adding a NURBS curve control component to a bit. The component UI has an edit button. Clicking it will create the curve control. Once created the user can use the standard Maya tools for manipulating the curve. Once the user is satisfied with the edits they can hit the button a second time to save everything to the component node.
The best way to think of this section is as a library of modules. A module is a hierarchy of bits with components that together create a very specific rigging element. For example, an arm or leg. From this section the user can save new modules to the existing library or load in saved module designs. The idea here is that over time more modules will be added to the library with the overall result of reducing rigging time. This section is where collaboration between teams will manifest itself.
Modules are stored in XML files.
This section is about building and saving characters. A character is a collection of modules that together generate a fully functional rig/skeleton.
Now, this section is still heavy in development. The UI you see in the image is missing most of the elements and functionality. What I do have is a drag-and-drop enable list that shows each module in a character. These modules are ordered based on an internal build priority. From this list the user can drag the modules into the order required to build the full character.
Why a build priority for modules? Well, I needed to solve the problem of module dependencies. An example of this would be a pectoral muscle module that requires the spine, shoulder, and arm modules to be built first. I could have handled all this via code and made it invisible to the user, but I felt this approach contradicted the workflow of the rigging system as a whole.
In the future this section will include tools for creating characters, editing characters, and a library of characters.
So that’s the rigging tool as of today. The component system re-write is complete and as you’ve seen the UI is nearly done. I’m really excited to finish up the system and run it through some paces. In fact, I’ve started a project specifically to test the rigging tool. It’s early days yet, but here is a sneak peak at a Dota2 courier I’m creating.