A small VFX studio pipeline: what you need and what you can skip

The short answer

A small VFX studio needs five things before it needs pipeline code: one folder structure used on every job, a naming and versioning convention everyone follows, a shot list with a status, owner and due date per shot, a review step where every version is seen against the brief and the client's notes, and a delivery spec agreed at the start. Most of this is convention, not software. Add a production tracker when the shot list stops fitting in your head, and add integration with your 3D and comp software only when someone on the team will maintain it.

What a pipeline is for

A VFX pipeline exists to answer three questions at any moment: where is the latest version of everything, what state is each shot in, and what does the client need to see next. Large studios answer them with asset management systems, publish tools and render farms managed by a pipeline team. A small studio can answer them with discipline.

The trap is to buy or build the large-studio version too early. A tracker with integrations into Nuke, Houdini and Maya pays off when someone maintains it. Without that person, it becomes a second job nobody has time for, and the team drifts back to the shared drive.

1Folder structure

Pick one structure and use it on every job. A common layout:

/PROJECT_CODE
  /editorial      plates, EDLs, reference cuts
  /assets         models, textures, rigs, by asset name
  /shots
    /SEQ010_SH0010
      /plates
      /work       per department: track, roto, fx, lighting, comp
      /renders
      /comp
  /review         exports sent to the client, by date
  /delivery       final files, by delivery date

The exact names matter less than that every job uses the same ones. A freelancer who joins on job three should know where the plates are without asking.

2Naming and versioning

Every file name should tell you the project, the shot or asset, the task, the version and, where it matters, the artist:

ABC_SEQ010_SH0010_comp_v012_ana.nk
ABC_SEQ010_SH0010_comp_v012.exr

Rules that save the most pain: versions only go up, never overwrite a version once it has been reviewed, and the render carries the same version number as the scene that made it. When the client approves v012, you can always find the exact scene that produced it.

3The shot list

The shot list is the heart of a small pipeline. One row per shot, with:

For a 20-shot job, a spreadsheet can hold this. For several jobs at once, or a job with freelancers in different places, a tracker that shows the same data as a board or a timeline and lets each person see their own shots saves a lot of messages.

4Review

Every version gets an internal review before the client sees it. Check against the brief, the client's last notes and the technical spec: frame range, resolution, colour space, edge quality. Keep notes per version with the frame or timecode.

For client review, send a proxy with the version number burned in or in the file name, and ask for notes per shot, one change per line. When notes conflict between the director and the producer, send the conflict back for a decision. Count rounds per shot against the bid.

5Delivery spec

Agree the delivery spec in writing at the bid stage: file format, bit depth, colour space, frame range with handles, naming, how files are delivered. A delivery spec that arrives the week of delivery, asking for a different colour space, is a re-render. Put the spec on the job and check every delivered shot against it.

Bidding and tracking cost

Bid per shot, with the tasks and days for each. Track the days spent per shot against the bid as the job runs. A shot that has used its days at the internal review stage is a conversation to have before the client review, not after delivery. The day rate calculator helps set the day rate the bid is built on, and how to write a 3D rendering quote covers the quote itself.

Freelancers in the pipeline

Freelance compositors and FX artists are normal in small VFX work. Give each one their shots, the plates and the references, the naming convention, the version they should work from and a due date in their time zone. They should deliver into the shot's folder with the correct name, not by a personal transfer link. Review their versions like anyone else's, and record their cost against the shot.

When to add a production tracker

A spreadsheet stops working when any of these is true: more than one job runs at once, more than three people update it, freelancers need to see their own shots without seeing everything, or the client asks for a status view. At that point, pick a tracker based on what you need:

• Shot tracking with integration into Nuke, Houdini or Maya, and a live review room: a dedicated VFX tracker such as ShotGrid, ftrack or Kitsu. See ShotGrid alternatives for small studios.
• Shots, tasks, freelancers, client review and the bid and invoice on the same job, without integration: a studio project management tool.

Doing this in OIO

OIO is project management for small studios, not a VFX pipeline. Each job is a project page with a ticket per shot or per task on a kanban or a timeline, with owner, status, due date and a checklist for the notes. Freelance artists get a link to their ticket and work from it with no account and no seat: they read the brief, download the references, upload their version and mark it done.

Each version goes up on the ticket. The client pins numbered notes on a still and comments on a video at the second, and clicks Approve this version. The bid, the freelancer costs and the invoice sit on the same project. OIO has no Nuke, Houdini or Maya integration, no frame-stepping or colour-managed player and no asset management; the free Blender add-on can post a line to a ticket when a render finishes. For the tracker comparison, see OIO vs Kitsu and OIO vs ftrack, and OIO for VFX studios.

Questions