Tuesday, 27 July 2010
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.
Monday, 26 July 2010
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.
Tuesday, 20 July 2010
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.
Friday, 4 June 2010
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!
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.
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.
Subscribe to:
Posts (Atom)