#0002 Tools of the Trade

There are well over a 100 different software applications used in visual effects and motion graphics today. Wikipedia lists around 70 packages for 3d work alone. Clearly, the CG supervisor must be proficient in one or more of the major packages and knowledgeable in several others. Invariably, the CG supervisor will be working with artists using software outside his technical sphere and invariably, given the rapid pace of new development and upgrades, this could include new versions of software the supervisor has used in the past. Expecting the CG supervisor to know every tool of the trade is unrealistic. As a CG supervisor you need to know how to supervise the use of tools you may not be expert in.

Obviously, as time permits, you should become knowledgeable in the tools used by your team. But learning new tools may be something you have very little time for. Even so, there are some steps you can take.

Don't Fake It
Resist the temptation to brazen your way through the situation with the pretense you know the software. This will not work and will, and should, get you in a heap of trouble. Be forthright in admitting you are not capable in the software package. If you don't, all you'll be doing is raising false expectations about your skills and knowledge. Remember, you were hired to supervise the artists who were hired to use the tools.

Pick Your Expert
Find one or two people on your staff who know the software well. These will be your go-to people if you get stuck. If there is no such person, you need to get one hired right away if the software is mission critical. If it's not mission critical, then the issue is moot. So we are talking here about software that is needed now or in the immediate future to get the job done. So make sure you have a go-to guy on the staff.

Learn the ABC's of your software tools
Find out first the applications of your software --what is it good for? Your experts can usually fill you in within the first five minutes. A little internet research will help if you need more information. Next, look into the capabilities of the software --what can it do? The difference between application and capability is this: application is about when you would want to use it and capability is about what you can expect to accomplish. For example, Blastcode is a great application for making things blow up or break apart. It's capabilities include taking an object and shattering it into big chunks, blowing out small pieces of debris hidden inside models, causing objects nearby to be effected, adding secondary explosive effects and dust, and so on and on. Finally, you need to understand the basic operation of the software --what is the workflow and the typical turnaround time, what data goes in to get the result, and what is the form of that result? For example, Blastcode works within Maya, so the inputs would include tyhe geometry to be blasted, objects to be ejected, the textures, etc. etc. The outputs would usually be a baked simulation.

Delegate, review and amend
Now that you understand the ABC's of the software, you are ready to start supervising. At this point you should follow the standard cycle of delegation, review of work and amending takes until the results are acceptable. We'll examine this workflow in another post in detail, but there are subtle but important issues to consider when you are not the expert in the software.

First, when delegating, you will need to consult one of your experts (who may be the artist but may not be) about the estimated production time and the workflow. Be sure you understand how this shot will be accomplished. Don't assume it follows the basic workflow, it just might be a special case, and you don't want to be learning that four days into a five day cycle, do you? If the artist assigned is not your expert, you should also discuss the same issues with the artist. You can do this with the expert present or not, depending on your comfort level with the subject and your supervisory relationship. Remember, you are the leader and your team expects you to be in control, not your expert.

Second, when reviewing, you need to consider the time required to make whatever changes you may see are needed. You may tempted to assume the changes are easy when they are not, and not being the expert, how can you really know? When you don't know, you need to ask, but before you do, prioritize your changes. What is critical, what is not? This should be standard in a review process, but because you are not an expert, you need to be more aware of this.

Finally, when asking for amendments, you will now need to ask again about time and production workflow. This is also a time to ask if there is some compromise that can be made to achieve the look (you should also ask this when delegating) or some alternate method. Perhaps by breaking down the problem into layers and compositing you can make a difficult challenge more easy. Or maybe instead of fixing some componet you make mattes and get it fixed again in the comp. Look for efficiencies and be flexible.

Troubleshooting is about experience
Sooner or later you will encounter a situation where your artist does not know how to get what you want from the software or cannot get the software to work as expected. You're the supervisor and you have to keep things moving. So you can call on your expert, and should if that's expedient, but remember your job is much about solving problems. So work the problem like any other, except you will have to ask more questions.

While supervising LIFE AFTER PEOPLE at Flight 33, I encountered a problem where the artist could not get the water motion I desired using Maya Unlimited fluids, an aspect of the program outside my hands-on experience. So the first thing I did is I asked him to open the Attribute Editor and read off to me the names of the attributes one by one. I delibaretly stayed out of his chair, because it's about supervising, not taking over. Most of the attribute names made sense to me, I have worked with wave deformers since before the word "deformer" was invented, so I was able to direct them. Once in a while he would come to one I did not know and I asked what the attribute controlled. Not surprisingly, my "expert" did not know the meaning of all the attributes! (This is, by the way, an all too common problem.) Within a few minutes we had the basic settings changed to get the right effect and a 15 minute test confirmed it.

You are the leader
As you can see, the supervisor needs to know how to dissect a problem and needs to know the principles of the art, not every tool. As the leader, you need to invest some time in learning the tools beyond the ABC's:

On a long project you should take the time to read the release notes for the application version in use. Don't just do this for the apps you don't know, do it also for the apps you know well. Re-read the release notes, troubleshooting notes, new features and basic feature summaries often. If you read these 5-7 times over a 12 month period they should be firmly fixed in your mind. Talk about these notes with the experts and artists using the tool will help them stay on the edge and will encourage them to read the notes also (many artists just open upgrades and start poking around).

As time permits, you should open the application and poke around the menus. If more time is available, or the mission requires you to have a deeper knowledge, invest time in tutorials.

Finally, find out where the user community is for the application and find yourself a super-expert outside the organization you can email, chat or phone for the crisis beyond your staff's experience. It could save your job.