/* */

Friday 4 June 2010

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!

Thursday 3 June 2010

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

Wednesday 2 June 2010

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!