This blog aims to inform readers about the art of CG supervision --the challenges and techniques of managing a crew of artists engaged in producing visual effects or motion graphics for film, video or other media.

Sunday, July 5, 2009

When troubleshooting problems in computer graphics and visual effects, the CG Supervisor's hole card is a thorough understanding of the technical paradigm under the software.

Most 3d applications today are more or less procedural, using a node basis. The origin of nodes lies in C++, which introduced the idea of objects that can contain data and methods. "Methods" means a procedure or function that can operate on the data item. If you write JAVA or other types of code, you will often see this term.

An early form of nodes are simple data procedures called pipes. If you know or work with LINUX or IRIX or some other flavor of UNIX you should be familiar with pipes. Now, the pipes themselves are not, strictly speaking, nodes. Rather, they are io mechanisms that allow programmers to stream data from one program to another without writing a file, thus saving time and disk space by eliminating unnecessary io. Almost any UNIX based scripting language and some software take advantage of this mechanism.

Early image processing and compositing tools relied heavily on this mechanism, and these eventually were given front ends and became programs like Shake and Nuke. Other node-based compositing systems include Eddie, Fusion and Ice and Composer. Maya is mostly node based.Houdini is strongly node based, being highly procedural in its structure. Both Houdini and Maya allow almost any data stream to be used as an animation source.

Not all programs in use today are node based, but because C++ is the most common language for major programming projects, the underlying code usually resolves into object methods. Examples of non-node based software includes most paint software and some compositing software like After Effects, which tend to use a layering paradigm.

One of the challenging things for me in switching from Composer to After Effects was this shift in paradigm. Yet I found that despite the layering paradigm, essentially these programs, and other compositors like Nuke or Shake, define various data streams, manipulate these streams, and combine them.

Now, the point of this is not to analyze how every tool works you may encounter on the market, and this has been a very simplistic discussion, because againI want to move our thinking a little away from the technology and more into the art of CG supervision. As a supervisor, you don't need to know where every button is and where every function is, but understanding the paradigm the tools your staff uses is essential knowledge you must and can quickly acquire.

Let's look at why knowing the paradigm of your tools is most important. First, many artists learn how to drive the software to get a result, often following a canned recipe they learned somewhere. Too many have no clue how the software paradigm works to influence the result, so when the results don't come out as expected they think things are broken and they get stuck. By understanding the paradigm, you can help them get unstuck, because you can work the problem in a way that allows you to think outside the box of the specific application while staying comfortably inside the box of computer graphics principles for 3d, compositing, paint, modeling, dynamics or whatever.

A second reason to understand the paradigm of the tools has to do with the direction-review-revision approval cycle. For example. software like paint often uses a direct manipulation process, which makes it very difficult for artists to quickly make changes. However, if your artist is working in Photoshop and uses more advanced portions of the software, including non-destructive masking, adjustment layers, and layer comps, etc. the revision cycle could go faster. So making sure your artists are working in the best way can be helped if you understand how the software wants to be used for efficient revision.

This brings us to the third reason, cost control and estimating. O.K., that's two things, but they are ultimately interconnected. Direct manipulation tools can, in the hands of a great artist with impeccable direction and impeccable ability to interpret direction, can give results more quickly than indirect manipulation tools. More concretely, a paint artist can often generate a great matte painting quicker than the scene can be realized in 3d. However, once built, the 3d artist may be able to make changes quicker. All of these considerations go into your cost control and cost estimation.

In summary, you have a leg-up on other supervisors if you are an expert in your shops tools, but it is not practical for anyone to be an expert in every possible tool in use today. If you understand the underlying paradigm of how the software works, it will help you trouble shoot (and anticipate) problems, control the work pipeline better, and be proactive in cost control and give better estimates. It is not practical to be an expert in every tool, but it is essential that you understand the paradigms of the tools your shop uses.