One of the ways in which Mango facilitates the understanding of how people work and collaborate with each other, is by introducing the concept of "resources" and "resource types".
resources are the different files that are made by the pipeline(or artist in the pipeline) and handed off between different pipeline steps. One of the key designs ideas of mango is to categorize and label the different kind of resources that are created in production to better understand the following questions...
- What is the main purpose of the resource?
- What step of the pipeline is best suited to create this resource?
- How is this resource used by artist and producers (The Pipeline)?
- How do we ingest this resource into different steps of the pipeline efficiently?
- How do we keep every instance of this resource used through out the pipeline up to date?
this is illustrated in the following graph. (right click on the image and choose "view image" to see a larger version)
In this graph, we illustrate the relationship between different "resource types" in the lighting to composting pipeline. in this snippet of the pipeline the following 4 types of resources are used
- 3d Elements
in this scenario, work-files mostly deal with application specific files (.max, .ma, .mb, .nk). it is important to understand that in the mango pipeline "work files" in their entirety are not designed to be handed of to the next pipeline step (dough they certainly can be). instead the goal is to have a modular system, where the artist can build "work file" with everything that they need to get the job done, but only hand off the smaller chunk of work that his responsible for via the publish process. the next person in the pipe then collects all the available resources, built by the people before him/her, and and assembles a complete file that is then used to generate new or updated resources.
In this example the lighter makes a "work file" where he/she will load or create all the resources that he need to create the "3dElements" (image sequences) that will be assembled by the comp artist.
the roto paint artist will make a "work file" where he/she will paint out markers from a plate and render this clean "paint" elements so they can be used by the compositor
the compositor will make a work file in which he will composite all the 3dElements, Paint, and PreComp images sequences and render a final comp.
in this workflow, no artist really cares or needs an other artist's "work file". They only need to get the resources created by "work files".
in the case of the other 3 resource types used (3dElements, preComp, paint, comp) they all share one thing in common, they are all images sequences. But just having a resource type called "image sequence" doesn't tells enough about how this resource is to be used in our pipeline. By breaking it down into the the following different types, it becomes more clear as what the purpose of each image sequence is meant to do, and how it is supposed to be used by the next step in the pipeline.Why not have different resource types for each application?
the reason why all this different software formats are grouped together as one resource type is because they have a very particular purpose, and that is to create other resources. no other resources in our pipeline has the ability to create new resources other than work files. so we give them they own special category.
it it possible what so ever, that this file types will be used by future resource types, in wich this files will be used to hand over data needed for some step of the pipeline, but in this case the files would never be opened and worked on.
it's also important to note, that by making the work-file resource type generic. we can more rapidly add new software package to the pipeline... seance of all the tools dealing with work-files won't have to be updated to account for a new resource type.
with that said Mango does track what application made the work file. and as to stream line the process of finding workfiles that belong to a particular software.Unique Storage location per resource type
one of the benefits of splitting resources into this "purpose descriptive" types, Is that it allows us to split the storage across multiple drives or servers, An example of this can be storing all image sequences of type 3dElements on drive x:, while storing all images sequence of type comp in Y:. A studio has the option of using as many different storage server as there are resource types.
One of the main benefits of building a pipeline with the concept of resource and resource types, centered around the idea of "Work files" that out put axillary "resources", is that growing the pipeline to cover new techniques and technology becomes much easier, by simply introducing new resource types, and rules that govern how this new resource is going to be handed off.
this means additions can be made to the pipeline with our affecting any all-ready existing methods and practices. or having to re-engineered major parts of code to account for new on though of practices.