Jørn-Harald Paulsen

Archive for Rigging

Wow, rigging a book turned out to be waaay harder than what I initially tought, by far the most challenging rig I’ve done to date. The most logical approach to rigging a book would probably be some sort of procedural setup where you have one box on each side, each box textured to represent a bulk of pages, thus being able to control all of the pages on each side just by deforming these two boxes. I thought it would be cooler to have control over every single page though 😛

Rig Demo:

What made this rig challenging is that each page has to deform differently, the first page will for example have a sharp bend if turned in one direction, but in the other direction it has to gradually increase the bend-area to compensate for the width of the other pages. Even though you get the basic page turning to work, you will still have to deal with the fact that each page is different when applying any other deformation to the pages. I’m calculating the factor of each page based on where it is in the stack, this data is used as a factor for all of the deformation on each page to “normalize” them.

Another challenge is that when you have so many pages, you have figure out a way to make it animation friendly. You have to be able to control a lot of pages at the same time, but you can’t define macros for a specific set of pages as the animator may want to have pagebreaks within a specified set of pages. It’s hard to figure out a way to let the animator control all of the pages at the same time, while still having the possibility to have pagebreaks anywhere (without running into a world of cycle errors). I’m using different techniques similar to the ones in the procedural ribbon to get this to work.

As usual, everything’s done with native Maya nodes.

Note: I was searching a lot for different book rigs before starting this project, without much luck. But a user named ignasi in the comment section mentioned a tutorial by David Moore which could be worth checking out. It’s a totally different setup, but it’s really cool 🙂

Important note:
This setup isn’t really as stable as I first thought it to be, so you should probably stick with the 180 degree setup if you want to be sure not to get any problems. Cedric Bazillou first pointet out that you really can’t go beyond 180 degrees (trigonometry limit of angle between vectors) using only math, and the “hack” in my tutorial relies on maya’s cache/history in the orientConstraint-node in an attempt to resolve the angle past 180 degrees. The setup looks okay when scrubbing through the timeslider, but it won’t be able to resolve angles past 180 degrees if you jump between frames. The reason I haven’t removed this post is simply that the setup also shows how to setup a normal twist extractor, though the 360 part should be ignored. In the comment section of the video link you can read a comment made by Oyvind on how to actually trigger the problem with this setup.

The tutorial:
I forgot to mention in the video, but if you’re using translate-based stretch in your rig, you must have offset-groups on the twistextractors, which you connect the translate of your driverjoints to.

Since I put up my rigging reel I’ve received a lot of questions and requests for a tutorial on the procedural ribbons, so I’ve finally put together a tutorial on them. When I finished the tutorial I realized that it was really slow-paced, so I’ve written a script for it (attached at the bottom of this post). So for those of you that find it easier to figure out what’s going on by skimming through some code, you know what to do 🙂

This kind of technique might be old news to some people, but it’s too awesome not to be shared. These ribbons actually evaluate slightly faster than the traditional ribbon-setup, which is crazy considering they’re so much more flexible. What makes this setup powerful though, is that they utilize the nonLinear deformers in Maya, which means you inherit the same flexibility as you have with deformers, so you won’t take a performance-hit as you’re just adding functionality to an already existing deformer. This technique could of course be altered to ride ontop of FK-rigs, which could be used to rig tails/tentacles/fishes etc. When I figured out this technique I felt like it opened a door to a new way of thinking about rigging challenges.

The tutorial:

The script:
The ribbon produced by the script is almost identical to the ribbon created in the tutorial, with the exception of some cleanup in the setup and an option to offset where on the surface the twist occurs.

Wow! It’s been more than a year since my last post here… Time flies 😕 Anyway, I’ve gotten a lot of questions about the procedural ribbon from my rigging reel, and I promised I’d do a tutorial on that, I’ll try to get that done next week or so 🙂

This however, is actually the thing that got me started on the procedural ribbon in the first place. My first thought was to start with getting the sine-function to work with nodes, and then work my way from there. The ribbon turned out totally different from this tutorial though, but I thought this could still be a useful technique to share.

First off, there’s several tutorials out there on how to create a sine-function in Maya, but I’ve never seen anyone do them with nodes. The main reason you would want to do things with nodes instead of using expressions is that expressions doesn’t always evaluate when you want them to, some times you have to scrub the timeline or playback the scene to force an evaluation of the expression. That can be really cumbersome if you need to adjust attributes that affects the result of the expression without seeing the changes instantly. Also, nodes evaluate way faster than expressions 🙂

The concept:

This is very basic, and the concept is very well demonstrated here, the tutorial just shows you how it can be applied to several objects in a way that lets you control the entire chain of objects affected by the sine with one controller.

Even if you know how a sine works, there’s still something to take out of doing it this way in Maya. Instead of dealing with just the math to get this to work (which you do with expressions), you’re dealing with a more practical setup, which easily can be modified to behave however you want it to. So as long as you know the “pattern” of the mathematical function, let your rigging brain take over and do a practical setup in Maya that lets you extract the behaviour of the function.

As a rigger you have to get along with the animators, and a good startingpoint for that is to provide them with fast rigs. If the animators have to playblast for each time they want to see the actual animation, they are going to waste a lot of time!

I often find myself implementing a lot of stuff in a rig, stuff I think the animators may need. As I’m improving my rigs, I get more nodes and more calculations going on to achieve what I want – which in the end may result in performance issues with the rig when animating. I’m trying to find out if there’s some way to measure the performance of a rig-component? I find it really hard to find out which components that slows down my rig, as I have to add and animate all of the rig-components together, and then try to compare the playback-speed, remove components, re-check, etc. How do you guys approach this? Also, is there any documentation of speed differences for expressions vs nodes, extra joints vs corrective blendshapes, skinClusters vs wrapDeformers, constraints vs normal parenting, etc?

I got a lot of interesting answers in the thread, but one in particular from Josh Carey (a mentor on Rigging Dojo) helped a lot. He tipped me off on dgtimer, which does exactly what I asked for. So I’ve just wrapped this into a clean little script.

The Script
The script measures the speed by playing off the scene and evaluating each DG node’s performance, which means that for the object(s) to actually be evaluated you have to animate each component (that you want to be included in the evaluation) over a given timespan, the more frames you calculate from the more accurate the results will be.

So if you have a rig that runs too slow, you can use this script to see which node(s) that does the hardest impact on the performance. You often find that it’s just a couple of nodes that really takes onto the percentage, stuff like wrap deformers are something you want to avoid (at least in the proxy-rig) 🙂

Video Demonstration:
I’ve uploaded a video to demonstrate how it can be used, in the video I’m using it to compare normal parenting, direct connections, constraints and skinclusters.

When animating sea-creatures I found that a sine deformation was invaluable to get the dynamic flow that most of those creatures naturally had. Normally I’ve done this by using expressions, but I hate dealing with expressions when animating as you have to play the animation to evaluate and see the actual result of the expression.

So I’ve been experimenting a little on my own to see if it’s possible to achieve this with the standard nodes within Maya, and as Maya actually do have a sine deformer, I’ve been looking at ways to extract that behaviour so that it can be applied to joints.

Here’s the result:

It’s amazing what you can do with rivets, that’s what I used to extract the sine behaviour 🙂

So, I’ve finally started to look into Python 🙂 I haven’t taken the OOP functionality into use yet, I’m just starting off by getting used to the syntax before I dive into classes and stuff. On that note, I recommend checking out Zeth Willie‘s video: The basics of using Classes and OOP in Maya/Python. That was the kick in the butt that I needed to get off the fence and try something other than MEL, quite refreshing actually!

So the first version of the Cartoony Wheel Rig looked to work ok when playing around with the rig, but when doing some actual animation I wasn’t too happy with it. There’s particularly two things that I wanted to fix in the next version, the first thing is that you were totally limited to the lattice, which means that you couldn’t hit a specific shape unless the lattice allowed for it. The second issue was that you couldn’t do big things with just one controller, I would always end up having to move/rotate three or more controllers to hit each shape, which means slower workflow.

So for this version I added the possibility to actually add blendShapes to the wheel while maintining the shape when spinning the wheel, so if the rig can’t reach that specific shape you want, you can just add it yourselves. I also got rid of the motionPath-controllers, they were a bit messy and the rotations didn’t work too well. I think this rig will work a lot better than the previous, but I’ll do some test-animations with it in a while to see how well it works.

Here’s the script in action:

This version is a bit cleaner than the first version, though it’s a bit slower because of the wrap-deformer. I’ve added an option to turn on a proxy-object through main-controller so that it evaluates a bit faster.

If you have any feedback/critique I’ll be more than happy to hear about it 🙂

I started to rig this creature about a year ago, being my first attempt at mechanical rigging I quickly ran out of ideas on how to rig the legs properly, so I gave it up.

However I picked up the rig again about two months ago, starting from scratch on the entire thing, after a hard struggle I finally managed to figure out how to solve the legs (which is the key to the entire rig) and completed the rest of the rig.

When rigging vehicles you’ll usually have to deal with at least two wheels, and (especially if you’re going cartoony) you’re going to waste a lot of time if you’re rigging them manually, one by one. So I decided to write a script for this, the script is supposed to do all of the work automatically, and it should work with wheels regardless of size and position.

The requirements I set for the rig was that it had to be clean, fast and flexible. It should also be animationfriendly, so the controllers have to be logical and easy to select. With this current version of the rig I’m not too happy about the flexibility in particular, it works, but it can’t be pushed as far as I want it to. I’m going back to the drawing board.

Here’s the script in action:

The current version is basicly just a lattice with some clusters, and a nurbs-circle with all of the extra-controllers connected to the circle through MotionPath-nodes. As for the main controllers, I have a contact-controller for floor contact, two controllers for the rolling of the wheel, and one main-controller for translation/rotation/scaling.