Week 1

January 7, 2017

This week, we established what was missing and what was needed to implement the missing bits.

Table of contents

  1. Overview
  2. Filesystem API
  3. Filesystem UI
  4. Collaboration
  5. Moving forwards

Overview

During the first week at Mindbender, we established that the main issue was validating data passed from one artist to another. That is, artist often had problems with assets not being formatted properly.

In order to aid in formatting, we chose to implement a publishing mechanism with which data would first be validated before being passed from one artist to another. A mechanism that would be able to automatically deduce, based on the content given, how said content should be formatted and allow the user to make the necessary changes if needed.

In order for a publishing mechanism to be implemented, there needed to be a concept of “project” and “asset”. That is, valid data depends on both the project and the kind of asset an artist is dealing with. For these concepts to be implemented, we needed to take a closer look at how data was currently structured on the file system.

It turned out that although artists understood the concepts of project and asset, the concepts were not well enough defined on the file system. In this case, each project was laid out as a Maya project, where some part of a shot were delegated to one subdirectory (e.g. cache/) and other parts residing in another (images/). Assets on the other hand was located in scenes/, under an arbitrary level of nesting.

So this is where we started, the file system layout.

Filesystem API

The filesystem represents the data around which Mindbender is built. It is therefore the single most important asset to the company and by extension the most important asset to get right.

The foundation is a customised version of Pyblish Starter, which is a simplification of Pyblish Magenta, based on Asset Map, which itself is a simplification of the Framestore layout.

Terminology

These keywords are introduced into the Mindbender pipeline, each represented by a folder or file and are briefly introduced below.

  • Asset
  • Shot
  • Subset
  • Version
  • Master
  • Private
  • Public
  • Task
  • User
  • Application
  • Representation

Asset and Shot

Throughout the years, content creation studios have converged towards a common high-level representation of the data they produce, namely “assets and shots”.

Assets and Shots cover almost all, if not all, possible data a content creation studio is able to produce and makes for a solid foundation upon which to build more complex and bespoke data structures.

Version

One such data structure is the Version. A version represents an iteration of data, the first version being the catalyst in a series of updates or upgrades to the data. Each version contains one or more “representations”.

Representation

A representation is one format in which to represent a particular set of data.

For example, an image may be represented as both a .png and an .exr. They both represent the same data differently. It may also be represented by a description - e.g. “A mountain view of a vast landscape” - a color or even a memory. Each of these are representations of the same set of data.

Each representation occupies one or more files residing in the Version directory.

Private and Public

Another important aspect is the separation between Private and Public. In other words, what is in development, and what is shared. At Mindbender, this concept does exist but is again not very well defined. Shared files lie amongst files in development, making it difficult to programatically decide when to use which and for what purpose.

By separating Private and Public, we can make an explicit requirement for Public files to be “immutable” - that is, to never change. Once something has been made public, it is forever unchanged, thereby guaranteeing that once a combination of assets have found to work well together, this harmony is never broken. An important aspect when projects scale.

The Private branch contains a Users working directory, followed by a directory per Application used.

Within any given asset, a user is given his own unique working environment. It is within this environment that an artist produces files, and is welcome to do so following any convention of his choosing. This includes naming and directory layout. No part of the pipeline may depend on what goes on within a users working directory.

The rationale for embedding application directories into a User directory is that each application has its own internal layout representing the data it manages. For example, Maya may produce “scenes” and “caches”, whereas Nuke produces “scripts” and “images”.

The benefit of this giving a user complete freedom in the management of his own files is complete utilisation of a workflow he is already comfortable with, and alleviate the need for conformity in this particular aspect. Instead, conformity is strictly enforced in the Public space, which is where files are ultimately validated and shared.

Master

At Mindbender, there is a concept of Master. That is, a version that never stays the same, but is always updated to reflect the latest change of any asset. This concept enables updates to happen transparently across any number of asset combinations; such as a shot receiving an updated model for rendering. It does however mean that the state of any given combination can never be guaranteed and introduce brittleness and uncertainty into the system.

Due to the scale of projects at Mindbender, this concept is relatively safe and the savings currently outnumber the cost of keeping it in. So what will happen is a dual system, where assets are published into immutable versions and at the same time update a single Master version. We may also want to explore the possibility of enabling the Master version to be dynamically replaced by immutable versions at will, by for example making it into a Junction and retargeting it to any given version. But ultimately a transition is recommended, as it is expected that Mindbender will continue to grow and take on more complex projects in the future.

Subset

In the simplest case, a working scene represents the asset and is versioned as a whole. This includes assets such as a character model or rig. The version of a given model may be incremented by considering the totality of a working scene at an improved state.

However, this view breaks rapidly when considering more complex assets - such as a shot.

When working on a shot, not only does your scene consists of many disparate outputs - such as caches from three different characters and a camera - but also of individual assets that were themselves once considered assets. This is where Subsetcomes in. A Subset, as the name suggests, is some part or parts of a working scene that itself is considered and asset.

For example, the three characters and camera are each considered a unique asset that is versioned independently from the other.

shot01:
  - Cat01
  - Cat02
  - Camera01
  - Truck01

The same then applies to traditional assets.

Greta:
  - animRig
  - simRig
  - furRig
  - model
  - texture

Filesystem API Conclusion

Although many concepts are introduced here, it is important to realise that none of these concepts are new. You have been working with them - either knowingly or unknowingly - throughout your entire career. These are global concepts that apply to all content creation in film and commercials. The exact names may differ across studios, but their meaning is global and ultimately a consequence of human nature.

As as side note, I’d also like to point out that as far as the pipeline is concerned, there is no difference between Greta and shot01. They are both considered as Assets, meaning the term Shot is primarily for your own comfort and for use in conversation with your peers.

Filesystem UI

To simplify filesystem management, we implemented a minimal TUI, or Terminal User Interface.

The TUI acts as a gateway through which every artist specifies what he is about to do. The decision is then recorded as “environment variables” that the publishing mechanism can later use. The TUI is developed using Windows cmd.exe scripts - known as “.bat” scripts - and serves two purposes.

  1. Create and navigate directory structures
  2. Record those choices

These two mechanisms work in tandem to guide the user through available choices and produce a uniform directory structure without manual intervention. Choices are exposed as files and the user is invisibly navigated to a directory in which available options are laid out.

For example, upon launching the TUI main interface - mb.bat - the user is navigated to the projects directory, m:\f03_projects [1]. This folder then contains available projects, each represented as .bat files themselves.

[1] In reality, due to backwards compatibility with the existing system, the actual folder is m:\f04_assets\include\pyblish\bin but is expected to transition into a more logical place as time passes.

The TUI is a first step towards a graphical user interface of the same purpose that is quicker to iterate with little to no cost in productivity.

Launching mb.bat presents the user with a landing screen.

MINDBENDER --------------------

  :: Some nice graphics ::

  Welcome marcus!

  1. Enter the first characters of any project
  2. Press [TAB] one or more times to cycle through available matches

$

In full, the TUI consists of 3 levels.

  1. Start
  2. Project
  3. Asset

In the Start page, a user is expected to enter a given project. If the project does not yet exist, it will be created, alongside a suitable directly layout. The pipeline TD may control what is created by editing the corresponding .bat file. Once entering a project, the user is expected to enter an asset. At the moment, a few example assets are provided to help guide the user in terms of syntax.

p999_Meindbender_Sync ---

  Which asset would you like to work on?

  For example:
    $ Greta
    $ BlueVehicle
    $ shot01

$

It is the intention that instead of examples, actual available assets are drawn here to help guide the user in making the right choice. Further down the line, this is also where a “Recent” category may appear, to streamline the effort of entering common assets. Ultimately, the TUI is expected to transition into a graphical user interface, or GUI, in which the options and choices are made graphically.

Once a user has chosen an asset to work on, only one thing remains - launching an application.

It is important to realise that this approach is one of many and that it was based on a few critical factors.

  1. The studio has had no prior exposure to an established pipeline.
  2. The one pipeline engineer does not have a formal education in software engineering
  3. The studio is running Windows exclusively
  4. The studio collaborates with freelancers across the globe

Collaboration

Mindbender is a global studio. They work with artist not only locally but also remotely. Because the artist is remote, they have little or no ability to control the environment in which they work. This can be problematic, not only in terms of ensuring they use the same software and versions of software, but primarily in ensuring their infrastructure is compatible.

Given a local development environment, there are three ways in which to bring a remote worker into a local pipeline.

  1. “Install what we have”
  2. “Working in the cloud”
  3. “Use this”
1. “Install what we have” - Share Software

Likely most intuitive solution is to tell the remote user that “We are using Maya, and here are some of our in-house software you will need”. With this information, a remote user can establish an environment on their local machine that mimics the one at Mindbender.

It does however have a few downsides.

  1. Setup complexity increases with the number of software packages required to be installed, including pipeline related tools.
  2. A user may not have control over all aspects, such as which OS or version of an OS is used at Mindbender.

As an example of (1), Pyblish requires Python, PyQt5 and the installation of Pyblish itself. Setting this up on any machine involves some amount of work.

2. “Working in the cloud” - Share Workflow

A recent addition and intriguing mind experiment.

What if everyone works remotely? Even local workers? This way there is no separation between those working locally at Mindbender and those working remotely, resulting in a unified experience for all. One method of achieving this is by connecting your screen to a remote computer in “the cloud”. To a common series of server where anyone can connect and work as though they were within the same space.

This too however comes at a cost.

  1. Performance. With (1), software runs locally and utilises the full extent of performance available in the running machine.
  2. Down-time. Connections break all the time. When two studios are connected to a common server, chances of failure are three times as high. If connection breaks in your office, work ends. If connection breaks at their office, work ends. If connection breaks at the server, all work ends.
3. “Use This” - Share Environment

What if there was a way to combine the benefits of bare metal performance with those of a uniform development environment?

In the past few years, virtual machines have flourished. From being emulated at 100x the performance cost, abstractions within the hardware itself enable near transparent emulation of nearly any operating system and underlying hardware, at near zero performance cost.

This means Mindbender would be able to provision an entire operating system, pre-installed with relevant software, pipeline, security and analytic measures that any freelances boots up as though it were a local machine sitting at Mindbender.

The cost? Less than 5% drop in performance and a one-off gigabyte sized transfer of the disk image. An artist would be up and running with an known environment, including software, drivers and infrastructure, in less than 30 minutes.

Virtualisation software - VirtualBox - is free and works on Windows, OSX and Linux. OS is free - CentOS. Additionally, there is the possibility of producing a single executable installer that each remote worker runs. The installer would (1) setup VirtualBox, (2) install the disk image and (3) provide a desktop shortcut which would log them into the virtual machine. From there, it would be as though they sat down at Mindbender and logged into a computer.

What they would need is an internet connection - for the Maya license server running at Mindbender - and optional VPN for files. Each of which could be pre-configured to make appropriate connections without the remote user having to configure anything.

Week 2

This week is about iterating on what we’ve accomplished in week 1.

We need to prove to ourselves that..

  1. The directory layout works
  2. The TUI works
  3. There is a clear path for use remotely

Once that is done, we can start looking into specifics.

  1. How are assets published?
  2. How does another artist pick it up?
  3. Where do things typically go wrong?
  4. How do we write validations for it?
  5. How do we publish shots?
  6. How are shots picked up?
  7. How can we automate putting a shot together?

Alongside this, we will have a look at what is missing from the current Creator and Loader GUI, as well as look into how a Builder GUI could look like, and what to expect from it.

This should cover a full week, but in case there is spare time, let’s also look into setting up a Virtual Machine and testing this out locally, pretending as though we were remote.

Any concerns or suggestions are welcome at this point. I expect this document to include most of what we covered during week 1, but to gloss over certain details. These details will be documented in full once we’ve established something we are all happy with.

Any questions, let me know!

Best,
Marcus