Production Pipeline in CG Fun

For a backend area, we’ll want to provide some kind of method of communication between artists—especially since most everyone is remote to the server. A news area with comments (either in a bulletin board or weblog fashion) is key. Utilizing MovableType or some similar weblog with comments setup is ideal for this kind of communication. There needs to be a central calendar as well to allow deadlines and milestone dates to be seen by everyone. MovableType is a clear choice compared to pretty much anything out there. It runs locally, runs on PERL, and has been hacked into so many different CMS’s that it’s not even funny.

The next important step is setting up the directory structure. Directory structures were established by Kodak back in the day, and are one of those things that you either know or don’t know. Ideally, we should stay as close to the Kodak paradigm as possible to allow new artists who have worked in other major facilities the ability to jump right on board.

We need a directory structure that will allow for wild flexibility between a 4 minute short and a 90 minute feature film. The first thing is that we need to have a high level project setup. The system should allow for the creation of a new short, film, rendering, or group of shots from another effects house to be grouped together. The best all encompassing term would be “Project,” and so we’ll go with that. Kory’s existing nesting looks something like this:

[Project]

• sequence




• shot




• [Camera]


• [PreVis]


• [Characters]


• [OptimizedSet]


• [Animation]


• [ClothSimulation]


• [FXelements]


• [LightRig]


• [TestRenders]


• [Comps]


• [FinalRenders]


• [SourceFootage]

That’s lovely and all, but we’re going to share these elements, e.g. characters, set, animation loops from the trax editor, the lighting rig, etc. It doesn’t make much sense to have a copy of the model of one character for every single shot in which that character appears. So we need to come up with some kind of central repository for elements and have that symbiotically linked to the directory one is working in—or associated with that shot and sequence via the database.

So we have a setup for directory nesting:
/[projectname]/[sequence]/[shot]/[segment]/[element]/

But we also have
/[projectname]/[library]/[elementgroup]/[element]

What happens to elements that are not ready to go? We create a “workbench” directory at the same level as the “library” directory. Once elements are finished, they simply are moved across, and the directory structure is kept intact.

/[projectname]/[workbench]/[elementgroup]/[element]

Then to do one better on top of that, what happens when we start spreading the love over various servers? So elements should be referenced by their servername and mount point for NFS or AFP or whatever the heck we choose.

/[servername]/[projectname]/[etc.]/[etc.]/[etc.]

Before I get too hyper, I want to make sure that files that are not project specific—administrative forms that are used over and over—are kept separate from the project files so that when a project is archived, those files don’t move. Many of these files aren’t going to be used by the artists on a day to day basis, but they need to be available.

[Administrative]

• [Correspondence]


• [Forms]


• [Legal]


• [Reference]


• [Templates]

What of files that are not project specific, don’t quite fall under “administrative,” but deal with production? Let’s steal an idea directly from Jason Schleifer and create a “Production” share at this point.

[Production]

• [Software]


• [bin]


• [mel]


• [applescript]


• [perl]


• [shell]


• [shake]

So that’s the beginings. Anyone have any ideas? Next time? Data modelling.