Week 6

Hi team,

This week has been about building and installing the next iteration of the application launcher, mb.bat, aptly called “Launcher”.

Table of contents

• Overview
• Goal
• Executable & Environment
• Directories
• Metadata
• Limitations
• Videos
• Next Week

Documentation

• Inventory API
• Configuration API
• Executable API

Overview

mb.bat is built on-top of the Windows cmd.exe and manages a few distinct things.

1. Calling the right application executable
2. Directory navigation and creation
3. Environment variables
4. Asset metadata, such as the framerate of a project

Most of these come for free; such as calling of executables, directory management and managing of the environment. This is what cmd.exe does natively so riding on top of that wave has thus far been a breeze.

The cost of this convenience however is the fact that neither of these can be used independently. For example, there is currently no manner in which we can create just the directory layout or launch just the application. They all happen together or not at all.

In practice, it means we can’t for example ask about the length of a shot without also launching an application.

But perhaps most importantly, the information managed via .bat files was unusable by anything other than cmd.exe. Such as a graphical user interface.

Goal

For the launcher to take the form of a graphical user interface and to run on platforms other than Windows, we must step away from cmd.exe and stepping away from cmd.exe means re-building many of the conveniences it initially gave us.

This is the separation I’m looking to make with the Launcher.

Executable & Environment

With mb.bat, information about the executable run for a given project is embedded into the subsequent .bat files you enter, such as maya.

maya.bat

:: Launch (local) Maya
echo Launching Maya @ %MINDBENDER_WORKDIR%..
start "Maya" "c:\program files\autodesk\maya2016\bin\maya.exe" -proj %MINDBENDER_WORKDIR% %*

Furthermore, this .bat file is distributed along with the core pipeline, effectively limiting use of the pipeline on any operating system other than Windows.

In order to eliminate this dependency, application specific properties had to be made independent of the operating system.

Namely..

• Directory name, e.g. /maya
• Directories, e.g. /scenes, /images
• Environment, e.g. PYTHONPATH
• Files, e.g. workspace.mel

Additionally, these properties had to be made editable by a non-technical supervisor.

So I put together a file format capable of facilitating these requirements in the form of a YAML document.

schema: mindbender-core:application-1.0

label: "Autodesk Maya 2016x64"
description: ""
application_dir: "maya"
executable: "maya2016"

default_dirs:
    - scenes
    - data
    - renderData/shaders
    - images

environment:
    # Shorten time to boot
    MAYA_DISABLE_CIP: "Yes"
    MAYA_DISABLE_CER: "Yes"

    # Disable the AdSSO process
    MAYA_DISABLE_CLIC_IPM: "Yes"

    PYTHONPATH: [
        "{PYBLISH_MAYA}/pyblish_maya/pythonpath",
        "{MINDBENDER_CORE}/mindbender/maya/pythonpath",
        "{PYTHONPATH}",
    ]

arguments: ["-proj", "{MINDBENDER_WORKDIR}"]

copy:
    "{MINDBENDER_CORE}/res/workspace.mel": "workspace.mel"

The Launcher may then (1) read this file and (2) adapt it to the currently running operating system.

Directories

Previously, project and asset directories were managed by .bat files. Calling upon one file created a corresponding directory, such as MyAsset and finally MyAsset/work/mytask/maya.

In order to enable support a graphical user interface along with more operating systems, a new file format was introduced called Inventory.

.inventory.yml

schema: mindbender-core:inventory-1.0

assets:
  Bruce:
  Batman:
  Camera:

film:
  sh010:
  sh020:
  smoke:
  filler:

The file determines the what assets are available within a given project. The supervisor then gains a high-level view of each project and can make large customisations from a single location.

Tasks and applications were split into a separate configuration file.

.config.yml

schema: mindbender-core:config-1.0

apps:
  - name: maya2016
  - name: nuke10

tasks:
  - name: animation
  - name: modeling
  - name: rigging
  - name: lookdev

template:
    work: "{projectpath}/{silo}/{asset}/work/{task}/{user}/{app}"
    publish: "{projectpath}/{silo}/{asset}/publish/{subset}/{version}/{subset}.{representation}"

With these files, projects may be browsed without direct access to the file-system, which will become important as both the Launcher and Loader begins to work with files that aren’t necessarily available via the local computer, such as for freelancers.

Metadata

Previously, additional information about project and asset were defined in the .bat files and passed into the environment upon launching the application.

set MINDBENDER_FPS=25
set MINDBENDER_RESOLUTION_WIDTH=1920
set MINDBENDER_RESOLUTION_HEIGHT=1080

This enabled customisation via simple, editable text files with a relatively straightforward syntax, along with use of these variables in the application of our choice.

It did however make it challenging to use in a graphical user interface and to gain access to metadata from a project or asset that we weren’t currently working on, along with of course the inability of using it on anything but Windows.

To cope with these new requirements, metadata may be added to the corresponding .config.yml and .inventory.yml files of a given project.

.inventory.yml

assets:
  Bruce:
      label: Bruce Wayne
      group: Character
      icon: cutlery
  Batman:
      group: Character

.config.yml

metadata:
  label: The Hulk
  fps: 25
  resolution_width: 1920
  resolution_height: 1080

Limitations

1. Sensitive configuration files
   • A simple syntax error in one of the configuration files throws off the whole system and prevents any further applications from being launched for anyone. This is a severe limitation and one that will need proper care and support.
2. Little to no dynamic metadata
   • Projects are defined but also define themselves in some ways. For example, they have a deadline, a particular number of tasks that need completing at a particular rate along with personnel capable of accomplishing tasks at a certain rate. This data is implicitly generated throughout production, but there is no mechanism to capture it and the configuration files are one-way sources of information. They do now update on their own.
3. Dependency management
   • Perhaps the most severe limitation is that of facilitating combinations various dependencies. At the moment, this isn’t a problem as every project uses the exact same version of everything. But it is likely to grow into a problem as we upgrade from e.g. one Maya to another and the plug-ins associated with it. For this I expect us to look into Ecosystem or Rez though would like to avoid it for as long as possible due to the added complexity.

Videos

Here are the videos I’ve shared with you throughout the week.

Next Week

Next week I begin work on the next iteration of the Loader, with increased performance and amount of data visualised thanks for the advances in the Launcher.