If you have been keeping up with the blog, you know that I’ve been out of the software development loop for a bit. The interesting thing about being out of the loop is that it can give you a bit more of an objective perspective when looking at the ‘new’ things. It seems not much has changed – at least not dramatically. The one thing that does seem to stand out a bit has to do with object oriented analysis and design. Object oriented analysis and design is a method or process that is used for software development (often using an object oriented language, like C++ or SmallTalk or… fill in this space with your favorite object oriented language here).
Back when I did this professionally, there were a couple of different ways to go about doing ‘object oriented’ analysis and design (OOA/D). After 10 years or so, it looks like there are still a number of ways, but one of the more popular and effective methods is called UP (Unified Process). A couple of the ‘old boys’ put together their thinking caps and agreed to agree on a process for object oriented analysis and design.
I know, you are asking,”‘What on earth does this have to do with animation?” Please bear with me just for a little bit longer. Two things you need to understand to make the link.
1) The first thing to understand is the old way that software development used to be done (in the software development world 10 to 20 years is equivalent to eons of regular time). At the risk of oversimplification, in the past, the common method used to figure out what the system was supposed to do, was to do a requirement analysis, then design the system and then implement it. Each was a separate step and the steps had to be completed before you could go on to the next step (this is also commonly called the ‘waterfall’ method). Analyze, design and then build. Research now says this is bad. Research says that at the end of the project about 1/2 of the requirements originally defined are not what the client actually wanted. That means a pretty useless system. That doesn’t mean that thinking, analyzing and design are bad. What is bad is how much of each is done at what stage… which leads to…
2) The second thing to understand is that this has been replaced by a more iterative method. The method goes like this: Figure out a few of the ‘core’ requirements, analyze a few of those in detail (a subset of a subset), then design and immediately implement those few core requirements. The next step is to take what you implemented, go back to the client, and take their feedback to modify or add any requirements and repeat the loop. Progressively defining more requirements and ‘building up’ the system (i.e. program) incrementally. This way the client gets what they asked for, give feedback on what they are seeing developed, they see something right away, and the developer has the satisfaction of seeing something working (instead of being bogged down in requirements analysis for a year). Over time the requirements get massaged and they eventually stabilize, over time you get the completed software package built up in iterative steps. Get the picture?
Ok, so now for the setup to the link to animation. There are fundamentally three ways of making animation. 1) Pose to Pose, 2) Straight Ahead and 3) a combination of 1 and 2. Richard Williams (of Roger Rabbit fame and whose Animation Master Class I had the privilige of attending!) advocates #3. Rightly so. You nail down your poses to see where you are heading with the animation, then you go ’straight ahead’ between the poses. Getting the best of both worlds – structure and direction from method #1 and the freedom and looseness of method #2. Most of us have used this method with varying degrees of success.
The specifics of a general animation workflow go something like this: 1) First we analyze the shot: what is the character doing, thinking, feeling? Get some reference footage. 2) Then we plan the animation: Act it out. Draw some thumbnails. Do some initial blocking by setting up our key story telling poses to see how it’s all working out. 3) Finish the shot: add breakdowns, tweak overlapping motion, add secondary motion etc. It’s a pretty good process.
Now work with me here… think about the software devlopment process and its similarity to the animation process. Software development: 1) Analysis, 2) Design and 3) Implementation. Now think about the animation process 1) Analysis, 2) Planning and 3) Implementation. It’s essentially the same process. Analyze, design, and implement. Interesting, huh? Well, it is for me!!
Anyway, up to this point I’ve been thinking about the animation process in the same way as the ‘old’ method of software development. The waterfall method. Figure out your shot from the very beginning. Analyze it till you are blue in the face. Then block the shot making sure you have your story telling poses. Then finally finish off the shot after it has been approved by the director.
Now, I wonder, can we as animators learn from the software development world? They discovered that the waterfall method ended up with something the client didn’t really like. Can we help satisfy our director’s vision by using a more ‘iterative’ approach? I think we already do – but maybe we need to be more aware of it.
Why is there a method or process called ‘layout’ in animation? This is where camera positions, general character positions and character movement (i.e. positions of the body of the character, not articulation) are defined based on the storyboard. It’s also called an ‘animatic’. That is the equivalent to a subset of the ‘core’ requirements being implemented right away. It’s the result of a partial requirements analysis, design and implementation. We see the ‘animation’ taking place already at the ‘layout’ stage. That’s just like the Unified Process!
Why is there a process called ‘blocking’ in animation? This is where we put our story telling poses. We block the ‘rough’ animation with these poses to show the director where we are heading. Again, more requirements are being defined and analyzed, more is designed and then implemented – right away. How many times have you gone back to fix the blocking, because after showing it to the director they said it’s not what they wanted? That’s the Unified Process in action.
We actually follow the iterative process more than we may be aware of… What would happen to our animations if we followed the software development methodology more closely? Maybe a change in mindset is enough to make an improvement.
I used to think that if I figured out exactly what I wanted at the beginning of my shot then I should stick to it and never deviate. After all, I put all that time into the research. What about all the blocking? I spent so long setting up each pose so that it would read correctly. Why would I throw that perfectly good pose away? Maybe that’s a bad way of thinking about it. We should be flexible to see that some things are not as good as we originally thought and planned, that a certain pose really doesn’t fit, that that part of the shot is not what the director really wanted. So we iterate. Go back, refine, and move ahead implementing the changes. If nothing else, this mindset will help us to be a little more flexible and less prone to freaking out when changes come our way. Maybe.
Is there something else we can learn from the software development process? What else can we learn from other disciplines that would help to make our work excel? Ah well, back to animating!