Wednesday, August 15, 2012

Enter Sand(y) Man

Sandy Sutherland has been here since the beginning, when Triggerfish Animation Studios was only a few people working out of one building (The Long House). He’s been here through the years it took to complete “Adventures in Zambezia”, he witnessed the renovation of the Barn to meet the needs of a rapidly growing studio, and he will be here to see the completion of “Khumba”, and beyond.  

As Technical Supervisor here at Triggerfish, Sandy operates behind-the-scenes, and while the work he does is often unseen, without his help and his expertise there would be no “Adventures in “Zambezia”” or “Khumba”. In the Q&A below we shed some light on what he does – our way of saying thank you for all the work that he has put into our two films, and for all the fixes and troubleshooting that he will be doing for us tomorrow!

What did you do when you started out in CG Animation?

I've had to work my way up through the ranks. I started with modelling, texturing, rendering, everything, which is typical South African animator as it were. I got taken on for “Zambezia” but it was before (The Barn) was built. 

On “Zambezia” I was lead rigger, and we did the rigging for all the characters. We got every character rigged, and did all the fixes on them. When that was finished we moved on to doing the special effects – we did the dust, we did the clouds. We did the pots being dropped with all the colourful dust, also the shattering of the wheel at the end of the film, that sort of thing.

What is your role at Triggerfish now?

I am Technical Supervisor, so I take care of any fixes, methodologies on how to do stuff, and I look after the render farm. I also do a lot of troubleshooting – like right now I’m trying to fix a scene where one of the characters has been animated, but it’s a very big set so the character is very far from the origin. It’s a problem in a 3D package because the further you get from the origin, the more you start getting numerical instabilities, and then what happens is that the rigs don’t work very well or the mesh goes funny. So I’m busy trying to fix that in this particular scene, so right now the character is just in orbit.

I also developed the point caching system that we use here. We use a point caching system where we’ve got the animation rigs, but they don’t go through to lighting because that can be really heavy, so what we do is when animation is finished, point caching happens, and each point of the geometry is written into a file and then another file is opened that reads that frame by frame and moves the point as it were. We also do fur caching, which is very similar it just uses a different file format.

In terms of the render farm, I actually helped Basil build it, and I take care of it and make sure that it runs ok, and install new versions. I also look after the renderer that we use on the render farm – I build it in Linux and then make it run.

What’s the most challenging part of your job?

Definitely getting the scenes rendered. Some of the sets are so huge, and we’ve struggled a lot with the amount of memory needed to get them rendered, even though the renderer that we have now is very good at handling a lot of data. We developed a system where we use what are called ‘stand-ins’. We wrote out a mini-render for Arnold called an .ass file (the guy who wrote Arnold obviously had a sense of humour) for each asset, and then Arnold knows how to render that file, so it doesn’t have to translate itself and just renders it directly. So instead of it translating every little bush in the scene, it just loads the little .ass file in its place which it already knows how to render. So that way we save memory and time.

Another challenge was when we first started using Arnold, the plug-in that we were using didn’t support it that well, as it didn’t translate the paths properly. We use Windows work stations, but we use Linux to render, so you’ve got to convert the paths so that the two systems communicate with each other. We had to develop tools to convert the Windows paths to Linux paths and make sure that they are correct, otherwise all the renders crash.

You were here for the whole of “Zambezia” and now you’re here for “Khumba” as well, what differences can you see between the two films from a technical point of view?

Well, “Khumba” is just a lot bigger –in terms of the technicality and in terms of the shots. “Zambezia” was taken to quite a high level, but it can’t compare to “Khumba”. In “Khumba” the sets, all the bushes and the dressing and everything, are so much more complex than “Zambezia” was. So much so, that we actually had to use a different renderer for “Khumba”. We did a couple of test renders before “Khumba” started and we settled on the one we have now. The renderer that we used for “Zambezia” wouldn’t be able to render what we’re doing now – there’s just too much information.

Do you work very closely with Jared (our Software Developer)?

Yes I do, and with Simon before him. Jared and Simon developed most of the scripts – basically I just tell them that we need a script that can, for example, check the path and check that it’s correct so that when it gets to the Linux machine it doesn’t find that somebody’s typed a capital letter somewhere, then when it gets to the Linux machine it can’t find the path. In fact, Simon developed Squirrel, but I kind of initiated it. “Zambezia” was a mess, everyone was basically doing their own thing, and we tried to implement strategies and pipelines, things like that but it didn’t work very well. So when we came off “Zambezia”, Simon and I said that we had to do (“Khumba”) differently, that we had to have a system in place that automatically wrote where things went and knew where things were – something that controlled the whole system. It was actually intended to go a lot further but we just ran out of time. It was intended to be a complete approval system. So that let’s say a modeller is modelling something, he would finish and he would submit it for approval. It would then go to his HOD, but it would disappear from the modeller (he wouldn’t see the file anymore), and would then appear on the HOD’s list of things to do. The HOD would then be able to look at it and approve it. If it was approved it would disappear from the HOD’s list and go into the system, and if it was disapproved it would go back to the modeller.

That being said, what we have now works well. We have 1200 assets on “Khumba”, and there’s no real way of controlling them without having a system.

After “Khumba”, do you think you’d have another sit down and see how the system can be improved for the next film?

Oh definitely. The biggest problem we faced in developing Squirrel is that you need a few months of not working on anything else so that you can write the stuff and test it. Squirrel was  developed in production, which turned out to be a nightmare because we’d think something would work really well, but then it didn’t and then we’d have to re-work it. But because it’s in production, it’s more difficult because you tend to have to fix things in a hurry and as they happen, instead of testing the whole thing, seeing what doesn’t work and then fix it or re-wire it completely. So Squirrel, as it is, is not ideal because it’s been ad-hock fixed, as we needed it to work right then and there.  But it still works well!

That it does :)

Photo by Julia Merrett

Pin It

No comments: