Th Pilot Rig (part 1)

The following shows the progress of my Pilot rig in its initial stages. 

This particular rig was a very challenging piece of work. Rather than setting up the IK spline that may usually go into creating the back joints, I followed a tutorial that builds all the components of the IK spline from scratch. We start with a a set of disjoined joints placed along the spine. A CV curve is then placed on each joint. From here the details are rather complicated, but to summarize the back was eventually made from two sets of spine joints, with an additional neck joint at the top and a root bone at the base of the spine. Eventually the goal of this set up is to create an advance twist function that can more accurately create human postures.

With all the fundamental objects in place, it was now time to fix the appropriate expressions and connections that will eventually govern them. Here are the results from the set up. At this point rotations in one orientation are affecting the locators when the actual twist hasn't been set up. In the next post you may see the fully working spine

Th Pilot Rig- Functionality

Having finished the spitfire rig, I was assigned the task of creating the pilot rig. The functionality of the rig is an essential question. Unlike the rig I made for the Rocket Girl from the Mission Control project, I am not required to make a rig with cartoony features. However I still want to create a rig that was both versatile and robust character set up that can create a realistic humanoid rig.

The rig is needed to be a pilot- so it is very possible that the lower half of the rig may never be seen whilst the pilot is flying. However, the scope of our project is to create assets that develop the pre-production of a film, and to have a fully rigged character was an essential part of our brief, even if we are unable to see a great deal of him. If it is possible, we may be able to incorporate a scene where the pilot rigs functionality is in full view.

Funtionality of rig

character should be able to:
Sit in the cockpit
Press buttons, levers
Stand along side his plane
Carry out a basic walk cycle

the character does NOT need to be able to:

squash/stretch
have facial expressions
do anything unrealistic/ over exaggerated

With this in mind, I start making the building blocks of a humanoid rig.

Introduction of Dropbox

As a group I feel that we had really progressed in our level of maturity. However talented one may be at the "particular aspects" of 3D animation, it generally is the case that organising the way in which we do "the particulars" can yield a greater number of man hours in which we can improve our product. Although we all still could improve as artists, as young proffessionals we had started thinking of ways in which we could do things more efficiently. Our first step was to consider using referencing in order for all members to be working all of the time. We found that this greatly increased the productivity of our pipeline and also the flexibility in which we can alter things.

However, it became apparent that even this may not be optimized yet. Now that things were getting more and more complicated with more files going back and forth between animators, riggers, trackers and moddler, we noticed another place for improvement: file sharing.

Given that we are all working on the same project with the same files, would it not be a great idea to be able to share some virtual space where we could access? Greg first proposed the idea to Ollie and then myself. After going through all of the implications that may arise we were delighted to have the addition of dropbox into our workflow.

Basically dropbox is an online storage space that takes a designated folder and memory space on your workstation. When you are connected to the internet, a total of 50GB is synced with the dropbox account. This is allowed across any number of machines.

As a group we were all able to have a work folder each- one for rigging, modelling, animating etc under each student. This meant that we were all able to access everyones work and see the collective progress that was being made. For example I would be able to see playblasts from animation and test renders as they were being done! This was a fantastic idea and with this use of skype, we were able to communicate ideas with great precision and speed.

Problems with Maya Referencing

Although we attempted to the best of our abilities to use referencing to aid our pipelining we soon discovered that maya created some major anomalies when put in to practice.

Our first problem occurred when I first started referencing the model for the rigging file. Soon after updating the model. I discovered that the regions that had been altered and modified in modelling would inherit some major anomalies when replacing the old file that I was originally working with. Here are a few snapshots of some of the problems that we encountered.


In this case, modifications (i.e edgeloops), were made to the back wheel

This video indicates an even greater exaggeration of the same problem where modifications were made to the wing flaps.




We tried to identify what the problem may have been. We discovered that any changes made through changing edgeloops, duplication created these problems. We also tried to see whether it was the face normals or naming conventions of the model pieces. Unfortunately after a great deal of troubleshooting with little results, we decided to bypass the problem.

Since the rig that I was designing was based purely off parenting geometry to to control curves with the appropriate pivot points, once the control curves had been set up, then the majority of the work was done. The only re-working required was to remove the original referencing in the scene that was not working.  Then you would have to re-create the reference, and finally one would have to re-parent the geometry to the control curves with the appropriate pivot points.

The following shows two reference files in one scene whilst replacing the old model with the new.

Once this fairly fast process had been done, then the model and rig reference would be replaced and set up for the animators who would continue animation.

Although this is not an ideal solution to our problem, we found it effective for our immediate purposes. We did however try to imitate a professional production line to the best of our abilities given the constraints that we faced.

Rigging the Plane (part 3) Finalizing and Testing

After fixing the majority of the rig controls I had finalized the spitfire. Here are the test videos that indicate that the rig has been limited, locked and presented as necessary for the animators use.

Rigging the Plane (part 2)

This is an intermediate post to indicate the progression of the design rig. After more analysing and tweaking it became apparent that the rig should be completely dummy proof. We don't not want any controls available to the animator other than the required ones, and that too, between certain limits of extremum. We also want nohing other than the control curves to be selectable. With this in mind I went through every control and measured what should and shouldn't be possible for the rig to achieve. I also added some more controls that were not originally included in my initial design (like the back wheel and the box styled object under the wing)

Again we must also mention that the model had been updated a certain number of times and had to be re-parented appropriately due to a problem with referencing whic I will detail in a later post (See the "Problems with Maya Referencing" post later in this blog).

The updated UV'd model

 The re-rigged plane with additional controls

Overall I am very pleased by the design of this rig. My most important feedback came from my animators who, even though did not have a finished rig, were still able to reference using what I provided to constructively criticize my rig for the projects benefit.

Here is my first recorded rigging test.

Rigging the Plane (part 1)

Having looked into the rough mechanics by which a spitfire functions, I began rigging the spitfire model. Since a plane is a solid collection of rigid moving parts there was no need to consider skinning/binding or painting weights. I decided to create a collection of control curves positioned in the correct way to creatively fit around the plane. From here I would be able to do direct parenting of the geometry to the control curves. Since the function of the direct parent method takes the child and makes it move (translate and rotate and scale) according to the pivot of the parent, we need to only adjust the pivot of the control curve.

Note- When referencing, it can be problematic to have groups/parenting or any key frames in the reference file. If parents have been made in a reference file, you may encounter an error as I did reading: "Can not re-parent from reference file". This was an initial problem for us that was easily resolvedby editing the model ref file. Similarly if any keyframe remain latent from a rig ref- the animation file will have those controls/attributes locked until they too are manually delated from the original ref file.

It is my job as a rigger to create controls that are both appealing and functional without any ambiguity. I had a good idea from the research I had done to know where to place the relevant controls and the generic design required. Having been used to character rigs, I found that I was more focussed on functionality and simplicity. Here are a few snapshots of the spitfire early on.

The first model ref draft

My first basic rig designs

Having placed the controls, I still had to correctly rotate all pivot points into their correct rotation axis. Here you may identify that although the positioning of the controls are correct, the way in which all controls rotate are not aligned.






Note- Once you have aligned the rotation axis correctly, do not freeze transformations as this resets the alignment of the rotation.  You may, as I did, mysteriously find that your controls keep reseting after all of the efforts undergone to fix it! Keep this in mind for future reference.