Over the past few months I’ve had the pleasure of working on the rendering and effects side of Plankton Invasion, and in so doing I created a very extensive system that would go from A to as near Z without artist intervention in as many cases as possible on this effects heavy animated TV production. The system was dubbed EPIC (Extreme Plankton Invasion Code).
The system was very successful in how it worked and in this post I will talk a little bit about the experiences I had in building it and hopefully it can help trigger some ideas for others, or serve as a help when thinking about your own systems.

– If you want to see the effects of this, check the post about plankton invasion in general: http://www.usefulslug.com/2011/09/plankton-invasion/ –

First a little brief about my experience before plankton invasion so that you know where I am coming from. This way of working was quite new to me, so that is why I would like to document it a bit, and my path to programming is part of that story.
I’m educated as a traditional illustrator, and taught myself 3d from I was about 16 years old, so that’s a good 13 years now. After college I taught myself how to rig better because I wanted to be an animator, and had realized that good rigs were important. I started getting work as a freelance generalist and character technical director. Already after the first TV pilot I worked on, I realized how useful scripting and programming was, so I decided to try to learn that by reading open source code for some expressions used in messiah:studio by christopher lutz. I didn’t know much about math, next to nothing about programming and the source code to the first major plugin I made, ‘Walker’, is so hideously inefficiently and inelegantly written that it is almost embarrassing. But the system worked, and ‘fake it til you make it’ was going to be my modus operandi from now on. Several plugins, scripts, rigs, procedural animation systems, short films, small scale feature, music videos and adverts later my knowledge of what was needed in fast paced 3d production had grown, and I was called in to work on Plankton Invasion, a 78 x 7 minute FX heavy TV show being made by TeamTo and Grid VFX.

The obvious problem in producing TV animation, is that if you want it to be any good, you need to do a mother-load (excuse my french) of work, and you don’t have the luxury of time. That’s just the reality of that, plain and simple, and if you can’t stand that heat, then the kitchen is no place to be. Luckily TeamTo and Grid VFX are both very experienced facilities.
I started making EPIC at Grid, when I saw that we were repeating a lot of tasks as vfx artists. Generating UV passes for explosions, adding particles to feet as the characters were running in the sand, dust impacts, fire on matches, objects on fire, smoke plumes, smoke trails, water splashes, depth of field focus fixes (the characters are really small so they are being filmed by tiny cameras!), tv screens, and a whole bunch other effects needed to be done for the show (about 60-70 different types of effects and fixes were eventually automated and added to the system).
For season 1 (which we just finished), this was 6.5 minutes per episode (title’s about 30 sec) x 39 = 253.5 minutes of animation to render. On average, about 50% of shots were effects shots (remember, not just explosions!) so that’s something like 126.75 minutes of effects shots.
In one year, we made roughly two hours of effects in season 1, chew on that while I adjust my hat.

Lesson One: Is it ready yet?
EPIC had to be made during the production, gradually expanding as new episodes came with new effects to put in. So it needed to be ready to use all the time. I chose to build it in python, even though I had never coded in python before, because I knew it was a flexible scripting language, and this system would have to be very dynamic. I built a system that would read from a .csv file, the breakdown of which effect was tagged in each shot. Any shot could have multiple effects. The system would then basically do a big ‘swich/case’ for each effect (basically a bit of code that would determine which function to call based on the name of the effect). Each effect had it’s own response, like generating certain render passes, or adding something to the compositing flow, and these were functions that were generalized in two code files, one for doing stuff in 3d, and one for doing stuff in compositing. I used text files as templates (I didn’t know about the template module at the time) and directly modified the ascii files for compositing and 3d with these.
The system was basic enough that it could be built in a hurry, and it could be used straight away, even if only for one effect at the time, but it was already saving time. Lesson One: Make it lean and mean but ready for use immediately, you can expand later.

Lesson Two: Can I do that in a more general way?
Treating 3d and compositing files directly in ascii format using text replacement, regular expressions and templates is not always straightforward. What each effect needed to be able to do was very variable. Some effects needed to place particle emitters, some required a bit of math to do rotations or other calculations inside the 3d scenes, some needed to adjust parenting and a whole bunch of different render settings and things needed to be tweaked for each type of pass. For the first effects I just took the whole block of text that made up the effect in comp or 3d, and just pasted it into the right place in the ascii file and tested the file in the 3d/compositing programs to make sure I hadn’t screwed anything up. That wasn’t going to be enough when things got complicated. At first it was just one or two effects that needed something special changed in the file so I just made some functions to set all the things at the same time. Bad idea, mostly. Soon enough I needed to combine some of the settings from one effect, and some of the settings of another effect, and set some third setting in a different way. I needed to start doing things more generally. Gradually I created all the functions that were needed, like setting lighting options, adding particle emitters, parenting stuff etc. Now the responses in the effect code themselves were easier to make, as they just needed to call any of the functions they required. I still kept some functions ‘big’, like doing all that was required to create a matte pass for an object (checking a bunch of options, looking for names and setting output paths) as a single function, because it was effective to be able to just call ‘createMattePass(path,objectNames)’
Lesson Two: Make functions general if you can, but also allow ‘straight to end product’ functions.

Lesson Three: Can a computer make that decision?
When working with visual effects, it is a bit weird to suggest that a script can do all that work that the artists are doing. What the artists are doing requires visual decision making and subjective judgment of what looks good in a shot. The fact of the matter is, the script can’t think like an artist could. Here’s how a typical workflow goes: The artist does task A, then task B then task C … Z
A – B – C – D – E – F – G – H – I – J – K – L – M – N – O – P – Q – R – S – T – U – V – W – X – Y – Z
Then the technical director goes, ‘hmm, you just pushed all the same buttons in a sequence there, let me make that into one button for you’.
Now the workflow is like this:
A – C – E – G – I – K – M – O – Q – S – U – W – Y – Z
That’s how it stays, because the artist has to make some decision at all those points.
But this is inefficient, so what is the answer?
Actually a lot of those decisions that need to be made, don’t need to happen at that particular time. A lot of them can be made much earlier. During the breakdown for the effects, a person can make the decisions like how big should a dust roughly cloud be for this shot, which explosion will fit the shot and many similar visual decisions like that, and the system can simply allow them to be made. Now the workflow for the artist is like this:
A – U – W – Y – Z
What a time saver! By simply making the decisions up front for as many of the variables as possible, we save a huge amount of work. The artist will still have to make decisions, and then treat the final composite, maybe even tweak the 3d shot, but we’ve moved all of the decisions to a few central points. For each thing we have to do, there might be different how far we can go towards Z, but our system should go as far as possible. To the artist, it should feel like they have an artist assistant in the system, not that it is ‘taking their jobs’.
Lesson Three: Design A to near Z systems. Let the artist make decisions early.

One: Helping others helps you!
If the person you help buggers off and you never see them again, you will at the very least have managed to solidify your knowledge of the matter of the problem by thinking about it again. This is great professionally as it helps make sure you really know how to respond when someone asks the same question later. Trust me, someone will! That’s the worst case scenario, the better is that you end up helping people again and again, until you really know what the hell you’re doing.

Two: Become the go to man!
I made ‘Easy, peasy, lemon squeezy’ my professional slogan. No technical challenge, problem or anything else was wrong to come to me with. However I would let them know if it was simply extremely unfeasible or overly difficult. On a whole, the whole point of the technical director/artist is to say “Don’t worry, I will deal with that problem for you” OR “I’m afraid that is not possible in this world”. As a technical artist/director, what you do is a kind of magic to everyone else, don’t expect anyone to know what that involves. It is either possible, come hell or high water, or it is not. Everything between is your domain (including how long it will take even if you don’t know). The guy that says “Don’t worry, I will deal with that problem for you.” is usually the unsung hero of the production, but everyone will remember him well later on simply because it is what everyone from producer to artist wants to hear, and you can deliver it.

Three: You can help the entire company by applying your thinking generally!
There is nothing wrong with stepping outside of the daily grind of rigging, programming tidbits and tools, or slowly moving vertices about, to take a grander view of the situation. Especially as a technical artist/director you are probably the most capable of doing this and even though the production staff might not appreciate it at the moment you do, they will (or should) kiss your feet when you save them from that 20th production problem that was narrowly avoided because of your clairvoyance. Make sure you have an understanding with your production staff that your role is not just that of an artist, but that of a scout and that of a strategist. I can guarantee you that every production that fails to invoke the use of their technical staff for these other jobs/hats, will fail in one or (much more usually many) more ways. If you find yourself in the need of having to convince a producer, let them know what amount of man days it would take for you to fix something, versus what it will potentially take everyone involved once they have walked into the trap already.

Four: You get a different satisfaction from helping someone else than yourself.
No shit Sherlock, said the bored reader, but it’s an important part. When someone else succeeds after having learned something from you, you feel good in a certain way. I distinctly remember some years ago when I helped someone, who was almost a complete stranger over the internet, understand some fundamental bits about lighting and 3d artwork in general, and then that person went on to produce better lighting than I ever did and ended up in Dreamworks and many publications within a few years, and even credited me in a ‘special thanks’ list in a publication. Don’t get me wrong, I don’t take credit for anything this person achieved, but the pride I felt for having helped was enormous!

Five: Being helped is also great!
When I started doing 3d professionally, I got a huge amount of help, artistically, professionally and just simply by getting work from another freelancer called Pål Syvertsen (Flottaltså). The amount of appreciation I still have for this help, as well as the others in that first year (especially William Eggington, David Maas, Christopher Lutz, Shane Ushijima, Brian Nicolucci, Peet Lee) amounts to the volume of a mountain in the Himalayas, if not more. One remembers the help one receives.

The past few months I’ve been down in Belgium working with GRID and together with TeamTo on setting up the pipeline, rendering and effects for Joeri Christiaen‘s Plankton Invasion. Finally some of the images are ready for the small screen and will be hitting VTM in Belgium this month, Canal+ in France next month and then hopefully soon global domination! The revenge of the infinitely small is upon us, watch the trailers below.

UPDATE!: check out some full episodes in french on Canal+:
http://www.canalplus.fr/redirect_pfv.php?vid=543262
http://www.canalplus.fr/redirect_pfv.php?vid=543289
http://www.canalplus.fr/redirect_pfv.php?vid=543294

In the spirit of dare to share the deformer will be available for $100 $50 $20 for the first couple of weeks. Get it while it’s hot

http://www.3dworldmag.com/2011/04/04/get-the-most-out-of-messiahstudio/

Walker should be used with version 3.0 of messiah and upwards.

Click here to see a feature overview video

Click here to view a silent usage demonstration video

Walker Tutorial video #1

Walker Tutorial video #2

Walk creation tutorial video

You can buy Walker for $100 by clicking the button below.

 

Modeling: Dan Barker, Garry Brown, Peet Lee, Vegard Myklebust
Rigging: Vegard Myklebust, Brian Nicolucci
Hair: Dan Barker, Peet Lee, Vegard Myklebust
Animation: Fredrik Lindbom, Mandy Mok, Vegard Myklebust, Brian Nicolucci, Toby Winder
Animatics: Garry Brown, Vegard Myklebust
Rendering: Dan Barker, Garry Brown, Peet Lee
Post: Garry Brown, Peet Lee

useful slug provided technical assistance on the short film Fair Trading? by Joeri Christiaen at THURISTAR The film was the winner of the 2009 film competition organized by BeFair.be / Trade for Development Center.

Concept & Storyboard Artists: Andrew Eadington, Richard Albon
Compositors: Garry Brown, Greg Cox, Ajanta Ghosh, Lucy Hare, Peet Lee, Simon Percy, Caroline Phasey, Nick Scott, Kirk Smith, Terry Wu
Character Modelers: Peet Lee & Michael Rollinson
Character Technical Director: Vegard Myklebust
Character Animators: Garry Brown, Lucy Hare, Mandy Mok, Fredrik Lindbom, Vegard Myklebust, Jon Noorlander, Toby Winder, Michael Rollinson,
Lighting & Render artists: Ben Beckett, Mark Dodwell, Greg Cox, Peet Lee, Simon Percy, Terry Wu
Matte Painting: Richard Albon
Object & Effects Animators: Ben Beckett, Andrew Bishop, Greg Cox, Mark Dodwell, Peet Lee, Simon Percy, Michael Rollinson, Kirk Smith
Shading & Texture Artists: Dan Barker, Andrew Eadington, Peet Lee, Vegard Myklebust, Caroline Phasey, Michael Rollinson, Lies Veldeman, Terry Wu
Set & Prop Modelers: Ben Beckett, Dan Barker, Garry Brown, Mark Dodwell, Peet Lee, Michael Rollinson, Kirk Smith, Lies Veldeman
Sound FX: Clifford Reeves
Trackers: Ajanta Ghosh, Toby Winder

Client: Pretzel Films
End Client: Network Rail
Concept & Director: Nick Scott, Nick Scott Studios
Production Company: Darkside Animation
Compositing: Richard Acton
Audio: Si Begg
Modelling: Dan Barker, Peet Lee, Mike Rollinson
Scene setup & Rendering: Dan Barker, Andrew Bishop, Greg Cox, Julian Davidson, Lucy Hare, Peet Lee, Vegard Myklebust, Simon Percy, Caroline Phasey & Mike Rollinson.
Character Rigging & Animation: Vegard Myklebust
Effects programming: Vegard Myklebust
Effects animation: Peet Lee, Vegard Myklebust, Julian Davidson, Dan Barker
Fluid simulation: Julian Davidson.