Week 11

Hi Team,

This week I’ve been with you on-premise in Gothenburg Sweden, gauging workflow and current issues, the most important being the need for production tracking. I also did some research into the pipelines of others, primarily the one developed at Rythm & Hues through their presentation posted 2 years ago.

Table of Contents

• Production Tracking
• ftrack
• Tactic
• Rythm & Hues
• Multi Publish
• Next Week

Production Tracking

In January 2017 we had a series of internal meeting about optimising the workflow in two major areas.

1. Everyday artist productivity, such as publishing, loading assets, making point caches.
2. Artist management, such as scheduling, budget and tasks.

I’ll refer to (1) as Pipeline and (2) as Production Tracking. With pipeline shaping up, the bottleneck now moves onto production tracking.

Below is a matrix of what we are looking for in terms of production tracking contrasted against what each available product is offering.

Product	Hub	Users	Gantt	Tasks	Assets	Review	Comments	API	Open Source	Local
Trello
MeisterTask
Asana
Rational Plan
Google Sheets
Stalker
NIM
ftrack
Shotgun
TACTIC
5th Kind

The three major contenders are NIM, ftrack and Shotgun; 5th Kind excluded due to poor reputation.

The benefit of NIM was immediate; local hosting. It meant no upload to a third-party server and no external monitoring made possible, providing for a secure and comfortable trail experience.

The user interface was bold and impressive but as we tried replicating an on-going project via its interface we discovered an opinionated approach to production tracking where the idea of production concepts such as Shot and Sequence was locked in and misaligned against our own model.

For example, on a current project some of our shots have no numbers but just names. NIM however requires that each shot has a corresponding sequence with a three-letter code and padded number - e.g. SEQ01-SHT010.

If we were to try NIM on a new project, odds are we could have worked within its constraints and found a workflow that aligned with the opinionated structure it offered, but we couldn’t risk establishing a new project using an untested product and hence we were unable to fully appreciate most of what it had to offer.

From a development perspective, the NIM API documentation was lacking examples, consisting primarily of automatically generated snippets with little reasoning behind or intent of their use.

Next week we’ll give ftrack a try.

ftrack

Test Duration: 3h

ftrack, like Shotgun and NIM, provides each artist with a personalised space in which to view their current and upcoming tasks.

Administrators orchestrate multiple projects by defininig assets, shots and the tasks associated with each. Each item supports assignment and comments, the system also provides the basis for client review via personalised and archivable pages with support for video playback, comments and annotation.

Features

• Unopinionated, sequences, shots, asset and tasks are equal with regards to features, such as assignments and comments.
• Tasks, with status, timeline and assignee
• Notifications, via email
• Assets and relationships to tasks
• Password protected, per user
• Roles govern who sees what, per user and/or client
• Project status, limited per role
• Finance status, limited per role
• People, who is involved where doing what
• Web based, cross-platform, works on mobile devices
• Internal and external review
• Scheduling, Gantt
• Calendar
• Booking
• Finance

Missing features

Here are some of the things ftrack does not have that we must cover elsewhere.

• Main project page, a landing page with links to relevant material to a given artist, such as ftrack
• Freelancer contract management, including payroll and responsibilities

Tactic

Test Duration: 4h

Getting TACTIC up and running involved a Docker command, following which the web interface was available at http://localhost.

$ docker run -ti --rm -p 80:80 -p 2222:22 -e ROOT_PASSWORD="password" diegocortassa/tactic

Predating Shotgun and ftrack, TACTIC was at one point a commercial product that turned into open source software shortly after release. The company - Southpaw - now builds upon their open source offering via pre-defined configurations and cloud hosting.

At a glance, it features all of what ftrack offers (listed above), including video review and customised client areas.

In addition to what ftrack and Shotgun offers, it also provides..

• A node-based workflow configuration, what data exists and how it travels from department to department
• An open source license, which means (1) it’s free and (2) we can customise it in every way.
• Written in Python, which is familiar grounds and integrates well with our existing pipeline
• Postgres database, which is what I would personally use as well.

It does however suffer from an abundance of bugs, clearly visible to both the administrator and user, which makes the choice simply impractical.

• Information appears in popups, few of which can be closed
• 1 bug every 5 minutes

Example output

...
ERROR: do_query error:  column shot_texture.search_code does not exist
LINE 1: ...."search_type" = 'vfx/shot?project=spiderman' AND "shot_text...
                                                             ^
SELECT "spiderman"."public"."shot_texture".* FROM "spiderman"."public"."shot_texture" WHERE "shot_texture"."search_type" = 'vfx/shot?project=spiderman' AND "shot_texture"."search_code" = '010' AND ("shot_texture"."s_status" != 'retired' or "shot_texture"."s_status" is NULL) ORDER BY "shot_texture"."code"
Error:  An error was encountered adding this item.  The error reported was [do_query error: SELECT "spiderman"."public"."shot_texture".* FROM "spiderman"."public"."shot_texture" WHERE "shot_texture"."search_type" = 'vfx/shot?project=spiderman' AND "shot_texture"."search_code" = '010' AND ("shot_texture"."s_status" != 'retired' or "shot_texture"."s_status" is NULL) ORDER BY "shot_texture"."code"
]
--------------------------------------------------
  File "/home/apache/tactic/src/pyasm/command/command.py", line 241, in execute_cmd
    ret_val = cmd.execute()
  File "/home/apache/tactic/src/pyasm/prod/service/api_xmlrpc.py", line 200, in execute
    my2.results = exec_meth(my, ticket, meth, args)
  File "/home/apache/tactic/src/pyasm/prod/service/api_xmlrpc.py", line 230, in exec_meth
    results = meth(my, ticket, *new_args)
  File "/home/apache/tactic/src/pyasm/prod/service/api_xmlrpc.py", line 5296, in execute_cmd
    Command.execute_cmd(cmd)
  File "/home/apache/tactic/src/pyasm/command/command.py", line 241, in execute_cmd
    ret_val = cmd.execute()
  File "/home/apache/tactic/src/tactic/ui/panel/edit_cmd.py", line 411, in execute
    cmd.execute()
  File "/home/apache/tactic/src/tactic/ui/panel/edit_cmd.py", line 127, in execute
    last_sobject = my._execute_single(code, name=name)
  File "/home/apache/tactic/src/tactic/ui/panel/edit_cmd.py", line 324, in _execute_single
    raise SqlException(msg)

Error:  An error was encountered adding this item.  The error reported was [do_query error: SELECT "spiderman"."public"."shot_texture".* FROM "spiderman"."public"."shot_texture" WHERE "shot_texture"."search_type" = 'vfx/shot?project=spiderman' AND "shot_texture"."search_code" = '010' AND ("shot_texture"."s_status" != 'retired' or "shot_texture"."s_status" is NULL) ORDER BY "shot_texture"."code"
]

Rythm & Hues

Research Duration: 16-24h

In 2014 after the company went bankrupt, a video was posted on Vimeo detailing how their production pipeline worked, and it’s surprisingly simple and possible.

One of the things they do differently from other pipelines (that I’m aware of) is how they manage to encapsulate app dependencies to any task - such as rigging their tiger - in a single folder. This folder then only contains things related to rigging the tiger.

Similar to how in our case everything related to any asset is contained within a single folder, but in their case the separation is even more specific.

In practice what this means is that all paths used within e.g. Maya are local to the current working directory and that shipping this directory to another computer is a mere copy/paste. References, textures and caches all reference the local working directory hence no additional logic, conversion or dependency tracking is necessary.

It also means sending a shot or asset to a farm for rendering or additional processing is dead simple.

What baffled me at first was how they accomplished this without huge amount of data duplication. How can they avoid having multiple copies of the same version of their tiger model in each of the task folders that used it? How do they manage to keep track of updates of this model? This was the genius that enabled this level of specificity and it isn’t complicated.

└── ProjectFolder
    └── workareas
       ├── 1000
       ├── 2000
       ├── PiPatel
       └── RichardParker
           ├── modeling
           ├── lookdev
           └── rigging
               ├── v01
               └── v02
                   ├── _input
                   ├── _output
                   ├── nuke
                   ├── houdini
                   └── maya

Note that (1) all assets and shots are stored together under workareas/, (2) tasks are stored directly under a given asset (as opposed to under a dedicated work/ and publish/ folder), (3) task areas are versioned and (4) inside each task there is an _input/ and _output/ directory. This is where things get interesting.

The _input/ directory contains directories from other assets, e.g. the rig from RichardParker would reside in the _input/ of shot 1000.

The _output/ contains data produced within a given workarea, such as the rig produced in RichardParker/rigging. To avoid the aforementioned problem of data duplication, these outputs are symlinked into another workarea. These symlinked are used both to preserve disk space, but also to maintain a physical link between what data goes into a workarea, as well as what goes out of it.

└── output
    └── rigDefault
       ├── v001
       ├── v002
       └── v003
           ├── rigDefault.abc
           ├── rigDefault.skel
           └── rigDefault.ma

The beauty of this system is that now all data is tracked. Anything going into any asset or shot is physically tracked via a filesystem mechanism and workareas are the sole unit of work. All other benefits of our system, such as validating and guaranteeing a level of quality on output and relieving the artist from working with paths directly.

I’ll be looking at rolling this out as soon as possible.

Multi Publish

As a new feature this week, you are now able to publish to multiple assets at once. The Creator interface now offers an option to specify the name of an asset. The asset defaults to the asset you are working with, like a shot, but you can change it.

This workflow would allow you to for example perform look development on multiple assets within a single Maya session and have each look publish to each individual asset.

Next Week

Next week I’d like to integrate ftrack into your workflow in two major areas. Firstly I’d like dailies to happen there and secondly I’d like for published assets to appear automagically in the ftrack interface.

I’d also like to have as many of you as possible work in Paperspace; the choice to go with cloud technology is currently blocking other pipeline development so it’s important we overcome this obstacle as soon as possible.