Overview

 

This comprehensive system is an ongoing project that I am designing and building as a part of a collaborative class between Visual Effects, Animation, and Film classes. Together, these classes will produce 2 short films so I have been tasked with the laying out the pipeline architecture for both films.

 

This tool is being designed with other projects in mind, so that it can scale appropriately from large group films to smaller senior studio films.

 

Checkout the Github repository here.

 

The main idea is to have a sort of "database" that keeps track of a plethora of objects representing any number of shows, sequences, shots, and elements. Elements are the core objects of the database that represent what artists actually work on, from props to cameras to effects.

 

Helix

Project Manager (On going WIP)

Database

 

The database is stored as a JSON format, and is serialized through custom encoding and decoding functions for each DatabaseObject. Each item that is stored in the JSON file (Show, Sequence, etc.) extends DatabaseObject.

 

When the objects are read from the JSON format and deserialized, specific "tables" are made to make future lookups faster. This involves just rearranging how the data comes in into a dictionary that is designed such that common look ups will be keys.

 

Usage

 

Currently, the system is entirely command-line based in the interest of speeding up the initial setup time. Once this basic groundwork is laid, an artist friendly UI will be built so elements can be navigated, retrieved, and created faster.

 

When the user first initializes the Helix system, they must "pop" into a show, which sets any number of environment variables that is established in the show's configuration file. From there, the user can make new elements, or get elements from the database to continue working on. Again, proper variables are set to ensure their files are saved in the write location and that any assets they need for this specific element are available to them.

 

Once an element has been retrieved, it is primed to be worked on, and other commands are now available for the element context. Users can publish via "pub", create an override for the element in a sequence/shot, rollback to a different version, remove the element, or modify its database properties.

 

PERMISSIONS

 

Given the amount of commands that have potentially harmful results to the database structure and the work of other users, I have implemented a basic permissions system. Permissions can be defined by the system administrator in the global config file found at $HELIX_CONFIG. Here is an example showing how various groups for permissions can be setup:

 

[Permissions]
# Super user
admin = ['*']
adminusers = ['souell20']

# Default group everyone is in
defaultgroup = ['pop', 'mke', 'get', 'pub', 'pwe', 'els', 'elements', 'shots', 'seqs', 'sequences', 'shows', 'help', 'h', '?']

# TD can remove elements
td = ['pop', 'mke', 'get', 'mod', 'pub', 'pwe', 'rme', 'els', 'elements', 'shots', 'seqs', 'sequences', 'shows', 'help', 'h', '?']

Under the [Permissions] header any number of groups can be defined. The syntax of <groupName> and <groupName>users must be followed. The list following <groupName> is the list of commands this group can performs, and the "users" list is self-explanatory. Any user in the system not explicitly defined in a group is assumed to be in "defaultgroup."

 

Publishing

 

The system makes a distinction between 2 trees of directories - one working and one release. The working directories contain files named however the user sees fit for their individual workflow. Once the user is ready to publish their asset/element, the file that is named accordingly gets moved over to the release directory structure. Files in the release directory structure are what other artists use and depend on for their own assets - hence why the naming is important only at this instance.

 

The publishing system is "versionless," meaning that the published asset that gets copied over to the release directory is renamed with a version tag (i.e. myAsset.v0001.abc) but gets placed in .versions folder. Alongside the .versions directory is a file called myAsset.abc, which is merely a link to the recently published file that was placed in the .versions directory. This allows others artists to always reference the top level "versionless" file in their setups, and when new updates are published they automatically get them without changing to a new version. See figure below.