Week 13

Hi team,

This week has been about getting Colorbleed up to speed with where we are and vice versa, merging the pipelines of Colorbleed and Mindbender and aim to deploy an identical pipeline in both of our studios by the end of next week.

But first, let’s talk about Paperspace.

Table of contents

• Paperspace
• Identical Pipelines
• Configuration
• Progress
  • Project Manager
  • Loader
• Next Week

Paperspace

VERDICT Failed

It’s been two weeks since we decided to give Paperspace a try, it failed to live up to our requirements, especially with regards to the visual latency between user input and cloud response.

So now I’d like to ask each of you to take a moment to run through this questionaire so that we may record our experience over the past two weeks and communicate to our future selves when, if ever, we should return down this road and try Paperspace - or anything like it - again.

1. Questions
2. Responses

It’s important you take the 5 minutes to fill this in, else the joy and frustrations of these past two weeks will fade into oblivion, meaning we’d have to repeat this experience which is wasteful to us all.

In 6-12 months we’ll return to these answers, evaluate where we are at and determine whether or not to try pursuing this goal again. Development till then will assume work takes place locally, no cloud involved.

Previous talk

• Overview in Week 9
• Performance in Week 10

Up to speed

Roughly a year ago, I traveled to the Colorbleed office in Utrecht, Netherlands to deploy a pipeline similar to what you were given in January this year. A barebone yet scalable layout and organisation of artist workflow and developer source code.

Since then, Roy has made great progress in building upon this foundation and establish a quite a few surrounding tools in response to local production requirements, some of them we will likely introduce at Mindbender as well, as we are ultimately facing very similar challenges and we’re all just people.

Today, the overall pipeline philosophy at Colorbleed remains the same and because of the shared views with Mindbender a merge is expected to introduce minimal friction and change. Apart from both of us getting some much needed updates to the aspects where either of us has gotten further.

Identical Pipelines

One of the major changes made to the layout of code in the pipeline was the separation of (1) configuration and (2) function. Configuration constitutes everything that makes Mindbender Mindbender, including naming convention and directory layout, but also what kind of assets there are and how they should be formatted (and hence tested). Function on the other hand is what Colorbleed and Mindbender have in common.

Both of us (1) create, (2) publish and (3) load assets in some manner or form. The how of each of these things differ, and that’s where the configuration comes in.

Configuration

One of the design goals of the Mindbender Pipeline is to facilitate use by others.

Doing so enables contributions from and collaborations to be had with others, which is a win-win for everyone involved. It means (1) more production testing, (2) greater development resources and (3) a need to communicate and discuss design choices with others.

At this point, the project is split into two parts.

1. Function @ mindbender/core
2. Configuration @ mindbender/config

The configuration consists of all the things that separate Mindbender from Colorbleed, such as what assets there are, how these are validated and where on disk they are put. Whereas the core contains the creator, loader and manager user interfaces along with their corresponding programming APIs.

Polly

During the transition, and until deployment by end of next week, I’ve split our Maya menu items into two menus - one shared by us and Colorbleed, and one for Mindbender.

Polly houses the previous submenu items, for Animation and Rigging, whereas Mindbender provides access to the various GUIs and general pipeline related things, including publishing which was moved from here from the File menu.

The idea moving forwards is for Polly to remain what makes Mindbender unique and to enable others to produce their own configuration for their specific use cases. In this case, Colorbleed is to develop a configuration that encapsulates their workflow, MetaPipe does one for themselves and the same goes for additional production house interested in taking advantage of the core functionality of this pipeline.

In time, I expect there to be many configurations, but only one core. This is where the combined effort of all of those involved can start to show their colors, with more and more common functionality being identified on a per studio and production basis, and where there is room to scale this pipeline to eventually take on those in well established environments, such as Framestore and Imageworks, who may one day be users of and collaborators to this project.

Progress

One of the first things encountered by Colorbleed was the need to create a project. At Mindbender so far, I’ve been setting this up for you and so the workflow and interface with which you interact with projects are the least refined.

Project Manager

So Roy set out to port his existing Project Manager to reading and writing to the database and here’s what it looks like today.

Create Asset

Create Task

Browse and create Silos

Loader

In addition, Roy made good progress on porting his much more pleasantly designed asset Loader, which looks like this.

Next Week

Apart from deploying this merge by Friday, which you can already get a taste of if you try mb-gui-mottosso.bat which I’ve updated to reflect the current latest version of the pipeline (expect bugs), my efforts next week will be spent on iterating on our documentation with the intent of aligning the views of those involved - Colorbleed, MetaPipe and Alex - and lay the groundwork for future collaboration ahead.

There is no task more important than having everyone work towards the same goal and no effort more wasteful than pulling in opposite directions.

Most of this work will not be visible or relevant to you as artist, but will make itself known in more efficient and well orchestrated development. You will however be noticing an updated documentation section, which I have been referring to briefly so far and will be referring to more often in the future - both for direct issues such as how to create projects, but also embedded in the tools you use and the messages it gives you. Expect documentation to play a larger role in your everyday lives than what it does at the moment.

Finally, here’s what I’m aiming for in terms of design.

See you next week!

Best, Marcus