This is a resume, loosely resumed and poorly translated by me, and with my own comments in italics.
Luisma´s comments are from the point of view of a mere user, as he is not a programmer nor an expert. Also he is considering a type of production with several departments that will be exchanging or sharing assets most of the time, both internally and among departments, each using its own programs and tools, so it is a rather heterogeneus system.
An efficient pipeline will be mainly based on keeping an strict discipline regarding name conventions (nomenclature).
This will make easier for everybody to:
1.- Find assets to work with.
2.- Keep track of the versions of each asset.
3.- To check and send assets along the pipeline to the next department.
4.- Facilitate writing scripts and programs that work with assets.
This is mere common sense. Now lets go down to the practical side of it:
This is the list of "digital" departments ("non-digital" would be Art Direction, Concepts, Storyboard, Sets and Shooting, etc) that we can find in a medium-big production, sorted in chronological order along the pipeline:
- Previs - Visualizes the directors´s idea
- Modelling - Creates models
- Creatures - Rigs the model
- Cameras and Layout - Places the model on the scenery and frames it with a camera
- Animation - Animates the model (normally a low-res version). Once approved, the animation will be "published" and passed onto a hi-res model.
- Texturing - Creates textures
- Matte Painting
- Shaders - Creates shaders
- Lighting (& FX?) - Applies Textures and shaders to the hi-res model, and lights the shot according to its visual characteristics, and rendering the appropiate passes
- Compositing and colour grading - Finalize the shot mixing the rendered passes
The best way to organize this huge amount of information is through a unique Project directory, with several main subdirectories for reference and query, that allow for continuus access:
And then two "working" subdirectories:
/Assets: All the elements (characters, props, sceneries) with its corresponding revisions, kept up-to-date and related to other assets. For instance:
/Shots: All the production shots (/P01, /P02.. /Pxx) with subfolders for each dpt(/Models, /Anim, etc), for instance in Anim, several folders pointing to the "Assets" subfolder containing the needed assets: ( EDLs, models, cameras, audio, rigs, etc)
A Pipeline Script would assemble all that into a 3D scene for the program used in animation.
An aditional folder at that level is /Work, where the output work is saved into three folders (/Initial /Progress /Final) with the adequate versioning nomenclature: Pxx_CharacterA_lowres_v05_NA_ipxx.htr
where Pxx is the name of the shot, NA the animators initials, ipxx the version or take.
Once the shot goes into the "Final" folder, it is ready to be published for the next step (ie lighting)
This looks like a mess, and it can certainly be at first, but getting used to it it all makes sense, and speeds the processes of looking for assets, checking them, publishing them...
The less margin we leave for human error, the better, and aplying a logical methodology saves a lot of problems. There are many things that computers are better at than us, a copule of scripts here and there make your life much easier.
To sum it up: be rigid, with almost dictatorial discipline, when naming and placing things. Don´t allow licenses with these sort of things, a mere error or foolness can potentially become a huge mess.
Giving for granted the professional level (regarding discipline) of the team, the Pipeline must be at the service opf the team, and not the other way around, as it sometimes happens with so-called "pipelines"...
Of course this does not only relate to nomeclature, data structuring and such, but it begins there.
I don´t know of any tool that allows to create an "ad-hoc" pipeline, and its complexity will depend on a number of factors: The number of departments that will need to share/exchange assets, the programs they use, the kind of data each dpt. publishes, etc. The tools that will be written to configure the pipeline must have all this into account, as there aren´t two studios alike, one tool can be too small or simple for some and too big or complex for others