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.

Unit Introduction

Sanjay Sen Industry Exercises 3 Brief Breakdown.

In this Unit I will be involved in the successful delivery of two projects.

Project 1: Spitfire Project

This is a client based project set to us by a Framestore Director. He has assigned us the job of creating a Pre-visualisation of a potential film based on a World War 2 fighter Pilot.

Our task as a group is to create a realistic aviation scene with a take-off/landing sequence. The piece must be photorealistic, believable and to a professional standard.

My role in this project will be to create both an animator friendly rig for the plane such that it carries out all functionality and also to create a pilot rig who will be seated in the cockpit. I also may be assisting with any dynamics.

Project 2: Mission Control

This is a third year student based project. Being part of the rigging for his main character, it will be my job to create a cartoon styled rig with great capability.

Again this project is constrained to a deadline and working along side a team within a pipeline.

These two projects, whose progress will be documented on separate blogs, will constitute the work of this unit on which I should be marked on.

Post 1: Two projects, One Unit

This blog documents the unit Industry Exercises 3.

Myself and other members of my group have decided to partake in two projects that both be assessed with this unit.

This blog follows the development of thhe "Spitfire" project.

The following is a link to the "Mission Control" project.
http://ravesanjaysenindustryexercises3.blogspot.com/