Operator precedence

Taken from cgSultra, useful page I found detailing key fundamental concepts of MEL scripting. the image below gives clear representation to the order of precedene an operator takes:


The following shows order of operator precedence in MEL. Operator in same row has equal precedence. Left most operator is evaluated first, if a statement has more then one operators of equal precedence.



How to draw all kinds of crap

Character Sheet

Post of Bodyshapes, faces, poses I like

Image created by Szymon Biernacki, as part of a competition brief set by computer arts. Blog address: lordbiernac.blogspot.com

Yellow

dir. Neill Blomkamp

Short directed by District 9's Neil Blomkamp. Originally a competition brief set by Addidas (the theme being about emotional response to different colours). It has a really slick cinematic quality and seamlessly integrated cg effects.

Creature WIP

Couple of screengrabs from the Creature Character I've been developing. Started to apply a bit of muscular definition, but don't want to go over board. Need to re-evaluate the appearance of the arms and hands - look a bit human like at the moment, and a bit slender. I will start loooking at Gorilla anatomy as reference - this will certailny inform exactly how the character will stand at rest pose, although may look a bit odd with such a slender torso. I might duplicate this model and fatten him up a bit once his arms have been adjusted...  

Animal Anatomy Reference

Canine/ Human

Horse/ Human

Bird/ Human

Human Anatomy Reference

Back

Torso

Leg

How Birds Fly

Wing Flaps

Despite being a different species, this slow-mo video is still a good resource. The diagram at the start shows the various wing poses during a flap cycle - quite a good place to begin the research, so I begin to get an idea of the sort of shapes the rig will have to manouvre into for the animator.

Early misconceptions include the range of motion from the shoulder joints on the downward stroke - if straight out is 0°, then the wing only rotates around the 30°'s mark; the rest of the motion is derived from forward rotation and the wings elbow joint bending inwards. 



More imagery of the take-off poses for the bird - bit unclear at the moment if the elbow joint is a ball joint or a hinge like a human elbow. When I look at some reference it appears to be a hinge and others a ball.

Mel Requirements

Part of the USB mans rig requirement was to contain a mask visor that has a dot matrix display (very similar to the Daft Punk mask). This is relatively simple to set-up using a glow attribute, but I want it to scroll from right to left/left to right up and down etc. I would also like to be able to alter the speed at which it scrolls.

To do this i'll have to create a MEL GUI window with some sort of means for selecting the direction and an input box that allows the animator to control its rate by inputting a number.

Early thoughts are, in order to scroll from left to right the script will have to get the visibility attribute (on or off) for the dot immediately to its left, store that in a variable and then set that attribute on the visibility on the adjacent dot on a specified number of frames later. To scroll down the visibility information will come from above, to scroll up, the visibility will come from below and to scroll left from the right. 

Showreel 2010

Quick montage of a couple of the characters I developed for my FMP. The sound doesn't seem to have survived the compression.

usb turn table

turn table of finished geometry.

Evaluation

My Final Major initially begun as a collaborative project between myself and an illustrator, to design, model and rig characters ready for animation. At the early stages of development it became apparent that to stand a better chance of success, some sort of story treatment would assist in generating ideas for the characters. I decided to focus around an old Hoover vacuum cleaner I had in my cellar and developed a story around it to try and focus the design process and generate character ideas.






Midway into the brief, the collaboration dissolved, and the task of designing the characters still remained. I hold no single person responsible; but would rather identify a number of contributing factors. The first key factor was our areas of study. Dean, my collaborative came from a very graphic background, and despite having a keen interest in character illustration, his experience had not entirely prepared him for the consideration of motion and animation which is paramount to developing for moving image. Dean’s creative background would probably suit more 2-dimentional still environments – logo illustrations and web graphics.






With the benefit of hindsight, I should have fully vetted Dean’s previous drawings and examined them fully before committing myself into a working partnership; at that point I was more taken with his enthusiasm for the project. In terms of workload, we both had very different schedules. My weighting was structured around this project, my PPD module and my dissertation. Dean’s workload was more spread out with an emphasis on proliferation, so he could not allocate the level of time necessary to solve this brief successfully. We both attempted to arrange meetings between ourselves and course tutors to arrange an appropriate work schedule, but despite several attempts unfortunately didn’t occur.






I will take heed of this valuable lesson in the future and always vet possible collaborators for ability and motivation as well as their personality commitment and availability. On some occasions Dean and I communicated through the blog, but this was a rather cumbersome at times and didn’t initiate the stream of ideas I was hoping for.






I decided in order to produce my characters to collaborate with fellow students on my course. The first was Dave Warren’s “Toxic Boy”; a character he had designed and modelled for a short animation that required rigging. We went through his story boards and agreed upon the best rigging solution for his animation.






Toxic Boy is a bipedal character, and I soon found a volume of resources online and in print on how to rig a biped. The most comprehensive is that of Jason Schliefer, whose features titled “Animator Friendly Rigging” walk you through the rigging pipeline. The advantage this set of tutorials has over others I’ve previously seen is that he introduces the student to the process of evaluation that should be engrained in every Character TD’s workflow. His video analysis of real life motion focuses the attention on the task in hand, and helps determine exactly what needs to be achieved, and what factors affect key decisions in the process, something I have rarely witnessed in other tutorials.






I rigged Toxic Boy in accordance with Jason’s tutorial, but also added and omitted some of the features to tailor it to Dave’s requirements. For instance Jason’s arm involved a quaternion setup involving a number of joints on a spline to achieve better distribution on the twist. Because Toxic boy’s arms were covered in NCloth, you would not notice any pinching (or “candy wrapping”). For the one shot, which required the arms to be seen, I created a separate arm rig that was controlled in FK, with a forearm joint so Dave could distribute the twist down three joints.






The mesh itself was quite difficult to work with, which alerted my attention to the importance of good edge flow. I lost a lot of time weight painting the deformations once the character was skinned, which could have been avoided if there was more geometry in key areas; the shoulder areas were the main culprits here.






The skinning stage has previously been a make or break moment for me. I have since learnt to constantly test partial setups on the mesh by doing quick tests. A single joint for instance can lock down the geometry you wish to remain static whilst you test the area in question, a far quicker approach that rigging the whole thing, skinning it and realising there are issues with deformation. Once the character is skinned, there is little you can do to adjust the rig without detaching it., its far easier to test on a duplicate and transfer it over once satisfied (another shortfall of most video tutorials).






I devised the Crane rig through evaluating different video sources and photographs I had compiled, and ensured my knowledge of the task in hand was sound before I laid a joint. The immediate cause of concern was the wing setup; which at surface value appears simple enough, but its actual mechanics were deceptively complicated. Without the reference material, it would have been impossible to fathom the correct motion procedures and translate this into a working rig. This rig really made me realise the importance of observation and having a good understanding of how objects move in relation to each other (which is created in Maya through parenting, constraints, expressions etc). This is the key principle to good rigging – the hierarchy and how it affects the objects within. Continuing with the deconstruction reveals rigging is about transferring a series of numbers or values from one attribute to another.






Whilst developing the Crane, I was constantly building, skinning and testing possible solutions, then detaching and rebuilding on the final geometry. Jason Schliefer’s advice is as follows “experiment, build it, test it; if it works great! Now delete it and build it again, but make it cleaner without any residual nodes”. Sound advice which not only assisted the rig development, but also relieved the burden of weight painting.






For the USB character I wanted to implement a “ribbon spine”, which I first saw demonstrated by Dream Works Aaron Holly. The Ribbon spine has its advantages over a spline IK, the most notable is it doesn’t involve scaling the joints to simulate the stretch, rather relies on the interpolation of a Nurbs curve. This makes the setup incredibly robust, and avoids any popping that can occur directly above the top and bottom joints of the spline IK.






The Hoover rig also implements the “ribbon spine” to control the bag deformation a. I also used an expression on each of the wheels to create a rotational motion which responds accordingly to the forward and backward motion of the Hoover.






For this brief there was an element of modelling involved, and while I had already become well acquainted with polygon modelling techniques, Nurbs modelling remained a complete mystery. A portion of this brief was dedicated to exploring this workflow, and whilst concluding Nurbs modelling has it’s limitations, and can be extremely frustrating to work with, the interpolation and control achieved through spline and patch modelling surpasses that of its more robust cousin. The key area of understanding is the conversion techniques and settings. When modelling the USB Man, I was able to create a mesh ready for smoothing. When the smooth node was applied the resolution was unnecessarily high in area it didn’t need to be. The benefits of Nurbs to Polygon conversion allows the modeller the opportunity to convert the mesh patch by patch and evaluate the smoothness on the fly. If it isn’t smooth enough, they can retrace their steps and adjust the conversion settings accordingly. This is definitely a workflow I would recommend to any modeller.






As part of my PPD module I have been looking at job vacancies available for a Character Rigger/TD. They all without exception sought a candidate who was adept in MEL scripting and C++ language. This is certainly an area I will be focussing on in the near future, and I fully intend to familiarise myself with MEL’s syntax and develop work pipelines and GUI’s for my rigs.






I shall also continue to build characters and rigs, and hopefully their quality will improve with each one. The key missing ingredient is animation, which is symbiotically linked with the rigging, modelling and design process an underdeveloped knowledge of this will only hinder my development as a rigger. I feel I have gained a lot from this module, and developed the confidence to put the text books and video tutorials down and start using real life as my reference. From this point on I find the process of rigging less daunting and a lot more fun!

Hoover TurnTable

I've been thinking about setting up the turntable shots of the model and getting the best out of them. For this one I used a three point lighting system and put a surface in to cast shadows. This was done using the TurnTable function in Maya, but I start to set it up using motion paths and camera's with aim constraints, that way i can have a bit more control over the shot.

Hoover MEL

Strictly speaking an expression is not classed as MEL, but here goes any way.

I used the following expression to drive the wheel rotation:

float $dist = MainAnimCtrl.translateZ;
float $rad = 0.253;
float $Pi = 3.14159;
wheel.rotateX = ((180 * $dist) / ($radius * $pi));

I had to do a bit of digging around the old maths books to figure this out, but pretty straight forward. First are the three float variables declared - the distance in Z the main controller is travelling, the radius of the wheel (this doesn't have to be a variable, but for the purpose of this demonstration i'll point it out) and the value of pi to five decimal places.

The maths equation then perform the mathmatical magic and calculates the rotate X value of the wheel.

Hoover Rig

Video of the final rig. As I've stated earlier, the bag was rigged using a ribbon spine. This is a really nice way of doing it, in future i will create a means of utilising both the ribbon and an FK joint chain in the spine, whilst putting some sort of volume control on the joints.

The rest of the geometry is connected via parenting, and there's an expression driving the wheel rotation (details of the expression are included in the MEL section for this character.

Hoover Reference

Images of the Hoover I took, quite a simple object to model, which I'll approach separately and parent together at the rigging stages. 

Finished Geometry

This is the final model I will be rigging. At this point in time i'd like to add some sort of control to the bag that will allow it to translate around and squash and stretch. I already used a Spline IK in the Toxic Boy Rig, which had its issues with the stretch. Because the joints had a multiply on the scale X, the top joint expanded with the rest causing uncontrollable bulges around the base of the neck.

The ribbon spine doesn't have this issue, because it uses the uv position of the joints in relation to a nurbs patch to interpolate its position so there is no multiplication on the scale. This makes it a really nice robust setup, and as long as there are holding joints above and beneath, it will deform nicely.

The other challenge i have with this rig is to ensure the wheels rotate as the hoover translates. I'll be using an expression to drive this.

Side View

Rig Testing

Completed building the rig and skinned it to the geometry. Started pulling controls about to get an idea of the weight painting task, and discovered a major issue with the spline neck. Whenever I move any of the controllers, the neck seems to pinch-in on itself as above.

I've had a bit of a play in a new file to try and figure out the problem, after a bit of investigating it seems apparent i've oriented some of the joints the opposite direction in Y. I recall doing it, and thought at the time it was the right thing to do.

I've tried removing the spline IK, and re-orienting it, to try minimise the amount of work i'll have to do, but that hasn't worked - I keep getting that "Warning - skipped joint" in blue. Looked this up on the internet, as far as I can gather, its because of the IK. Having detached the IK and spline, it still wont orient properly, so I think I may have to bite the bullet and re-do it.

Oh well, could do with the practice!

Neck Setup

Brief description of the neck setup:

Down the neck theres two joint chains, an FK and IK setup. The IK has a spline Ik running through it, and the arrowed pointers have a joint each parented below them which are skinned to the IK spline (could have used clusters but opted for this method instead.

The FK chain will be responsible for posing the head and has the FK controllers parented under the end joints. This way the FK can control the fine tweaking. 

Going back to the reference video, I wanted the head and the body to have independant movement (ie to be able to move the head and the body stay still and vice versa). This will be determined by two seperate controllers, the first will be on the root bone. This will control the birds torso position whilst planting the feet (bringing the leg IK into play). I will then create a locator control that will be positioned at the head controllers origin. Previously I did a little tester involving an arm orient - where the animator had the ability to rotate the torso, and decide how the arm should follow (whether it rotated with the torso or held its rotational position) through orient constraints and weighting.

 My head planter will be parent constrained to both the root controller and the head controller. When the control is set to head, the animator will be able to move the root around and the head will remain planted - there's no stretch on the neck, so hyper-extension (moving up and down) will eventually cause the head to move. This is unavoidable, but the footage I have shows the body tends to move side to side; if this is the case the curve length will not extend and the head will stay rooted.

Here's the neck/head setup complete, and showing the attributes for the hip controller. As you can see from the channel box, i've added an enum attribute labelled "head" and "body". Primarily, the animator will want to work in "body" mode so the head follows the body, but there will be occasions where they will wish to switch over to head and give it that sort of body wobble motion. The outliner shows the parent constraint, wired between the head locator and the end FK joint. the head locator will be parented under the main animation control so it moves with the rest of the rig. Visibility will be switched off - you don't need to see it!

Foot Setup

Foot setup is now complete, so here's a quick rundown describing exactly whats happening.
Each toe has an fk joint chain running down it (I could have opted for an IK spline chain, driven by fk but decided this was a little overkill - There's no particular closeup of the feet in any shot). Getting the feet into the right pose is quite important, watching the video's I've noted the positions and shapes they achieve whilst walking and flying.

Each joint is connected at the ankle by three separate joints; which are not for skinning, but will allow toes to rotate downwards independantly. I've set up a "relax" attribute on the foot controller that will control this. I'll create a seperate ankle control for skinning which will have the ik handle attached.

Each joint has a nurbs control curve attached to its shape node using the parent -add -shape command. Took me quite a while to figure out that the shape has to be at the origin, with all its transforms frozen out, history deleted. Otherwise it maintains offset from the origin. We don't want that. This is a really nice processor friendly, Outliner tidy way of doing things (rather than using parent constraints). 

Set driven keys can now be applied simply to pose the feet into walking and flying positions, and speed up the animation process.

Wing Reference

Very useful resource on the workings of a bird-wing. Must note, this video refers to smaller birds, a crane has slightly different physiology to this, but none the less a useful starting point. This has helped me no end decypher whats occuring when the wings tuck under and fold around the top of the body when the bird is grounded.

Looking at the skeleton below and comparing that with the video animation it seems the Crane doesn't have the Humerous bone, just one big Ulna bone. The rest works pretty much the same - the bird wing and human arm are quite similar, they just bend in opposite directions. So i can act out the motion myself and then reverse it; which I did (see below)...

Me Being Bird


Hopefully not the best short film i'll ever make, but just to illustrate the backward nature of a birds wing movement. Once the arms are folded back on each other, they tuck over the back.

Crane - Side View

Side view of finished geo for the crane character. Lots of consideration already going into the neck. Comparing it to a more humanistic bipedal rig - it shares some characteristics; however the neck will need to be treated like the spine, the body i want to keep pretty rigid i the x axis, might break it up with one join in the midde just so it has a little flex for when the wings fold back into walking position, but might not be necessary.

The bird skeleton seems to suggest the whole body is one fused unit - come to think of it, i've eaten  my fair share of chicken off the bone - we've all picked around that huge lump of cartiladge that ends up in the bin - It has no play in it. Just the same here, except a bit longer.

I've also included the outliner and channel box in the snapshot, just to demonstrate the geometry is fully reduced to one piece, named up, grouped accordingley, has its transformations frozen and history deleted. Ready for rigging. 

Joint Placement - Side

One of the most important parts of the rigging process and sadly not well documented in video tutorials. This rig will have plenty of joints down the neck for the bird to move and shake and connected by spline ik that will be driven by fk joint chain. I'm not going to include any stretch or squash - this character is supposedly made from paper, paper doesn't stretch. 

Legs are pretty straight forward, only they bend in the opposite direction to ours, so i'll bear that in mind. I.m also going to add a couple of joints down the talons, so the bird can clutch, but for now I think this will suffice - might go back into it later and tart it up.

The front of the neck is quite a large area to control with the neck chain and will pose problems when weight painting, so what i'm considering is adding some sort of rib joints, with an expression connecting them to their neck parents that staggers their rotation a little - might hold its geometry a bit better this way? This will certainly make the weight painting a lot easier (one thing i've learnt from the toxic boy rig).  

Joint Placement - Front

Front view of the bird, looking at it again, I think the top leg joints need positioning slightly further down where the begin to bulge out. I've tried to show the rig sections that will hold the geometry towards the front of the neck. Wing sections will have two major bones that bisect the geometry and allow them to fold. The top view will illustrate this better.

Joint Placement - Top

I've begun with the wings - they're going to be the most difficult to work correctly. Thinking about typical wing behaviour, and what springs to mind is the way they fold back on themselves and tuck on top of the upper body and an actual wingflap. To save a boatload of time for the animator, I'm going to set up these motions via set driven keys, then they can just use the slider in the channel box rather than animating it every time.

Looking at the above image, i've had to slightly adjust the geometry on the wing, by shortening the second half so when it rotates and conceals itself under the first section it doesn't poke out at the end. I've also lengthened the first section so it will cover enough distance down the back. Looking at Crane reference material, this is quite some way.

I originally (and incorrectly) thought both sections of the wing rotated in the Y axis in the same direction. This is incorrect; the arrows point out the correct direction. In order to set this up using joints I used a chain which involved a three way setup. A chain that travels down the length of the wing and the offshoots that will point the feathers in the right direction.

I've tried to pose the wing in a folded position, but it turned out impossible to correctly position both the feathers and arm independantly as they share the same axis.

My proposed solution is to group each feather chain individually, then parent the group down the original arm joint chain. Now the arm will affect the rotations of the group node, leaving the joints themselves with free rotation values, that can be rotated to get the feather stretch.  

NB.

I've also added an extra shoulder joint to achieve the necessary Z axis elevation - if you look at reference material, the wings lift at this point to tuck the second section beneath it and hug the body. Very important!

Outliner

Outliner, showing exactly what i've done. Each individual feather chain is in it own group. These group nodes are then parented down the hierachy - exactly how a normal joint chain would be, only theres a group node inbetween doing the spadework, leaving the actual joints on zero rotation and can be independantly manipulated for fine tweaking. I've set the rotation mode to Gimbal, so it's an absolute doddle to animate!