Jørn-Harald Paulsen

Archive for Portfolio

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 🙂

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.