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 |
