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.

Research into the Spitfire

In order to rig the moving parts of a spitfire I would have to first analyze its structure. By doing this and understanding how the spitfire was built, I would be able to study other resources such as live footage to then have enough information to make an informed decision about the rig.

My first sources of resources were images taken from air shows and live footage and blue prints.
In the following piece we can see the moving points of the spitfire to a great degree of detail. We can see the physical nuts and bolts the comprise the mechanics of the landing gears, the cockpit, the wing flaps etc.

The following images show the spit fire in mid flight and give an even more in depth perspective of their mechnisms. The first images give one a very good idea of how the landing gears work and even how the centre of gravity acts on this massive, dynamic object.

Spitfire mid-landing

Spitfir mid-landing

Spitfire stationary

Spitfire mid flight 

Spitfire taxi-ing on the ground

Spitfire mid-flight

The following video footage was key in getting an even better idea of the actual aerodynamics of the spitfire. Although some of the models may vary, we can ascertain a great deal of information about the movements of the wing-flaps, landing gear, tail flaps, propellor etc.














Using all of the collective resources, I am now in a position to make informed choices about the rig. I have a far greater understanding of the dynamics and animation required for the spitfire project. I feel that the research has clarified the limitations of the rig, the functionality of the rig and has also given my a number of ways of creatively making the necessary control curves.

Referencing With More Rigour- Our Formed Pipeline

Now with a referncing test undergone, I was now ready to take a first draft of the model and begin rigging.

There are a few things that my group considered before we began anything. We had to consider the risks that were involved  in referncing. The most major concer is that the process involves replacing files. If for some reason the reference did not work it could jepordize work in the next stage of the pipeline. e.g if the model was updated, and the rigging ref was no longer compatible then the rigging would need to begin from scratch again. Similarly if the rig is updated to an animators project and was not working with his animation, then all of the animation work coulld amount to nothing.

For this reason it was esssential for us all to have a convension that we all had to stick to. As Ollie would update his modelling, he would have a number of versions of his model. He would name then something like "spitfire_model_REFver###" where ### maybe a number. when he was ready, he would send me a file named "spitfire_model_REF". I would use this as my reference and create a rigging version "spitfire_rig_REFver###" where ### number is my versioning of the rig.

As Ollie would work on his model and wish to send me an update, he would save a versioned copy, and then overwrite the file to "spitfire_model_REF" again. I would use this file and replace my old reference with the new one. Now when I open my latest rigging file, it should be referencing the new spitfire model. However, in the event that the rig did not work with the modelling file, we could always find a previous version for when the model last worked with the rig.

Before passing this on to the animators, it was good for us to test it out at the rigging phase. If al was okay, i would save my latest rigging file as "spitfire_rig_REF". I would then pass on my latest rig and Ollies latest model to the animators whose files should then automatically update. Again, should we run into any errors along the way, we would always be able to come back to a place where a version of the rig and model was working.


We have a similar convension planned for lighting and other aspects.

Research into Referencing

In the previous post we faced a bottle necking problem in the pipeline that slowed down productivity and also didn't allow the flexibility to evolve ideas.

Myself, Ollie and Greg sat and discussed methods of improving our pipeline and stumbled across a topic in Maya called referencing.

Similar methods are used in industry to allow overlapping of work rather than the 'ast job finishes and the next job begins' approach which seems ameture and unprofessional.

From the research that we had done, it seemed that referencing was a very simple cocept that would solve many of our problems. Take the example of the link between modelling and rigging. A draft of the model is passed on to the rigger who starts rigging.

Instead of physically imorting the moddling data into his rigging file, he simply references it at a certai path loction on the computer. The name and the location of this file is very important. Now lets say that a week later the moddler has made some additions/modifications to the model. The rigger should simply need to take the new moddling file, replace the old model reference with the new one. Now when the rigger has opened his rigging file, it will update with the new version of the model. Now the rigger can continue to develop the rig without having lost any of the work he did to the old version.

The same concept can be applied to animation. So the animators can recieve a rig draft. They start animating using the rig reference file. Some time later the rigger may come back with a more detailed version of the rig which can replace the old one and then be used for more animation to build on the previous work.



This allows the modeller, rigger, tracking artists, animators to be working on there individual aspects for a greater duration of the project. This will results in greater productivity, a more flexible product with a much lower risk of failure to meet a deadline.

Here are some websites that allowed us to understand the referencing concept to a greater level.

http://www.3dfiggins.com/writeups/mayaReference/


This video also greatly assisted me in my initial understanding.




However my greatest resource in understanding more about referncing was digital tutors. I used many of their tutorials to help me see referncings uses and practical implementations.

The Rigging Pipeline

In previous projects that I have been involved in the pipelining was ineffeicient but simple. First the model would be made early on. Once finalized, the UV'ing of the model and texturing before starting and binding the final rig. Even from here the animation would begin only when the rig had been completely done. One can clearly see that there are problems with this method.

Problem 1: Ineffeicient
In an ideal situation, you should be working at all times wherever you are in the pipeline. Sometimes due to the dependancy of some jobs in relation to others, this is not always possible. Hoevever by having to complete a model before rigging, having to complete a rig before animating etc, we soon see that we have alot of idle time for a great deal of the project. This is a waste of human resources and does not make the best use of the availible man power.

Problem 2: Restrictive
By having our work in a very modular style we lack the ability to go back in the pipeline. Once the model or the rig is finished then we can no longer go back to it. Lets say that some where down the timeline we decide to change a small element of the model whilst we had already reached animation phase of the project. We would have to ammend the model, redo the rig and reanimate the scene. This is not a viable option. The same goes with the texturing or the rigging or the lighting etc. We are unable to adapt or evolve our concepts, when evolution of a concept may be essential to the improvment of the final piece. (especially as more and more research is done)

Problem 3: Causes Rushing
We have already mentioned how each member of the pipeline is dependent on the task prior to them thus leaving ample amounts of idle time. However the flipside tio this is that when the task is assigned, we are each forced to work to a very immediate deadline. This means having to rush to complete your job and doing it 100% correctly in the first go. In my particular field this can be devestating since a rig concerns technical kinematic controls. Should there be a malfunction that may be discovered during animation (relativley close to the end of the project) then we would all be in a great deal of trouble.

With this in mind me and my group decided that we would be able to optimize both our efficiency and quality of work if we adopted some way of being able to work n our individual parts throughout the entirety of the project whist being able to update evryones project files to seamlessly integrate the newst 3D assets.