Tag Archive: Rig

An IK Leg and a Bug Hunt

Im not sure I can truely put into words how frustrating creating the IK leg for this rig was. I do know, however, that creating a stretchy IK leg should not take almost 48 hours to get working.

Before I duplicated my bones, I decided I wanted to put some extra bones along the lower leg to enable smoother twisting. To ensure things worked nicely later on I wanted to ensure that the three new bones I inserted were exactly a quarter, half and three-quarters of the way along the calf. To do this, I parent constrained each of the three bones to both the knee and the ankle, and made sure maintain offset was unticked. This placed all three bones exactly half way between the knee and ankle. I then changed the weighting of the parenting to two of them. Femur01 was weighted 0.75 to the knee and 0.25 to the ankle, whilst Femur03 was weighted 0.25 to the knee and 0.75 to the ankle. I then deleted the constraints and used comet tools to orient the joints correctly.

Joint Creation 11

Once this was complete I created two duplicates (one for IK, one for FK). I then created a third duplicate in which I deleted the three femur joints and reparented the ankle straight to the knee. This was so that I had just two bones in the IK system. I called it the IKGuide. I created an IK on the joints and made a simple cube controller for the foot. I parented the IK handle to this control. I then orient constrained the ankle bone to this controller so that it would not rotate as the leg moved. Finally, I created a simple circle controller and parent constrained the hip bone at the top of the IK to the circle.


With the IK built and working, I started to set up the IK stretch. Like the IK spine, I needed to know how long the leg was at any one point in time. However, I only needed the straight line distance from hip to ankle. I used the distance tool for this. I aligned one locator with the hip and one with the ankle and then parented them to the corresponding controllers. Now, as the leg moved, the distance tool would always give the distance from hip to ankle. At this point I also realised I had not created a knee controller. For this I used an arrow shape. I point constrained the arrow to both the hip and ankle (with maintain offset unticked). This placed the arrow on the plane between the two, directly in the centre. I then used an aim constraint to ensure the arrow was pointing directly at the knee. After deleting both constraints I moved the arrow in front of the knee and set up a pole vector constraint on the IK.


To wire up the stretchy leg I used another multiply divide node and, like the spine, the distance was wired to the first input. The second input needed to be the length of the thigh bone plus the length of the calf bone. As the joints had been oriented correctly this could be found simply by adding the x transform of the knee and ankle together. I changed the node to divide and wired the output to the “true” output of a condition node. The “false” output was left as 1. The condition node also had the distance in the first input and the length of the two bones as the second. It then compared the two lengths, and if the distance was greater than the bone length, the condition was true. I then wired this condition node to the x scale (length) of the thigh and calf. The two bones of the IK scaled nicely. Unfortunately, the ankle and foot bones were being scaled strangely when the leg stretched, despite not being wired to the condition node. I even checked the scale of both and x, y and z were all still showing as 1. This meant the bones shouldnt have been scaling at all.

FootScaleBug FootScaleBug02

I tried deleting the IK and remaking it, but the problem persisted. I then tried moving the controls with no IK present at all, and the ankle and foot continued stretching strangely. I could only assume there was something strange with the bones, so I deleted the IKGuide joints and re-created them. I set everything back up, re-wired the thigh and calf x-scale to the condition node and tested it again. I had exactly the same problem all over again. I tried re-creating the bones once more that evening but with no success. I finally decided the only option was to go to bed and look at it with a fresh mind in the morning.

As is often the way with re-visiting a problem the next day, I tracked the issue down quite quickly. I had all the joints in the hypershade to make sure my ankle and foot definitely hadnt managed to end up wired to anything and I realised there was no line showing the parenting of ankle to knee. I un-parented the ankle bone and re-parented it to the knee and the problem disappeared. I was delighted, until I found yet another problem. Whilst the ankle was no longer scaling strangely, it still was not doing what I expected when I moved the hip too far away. Despite being orient constrained the foot controller (and as such theoretically unable to rotate by itself) when I moved the hip controller forwards or backwards so that the leg stretched, my ankle would rotate.

FootBugRotate FootBugRotate02

I decided to fix the problem by simply creating a new version of the ankle and foot bone. I simply point constrained the new ankle joint to the one on the IK leg and orient constrained it to the controller again. Success! Problem solved, just not as tidily as I would have liked. It also left me feeling frustrated because I wanted to know why the problem had occured so I could avoid it in the future. Still, at least the problem was gone and I could get on with parent constraining the IK joints to the IKGuide joints. I unticked maintain offset and parent constrained all the joints to their respective guide joints. I parented the three femur joints in the same way I created them; by parenting to both knee and ankle and then editting the weights. However, what I hadn’t thought of was that a parent constraint would cause the joints to rotate out of alignment due to the ankle’s orientation. I pondered the problem for a while and decided I would simply ensure to maintain offsets when constraining the deform joints to the IK joints.


I then set to work creating a control system for the toes so that I could create a simple set of foot roll controllers. Initially I decided to place a circle controller around each joint of the toes, but it quickly became clear that some of them would be hard to select.



Instead, I moved the curve shapes of the controllers above each toe joint and this made them much clearer and easier to see. Finally, I also made a main controller that would be used to curl all the joints of a toe. I then began creating a simple set of foot roll controls and with some re-parenting of the IK handle my IK leg was complete.

Foot02 Foot03

Unfortunately, I quickly checked things in my orthographic side view and realised that at some point during the creation process I had managed to cause the entire IK system to move out of alignment from its starting position, despite all the controls being at 0, 0, 0.


The only option was to yet again build the entire IK leg. I deleted all my bones, mirrored the right hand leg to the left hand side. The good thing was, that at least this time all the controllers were already built so all I needed to do was wire everything up correctly, and make sure my controllers were correctly aligned before constraining/parenting things to them. Fortunately, this time I got it right and my left IK leg was finally complete. Hooray!

The IK Spine

I finally got the mesh back yesterday, and Im happy to say its actually symmetrical this time.


As such, I’ve been able to get cracking with building the control system for the toony rig. I started with the spine as I feel its such a central part of the control system, and almost everything else is parented to it in some way. My first step was to duplicate the bones that I want to apply the IK spine to. This means if I made any mistakes, moved anything by accident, I wouldn’t ruin the position/orientation etc. of the deform skeleton and I could easily delete the duplicate and start again. I tend to insert IK (or whatever is appropriate) to the name of the joint to differentiate it from the deform skeleton.

Once I’ve got my duplicate I hid the deform skeleton so that I couldn’t affect it or move it whilst working on the controls. I applied an IK spline with two spans to the spine. This means that there are control points for each end, as well as a single control point in the center to affect the curve. I created a cluster for each of the control points. These control the shape of the curve and the shape of the curve drives the position of the bones.


I then needed to build the actual controllers for the spine. Comet tools provides a quick way to make a bunch of spline shapes, but they are all quite simple, sharp edged splines. They never look particularly nice, and they don’t fit the shape of the body all that well. As such, I like to make a lot of my controllers by hand. To do this, I used the mesh itself to guide the shapes. I turned on snap to vertex and created a selection of curves that flowed around the area of the body that I wanted to control. I generally tweak them slightly afterwards to make sure the ends of the curves meet up and dont leave gaps anywhere. With this complete, I had a bunch of individual curves that could be selected seperately. What I actually want is to be able to click anywhere on any of the curves and to have them all selected. To do this, I had to reparent the individual “curveshapes” to a single curve. This can be easily done by selecting the “curveshape”, then shift selecting the curve I want to parent it to. I then simply use a single line of MEL script: “parent -r -s”. This leaves an empty curve node with no shape that can be deleted.

IKSpine02 IKSpine03

Once all my controllers were built I aligned them with the correct bones and parented the clusters to each controller. I also created two groups for each controller to be parented within. One I suffix with _SDK and one with _0. The _0 is my null group. The 0 point so that I do not need to use freeze transformations. The _SDK group allows me to set up parent constraints for a controller, whilst still giving the animator the ability to animate it. For the spine, I parent constrained the middle controller _SDK to both the top and bottom spine controllers. This means that the middle controller will always remain halfway between the top and bottom of the spine.

Once this was complete I decided to test the spine to check it was working correctly. Unfortunately, it wasn’t. I hadn’t realised I had only given the IK spline four bones to move around. When the curve had extreme bends the bones just averaged out their positions and the shape of the curve was lost. This meant rebuilding the deform spine with more bones so that there were enough joints to follow the spline curve more accurately. Having added them, I made sure to tidy up their orientation with comet tools again.

IKSpine04 IKSpine05

I then repeated the process of applying an IK spline to the duplicate set of bones and creating clusters for the three control points of the curve. I re-positioned the controllers to ensure they were correctly aligned with the new bones and then parented the clusters to the controls. I also set the twist controls for the IK spline to make the hip and chest controllers control

the spine rotation.



Finally, I wanted my spine to be stretchy as this is meant to be a “cartoony” rig. I created a multiplydivide node which I set to divide. I also created an arc length info node for the spline curve. This provided me with the length of the curve at any time. I wired the length into the first input of the divide node and put the length of the curve when all controls were at 0, 0, 0 into the second input of the divide. This means that the output will be the current length of the spine divided by the original length. I then simply wired the output into the scale x (the length)  of all the joints in the spine.


Success! An easy to use stretchy IK spine.



The Deform Skeleton

With my scenes set up for my animators on the elephant project, I can finally get to work on my side project; the toony rig. The first step to rigging anything is to build the joints that will drive the deformation of the mesh. I call this the deform skeleton.

The first thing I create is always the spine. The pelvis is the start of the chain and the head the end. I generally name joints as I go to avoid confusion when the entire skeleton has been built. I used the same naming convention as my elephant rig. A prefix of C_, L_ or R_, the name of the joint and a suffix of _jnt.

Joint Creation 01 Joint Creation 02

The arm was the next thing I built. I initially place the bones using the orthographic front view. I line up the joint positions to the hand as well as possible. However, because my view is orthographic, the joints are all created on a flat plane. This does not match the shape of the hand, so I then use the perspective view to line everything up correctly. I then repeat the process with the foot, but this time I create the joints from the orthographic side view. To ensure my joints orient correctly later on, I make sure that the first finger or toe I create is the most central one. This simply means that the joint in the palm or sole of the foot will point to this finger when oriented, instead of out to one side at, for example, the thumb or little toe.

Joint Creation 03 Joint Creation 04 Joint Creation 05


With all the joints created on one side of the body, I now need to correctly orient the joints. This is good practice because it ensures the joints will all rotate nicely in the same axis. These two images show the spine axes before and after the orientation. I use comet tools to do the joint orientation.



Joint Creation 06 Joint Creation 07 Comet Tools

After orienting the joints on the hands and foot, I tweaked the angles of the thumb. The reason for this is so that if all the finger joints are selected and rotated in one axis, they should close to form a fist. This makes it much easier for the animator to work and keeps the animation curves much cleaner.

Joint Creation 08 Joint Creation 09 Joint Creation 10

With the orientations tidied I could finally mirror my arms and legs so that I had a complete skeleton. Unfortunately, once I had mirrored the joints, it was clear that the mesh had not been mirrored correctly and was not symmetrical. I have contacted the artist and asked if they can have a look and fix it. However, since it is the easter holidays, I have no idea when they will see my email, let alone send me the fixed mesh. I dont want to continue rigging, just in case there is a problem and they are unable to get things symmetrical for me, as that would mean rebuilding the joints for the right arm/leg seperately and I would have to redo any work I had already done.

Not quite symmetrical

The Basic Rig

The basic rig is now complete, which means I can now create the deform test and actually skin the low poly mesh to check how everything deforms.

Deform Skeleton

It was such a relief to finally be doing something that felt constructive. My first step was to build the deform skeleton. This is the set of bones that the mesh will be skinned to. It is important to get the bones placed correctly so that joints bend in the right place and the deformations of the mesh are as natural as possible. With the skeleton built, I used comet tools to help get all the bones aligned correctly. This ensures that the axes of rotation are where I want them to be, and therefore the rig will be easier/neater to use.

At this point I also made sure all my bones were named correctly. Every joint name starts with either C_, L_ or R_. This denotes whether the bone is down the centre of the body (C_), on the left hand side (L_) or on the right hand side (R_). This is then followed by the name of the bone, and possibly a number (ie spine01 or trunk03). Finally, every joint ends with _jnt. A good naming convention is essential when rigging as it makes things much easier to find with a search tool etc.

IK Spline Spine

Once everything was named correctly I set to work creating a control system for the spine. I used an IK spline set up. To avoid causing problems and having to rebuild the deform skeleton, I duplicated the spine and placed the IK on the duplicate. I could then parent constrain each individual IK bone to its equivalent on the deform skeleton. This causes the deform skeleton spine to do whatever my IK spine does. I chose to create an IK spline with just two spans. This means the spline has three control points: one at either end and one in the centre. I turned these into three clusters which I could then parent to various controls.


I created a simple cube control for the hips and shoulders of the elephant which I deformed slightly so that they fit the contours of the elephant slightly better. I then parent constrained the corresponding clusters to these controls. I used a simple circle for the middle of the spine and again parent constrained the centre cluster to this control. This provided a way to control the spline curve and so control the bones. However, if a control was moved too far away and the spline curve became too long, the bones did not stretch and so only covered part of the curve.

This was an undesirable result, so I set up a fairly simple wiring system in the hypershade. I created a node for the spline curve with a single attribute: the arclength of the curve. This value changed whenever the curve changed, meaning I could always know how long the curve was. Using this changing value, and the curve’s original length, I set up a divide node that would calculate the current length divided by the original length. Then I used a condition node that was connected to the x-scale (length) of all the bones in the spine. If the curve was the same length or shorter then the scale of the bones remained at 1. However if the length of the curve was ever longer than its original length, the scale (length) of the bones was changed from 1 to whatever the divide node calculated. This meant if the controls were ever moved too far apart, the bones would scale and still fill the entire curve.


However, I discovered that while this worked really well when the curve was long, it didn’t work very well if the curve got too short. Some of the bones started flipping to try and remain within the length of the curve. As such I decided to completely remove the condition node and simply wired the divide node straight into the x-scale of the bones. The spine now stretches and contracts brilliantly.

IK leg

The next step was to create an IK leg set up so that the legs could be easily animated. I debated for a while which two bones to put the IK on before deciding it definitely needed to be shoulder->wrist/hip->ankle. Like the spine, I duplicated the deform bones and applied the IK to the duplicates. I created a foot controller which was, again, a slightly deformed cube. I parented the IK target to this controller and orient constrained the ankle joint. This meant that I could move the controller and the leg would bend, but the foot would remain in whatever orientation the controller was in. Finally I added a controller to move the top of the leg around. I then repeated this for all four legs.


The rest of the body I decided to keep simple for this basic rig and I used simple FK set ups in the neck, head, trunk, ears and tail. With all the controls complete I decided to try and make the rig clearer to use. I started colour coding my controls; green for left, red for right, cyan for anything down the centre. I also made a centre of gravity controller which could move both the hips and shoulders at the same time, in case the animators wanted some FK control from the hips. This I coloured yellow to make it stand out.


However I decided that the cyan was too close in colour to the “selected” colouring that Maya uses. As such I changed things again:


Rigging at last!

I finally received a low poly model from Paul that I could start rigging. At this point, what I really want to check is how the mesh deforms, especially around the legs. As such I plan to build a deform skeleton with some simple controls that will allow me to create a quick deform test so that I can skin the mesh.

The low poly model is looking pretty good, and its definitely nearly complete.

06  07

I have however warned him that we will likely need to change where the mouth meets the head, as currently it is quite square. Left like this, the corners of the mouth won’t close properly. As such, I’ve asked that he try to turn that square flat edge into a sharper corner.

2nd Year Showreel

And finally, its all over. Im just collating all my files together ready to hand in. Can’t believe how fast the time shot by. Also can’t believe its almost time to be a 3rd year. Crazy!!

Anyway, here is the final showreel of my 2nd year work. Unlike the longer coursereel, this does not have the entirety of my work on it. This simply has the best of what I’ve done during this major project. Plus it has music. Woooo.

Spine Fix

Finally managed to locate the cause of the issues with the spine when the dragon was rotated to face in a different direction. The base bone in the spine was flipping by 90 degrees whilst the others remained fine. It was due to creating the spine as an IK spline set up and wiring the rotation handles to controllers. Although this set up works fine in an upright spine, it appears to cause the handles to rotate strangely when the spine is horizontal. I have deleted the IK and re-linked the bones together and wired the controllers back to the correct things. Hooray for a working spine.


I also realised that my centre of gravity controllers were not set up correctly. As I had placed them above the dragon, I was causing the dragon to rotate around the pivot of the controllers and not the pivot of the dragons hips. Some extra point helpers and a few extra position and orientation constraints have fixed this. Also hooray!

A slight change of plan…

So it would appear a pair of 3rd year VFX students had their own project idea that involved compositing creature animation into live footage. They actually were aiming for a bit of a “His Dark Materials/Golden Compass” type theme but this still fits well with my original plan to try and composite some of my animation into the streets of Cardiff. However it appears they don’t have quite the numbers of animators/artists (so far at least) required to hit the scale of film they had been planning – which is a shame because it would have been awesome if this had turned out to be the big project of the year. Ho hum. Anyway, it looks like it may just be one 2nd year artists and myself doing the CG side of the work which rather limits the number of creatures they can have. In fact, Paul and I have agreed that we can only manage two creatures. While Paul handles the modelling and texturing, I will be rigging/skinning both models and then creating a walk and run cycle for both as well as a single non-cyclic animation (ie standing up from sitting or something similar). So, that covers 6 of my 12 weeks on the major project.

For the other 6 weeks I will be working alongside Elaine and a few others to help produce a short animation we have currently nicknamed “Project: Dragon”. It involves a rather silly chase between a hapless knight and an overly playful dragon. I’ve set myself the rather terrifying project of both modelling and rigging the dragon (eeep!). However, we have an artist who loves to draw who will be doing all the horrible design work of the characters. As such, he will hand me completed turn arounds so I dont have to do any of that nasty stuff involving pencil and paper. Or at least… not in designing the look of the dragon. I still need to work out the rig structure. The modelling of the dragon (and first attempt at rigging) will actually occur during our final advanced tech project. Three weeks to model, texture and rig (a week for each). I will then probably pass the model to Ruth who may tidy up any poor edge loops to aid with skinning the final rig. Jess will also completely re-do my textures. Once that is all complete, I will build a completely new rig, get the model all neatly skinned and set to work creating clever controllers so our animators can have a great (and easy) time of animating him. So that takes up another 3 weeks of major project time. The final 3 weeks will be devoted to doing some animation with the knight in the project – a run cycle, possibly a walk or jog and then some sort of non-cyclic animation.

Scarily, we are almost three weeks through our pre-production, and currently I feel as though all I really have is research. Will have to slave away at it all after Christmas.

Major Project Time!

Well, its Major Project time already. How has this university year managed to rush by so quickly?! Can’t believe the first term is almost over. Anyway, major project time means major decision time. We basically need to do four three week projects, two of which are collaborative and two of which are personal. However, there is a huge amount of leeway with what we do and what counts as collaborative or personal. While collaborative does of course require working alongside other people, the personal portion could be a specific section of a collaborative project that only I worked on.

Having discussed with tutors, we have also agreed that I can spend half my time creating rigs, and half my time animating. My main focus is currently leaning towards VFX and specifically creature animation. As such the main thing I currently want to do is find an artist who will create me a realistic elephant model that I can build a rig for and then animate. If possible I will try to find some VFX individuals that might help me composite the animation in to a real video.

So I’ve just spent the afternoon researching the skeletons of african elephants and watching various videos on the BBC motion gallery (which by the way is one of the most awesome resources for animal reference footage).

We have a pitching session middle of next week which hopefully will help me find a partner modeller as well as decide what the other half of my major project will be. In the mean time, more planning and research is required!

Advanced Tech

Soooo… the trouble with a busy, manic course is that there is no time around the work to actually keep this blog up to date. Looks like I may have to try and set myself a time once a week to sit down and make blog posts. However, since I have found an oppurtunity today, I shall take full advantage of it.

The rest of the first two advanced tech course works involved modelling a realistic hand in one week and then rigging, skinning and texturing it the next week. To practice skinning techniques we also had to rig and skin our bug in another 24 hour session. Needless to say, it was a pretty intense couple of weeks. Still, the modelling side of things turned out pretty well. I struggled at first while trying to get my head around the idea of “edge loops”. This basically means keeping the flow of the edges around polys moving nicely around the model and trying to ensure there are as few as possible, so that they actually just loop around and connect in various places.

Skinning and rigging the wasp turned out to be a real struggle due to a few mistakes made during my modelling process. As I had modelled the legs quite bent, it was impossible to make them straighten nicely with the rig. Also, thanks to a lack of edges around the leg joints the bends were very untidy.

Having completed the wasp, we moved on to rigging and skinning the hand. This went very well and I had it mostly completed on Friday before stumbling across an error. One of my tutors helped me to find a work around for the problem and a way to reload all my work on to the rig after the fix. This worked great on the Friday. However, I came in on Monday expecting only a small amount of skinning left to do only to find that the fix I had been shown on Friday had now deleted all my work and I had to start again from scratch. Unsurprisingly I was absolutely gutted and this seriously affected the quality of my skinning. There were several errors I failed to notice in my rush to get everything complete and I watch my deformvideo now with frustration that the deforms are so much poorer than my first attempt.

We also then had to texture the hands. Rather than using photoshop, we used procedural texturing, using various noise algorithms to create the random colour changes etc that you see on skin.

Finally, once the hand was rigged we also needed to pick a final pose and animate the hand moving into this pose.