The integration of cloud rendering resources into a CG studio not only introduces a change in how rendering resources are managed but also a cultural change in how the rendering process is approached.
Conductor’s turnkey approach to cloud rendering is well suited to help manage this change, providing tools and metrics to ensure the integration is successful on all fronts.
In this post we’ll take a look at how Production Managers can manage and monitor their studio’s Conductor usage all from within ShotGrid.
This post intentionally glosses over the implementation details as it’s primarily targeted at Production. The data is populated by a script running at a regular interval that queries the data from Conductor and pushes it into ShotGrid. A follow-up post will be aimed at developers, focusing on the implementation details. It will include code samples to help Conductor and ShotGrid customers get up and running quickly.
The Cultural Shift
In studios with exclusively on-prem render farms, there are often a few degrees of separation between Production and management of the render farm. There’s recognition that the render farm is a key resource required for the completion of a project and that its contention could lead to delays. Day-to-day management of the render farm tends to be a partnership between the technology and CG teams.
With on-prem render farms, resources are limited. The capacity of a render farm directly impacts a project’s schedule. The dollar cost tends to be indirect (how often does production try and track the actual dollar cost of a on-prem render?).
What if render farm resources are unlimited? The direct result is that rendering ceases to negatively impact a project’s schedule; there will always be some other limiting factor (headcount, creative decisions, etc…).
With this newfound render ability comes the need to monitor cost. This is the critical metric of cloud computing.
Taking a step back, with an on-prem render farm, the responsibility to push out a render on schedule largely falls on the artist. They need to make wise decisions about their scene in order to get the results in time for reviews, etc… cranking-up render settings and extending render times does nobody any favors - least of all them.
When switching to cloud rendering, artists tend to lose the incentive to self-regulate their render times. Obfuscated to the dollar cost, they can increase render times with little impact to themselves or fellow artists (as hundreds or even thousands of frames can run in parallel with little waiting for the job to start).
On the flip side, Production becomes keenly interested in every minute spent rendering as it’s now included as a discreet line-item in their budget.
Conductor was designed from its inception to ease the cultural shift that occurs when making a finite resource infinite.
With Conductor’s cost monitoring, cost limits and pricing model, studios can deploy cloud rendering with confidence.
In this post, we’ll dive into how Production can monitor, in detail, a project’s rendering cost without ever having to navigate away from their base in ShotGrid.
Conductor’s Pricing Model
Before diving into how to view costs in ShotGrid, it’s imperative to understand Conductor’s pricing model.
Conductor has two charges: compute and storage.
Compute is the cost of doing work and is billed per second. This is an aggregation of machine time, license time and the Conductor fee. If a render takes 45 minutes and 3 seconds to complete, those three components will be added up for that running time.
Storage is the cost of Conductor hosting all the files required by jobs and the resulting files. This is calculated daily and tends to be minimal relative to the compute cost. Unlike compute, storage is not associated with a particular job or project - it is account-based.
Other than these two charges, there are no other fees charged by Conductor; no monthly fee, no per-user fee, no bandwidth fee. This simplified pricing model ensures there are no surprises.
Conductor and ShotGrid
Jobs submitted to Conductor can be associated with specific Shots, Tasks, Assets or any other Entity in ShotGrid.
When those jobs run, the cost of those specific jobs can be queried and placed into a custom field within the appropriate ShotGrid entity.
In our examples, we’ll associate Conductor jobs with ShotGrid Tasks. This granular approach will capture a lot of data that’s useful for budget analysis.
In the screenshot below, there are two highlighted columns (they’re highlighted only for visibility purposes). The first column shows the accumulated cost for all Conductor jobs associated with a specific Task. The second column displays the number of jobs submitted to Conductor for that Task (which can be helpful for the context of the cost column).
Note how the cost for a particular shot is summed.
The bubbling up of cost data can go right to the project level. In the screenshot below, a pie chart was added to the Project Overview. This pie chart gives a very handful summary of total project spend on Conductor as well bring broken down by department.
Conclusion
Migrating to Conductor as a cloud rendering solution empowers Production to monitor and control costs. Gone are the days of clicking around a developer-focused dashboard, hunting for hidden costs associated with technical jargon and trying to monitor your spend that doesn’t end up matching your bill.
Deploying Conductor allows studios to shine a light on the hidden (but very real) costs of production. It results in more accurate bids and an increased ability to allocate resources.
Conductor is a natural fit with ShotGrid. Cost details can be queried, aggregated and displayed, allowing the render budget to be monitored alongside all the other necessary tasks to complete a project.