Week 12
June 11, 2017
Hi team,
This week has been about (1) trailing ftrack, (2) testing Paperspace and (3) on-boarding the team I’ve been putting together to help make this pipeline best in class. To this date I’m in conversations with Colorbleed, MetaPipe and Alexander Richter. The goal is to accelerate and future-proof development as well as extend the horizon of what is possible.
| Collaborator | Notes | Strengths |
|---|---|---|
| Colorbleed | Getting Roy up to speed with where we are and vice versa, he’s has built a number of excellent tools that we should be able to benefit from as-is. |
|
| MetaPipe | Keen to join and have similar goals and experiences as I, working with them would enable us to benefit from their expertise in rendering, farm set-up and cloud infrastructure. |
|
| Alexander | Yesterday I had a chat with Alexander Richter, the author of another open source pipeline project Plex about joining forces and working towards a common goal. He's got a number of really good ideas and experience in presentation and public speaking. |
|
Strengths are first-impressions and intended to change as I get a better sense of background, experience and preference of everyone involved.
Table of Contents
ftrack
Things are looking sharp and the communication between your current pipeline and ftrack is straightforward - ftrack will take on the responsibility managing users, their tasks and schedules.
Alan spoke of a good candidate for first production use last week that I’m aiming to see in there next week, at that point I’ll be able to have data sent to ftrack as we publish, and read from ftrack as we create and assign tasks. I’m thinking publishes will take the form of playblasts that we can review and for tasks to become visible to you via the Launcher.
Paperspace
I spun up 12 new machines with Quadro M4000 GPUs and off we went. We’re three days into testing, and are expecting to keep testing for another 11 days for two weeks total.
Aside from the benefits listed in week 10, we experienced a significant latency for users in the Sao Paolo region and barable latency in Sweden.
Another thing was user management.
- Each user is assigned a unique machine, but the username in each machine is Paperspace which complicates setting permissions and managing individual user directories on a shared drive.
- The Google Sign-in was pre-configured for ease of use, but having multiple users on the same log-in didn’t quite jive with Google which means Email, Slack and most importantly Google File Stream required manual intervention.
Google File Stream enables direct read and write to Google Drive within which we are able to host our internal NAS during the transition onto the cloud, after the plan is to use the cloud-provided NAS of 8x the performance. But since the user account got disconnected, so did the drive which disable write-access for the Launcher and thus no tasks to be started.
The set-up was complex enough to stir up trouble even for the most technical amongst us, so I had a look at “Team Drive”; a Google Drive “NAS” in which the share could be set-up once and mounted via Google File Stream as-is and viola, individual access, with administrator permission control per user and no set-up required.
We finally managed to move our Google domain name from mindbender.se to mindbender.com as well, but that meant we lost access to our early-access account to Google File Stream which meant no more access to this until a new account is granted.
So what will happen is that I, or someone capable (looking at you Peter!) set’s up a plain old Google Drive on the cloud NAS, Z:\. At that point, all should be working normally apart from the occasional synchronisation issues of duplicate files and such.
Collaborative Document
In order to identify and balance goals and jargon amongst each of us involved, I’ve put together a shared document in which we define our target audience, ideas and roles. The goal of this document is for us all to find a common ground upon which we can build the final product.
The document will also serve as a reference to future developers joining at a later stage, for them to understand our initial reasoning and goals.
Priorities
This week I also introduced the notion of priorities, which is how (1) I will reflect what I’m currently busy and how (2) you can indicate what you find most important. This also means that if you think something is important but it isn’t on that list, it will most likely not happen in time. This way participation is both encouraged and lack of it punished, fairly. :)
Feature Roadmap
In addition to onboarding, me and Calle have plotted the course ahead in the form of more specifications on GitHub, below are some highlights.
| Goal | Description |
|---|---|
| Workareas | A method of working locally, but remain within the confines of the pipeline |
| Diff | Compare a previous version with current state to gain an understanding of what changed. |
| MPAA Content Security Program | Gain an understanding of what security means for the MPAA and how we can avoid heading into areas we cannot use in a secure environment. |
| Database Statistics in Launcher | Disperse hidden performance bottlenecks by visualising what is happening in the database and on disk. |
| Visualise Project Status | Expose change dates to our documentation so as to avoid the trap of reading out-of-date material. |
| Installation Manager | Simplify end-user installation and keeping up to date. |
| Visualise Asset Status | Via ftrack, we can now take into account high-level aspects of production, such as when an asset is finished or ready to start. |
| Visualise Task | We can also provide shortcuts and information on what task a given artist is involved in, directly in the Launcher. |
| Organising the loader | Introduce tabs, a sense of hierarchy, search and filtering into the Loader |
| Externalise Configuration | In order for more studios to take advantage of this pipeline, I'll be separating what makes it special to us into a dedicated project such that others can install their own configurations into it. |
| Optimize Alembic export | Publishing animation caches currently does not disable refresh on the viewport automatically, resulting on unnecessarily long publish times. |
| Animation Validations | Better fool-proof the output from animators. |
| Rigging validations | Better fool-proof the output from riggers |
| Visualise Relationships of Assets | I found an open source project to draw interactive graphs, I'll be looking into using this to help us visualise relationships between the assets we produce. |
| Visualise Members on Create | Roy had an idea on how to better manage what goes into an instance on publish time. |
| Creator Plug-ins | As part of the configuration externalisation process, these studio-specific items are currently embedded into the core pipeline and must be separated. |
| Multi-update | As of last week, we are able to publish into multiple assets at a time, now all we need is the ability to update multiple assets at a time. |
| Tag and search assets | As we gain more metadata about assets, we'll be able to search more effectively amongst them. For example by arbitrary tags, such as "lowpoly" or "hero" |
| Last accessed statistics | More metadata about when assets are used, where and by whom will help us keep disk space usage as efficient as possible and not lose data we care about. |
Next Week
I’m very excited for you to get ftrack set-up for use in production and do more work in Paperspace so we can either make the transition as soon as possible, or decide not to at which point I will return to implementing safe synchronisation for all.
While this is happening, I’ll be continuing to onboard additional pipeline developers in the hope that time lost now is regained once we’re all up to speed. I expect a merge to happen with Colorbleed, which should provide a number of additional features for us, including better Loader organisation, project management and Manager features. They’ve got some ideas on set dressing as well that we can hopefully all benefit from.
To be continued!
Best, Marcus