What is publishing?
A process of exporting particular data from your work scene to be shared with others.
Think of publishing as a checkpoint between two people, making sure that we catch mistakes as soon as possible and don’t let them pass through pipeline step that would eventually need to be repeated if these mistakes are not caught.
Every time you want to share a piece of work with others (be it camera, model, textures, animation or whatever), you need to publish this data. The main reason is to save time down the line and make it very clear what can and cannot be used in production. This process should mostly be handled by publishing scripts but in certain cases might have to be done manually.
Published assets should comply to these rules:
- Clearly named, based on internal naming conventions.
- Versioned (with master version created for certain types of assets).
- Immediately usable, without any dependencies to unpublished assets or work files.
All of these go into the publish folder for the given entity (shot, asset, sequence)
Keep in mind that while publishing the data might take you some extra time, it will save much more time in the long run when your colleagues don’t need to dig through your work files trying to understand them and find that model you saved by hand.
The Instances are categorized into ‘families’ based on what type of data they contain. Some instances might have multiple families if needed. A shot camera will for example have families 'camera' and 'review' to indicate that it's going to be used for review quicktime, but also exported into a file on disk.
Following family definitions and requirements are Pype defaults and what we consider good industry practice, but most of the requirements can be easily altered to suit the studio or project needs.
Here's a list of supported families
|Model||Cleaned geo without materials||main, proxy, broken|
|Look||Package of shaders, assignments and textures||main, wet, dirty|
|Rig||Characters or props with animation controls||main, deform, sim|
|Assembly||Characters or props with animation controls||main, deform, sim|
|Setdress||Environment containing only referenced assets||main,|
|Camera||May contain trackers or proxy geo||main, tracked, anim|
|Cache||Animated Alembic cache||rest, ROM , pose01|
|MayaAscii||Publish subsets that don't fit other categories|
|Groom||Hair and fur setups||hair, bear, bodyfur|
|Render||Rendered frames from CG or Comp|
|Plate||Ingested, transcode, conformed footage||raw, graded, imageplane|
|Write||Nuke write nodes for rendering|
|Image||Any non-plate image to be used by artists||Reference, ConceptArt|
|Matchmove||Matchmoved camera, potentially with geometry||main|
|Workfile||Backup of the workfile with all it's content||uses the task name|
|Nukenodes||Any collection of nuke nodes||maskSetup, usefulBackdrop|
|Yeticache||Cached out yeti fur setup|
|YetiRig||Yeti groom ready to be applied to geometry cache||main, destroyed|
|VrayProxy||Vray proxy geometry for rendering|
|VrayScene||Vray full scene export|
|ArnodldStandin||All arnold .ass archives for rendering||main, wet, dirty|
Clean geometry without any material assignments. Published model can be as small as a single mesh, or as complex as a full building. That is purely up to the artist or the supervisor. Models can contain hierarchy defined by groups or nulls for better organisation.
Apart from model subsets, we also support LODs as extra level on top of subset. To publish LODs, you just need to prepare subsets for publishing names
modelMySubsetName_LOD##, if pype finds
_LOD## (hashes replaced with LOD level), it will automatically be considered a LOD of the given subset.
- Only consist of transforms, poly-meshes or subdivision surfaces.
- Include correct naming suffixes for all the transforms and shapes. (These can be configured differently)
_SUBDfor subdivision surfaces
- Have frozen and zeroed out transforms
Model Must NOT:
- Contain any external references
- Contain any zero-length edges
- Contain any non-manifold geometry
- Contain any negative scales
- Contain any lamina faces
A package of materials, shaders, assignments, textures and attributes that collectively define a look of a model for rendering or preview purposes. This ca usually be applied only to the model is was authored for, or it's corresponding cache, however material sharing across multiple models is also possible. A look should be fully self-contained and ready for rendering.
.MTLX (yet unsupported),
Please note that a look is almost never a single representation, but a combination of multiple.
For example in Maya a look consists of
.ma file with the shaders,
.json file which
contains the attributes and assignments and
/resources folder with all the required textures.
- Be authored on a model loaded into the scene using Pype Loader.
Look Must NOT:
- Contain any default shading (Lambert1 in maya for example).
- Contain any referenced materials
Characters or props with animation controls or other parameters, ready to be referenced into a scene and animated. Animation Rigs tend to be very software specific, but in general they tend to consist of Geometry, Bones or Joints, Controllers and Deformers. Pype in maya supports both, self-contained rigs, that include everything in one file, but also rigs that use nested references to bring in geometry, or even skeleton. By default we bake rigs into a single file during publishing, but that behaviour can be turned off to keep the nested references live in the animation scenes.
- Contain exactly one top group with all the rig content parented below it.
- Include model previously published within the same asset.
- Clearly define or tag geometry for later caching (method differs between hosts)
- Clearly define or tag all the animation controllers (method differs between hosts)
Rig Must NOT:
- Have any transform values on any of the controllers.
- Have any animation curves attached to controllers.
A subset created by combining two or more smaller subsets into a composed bigger asset.
A good example would be a restaurant table asset with the cutlery and chairs included,
that will eventually be loaded into a restaurant Set. Instead of loading each individual
fork and knife for each table in the restaurant, we can first prepare
which will contain the table itself, with cutlery, flowers, plates and chairs nicely arranged.
This table can then be loaded multiple times into the restaurant for easier scene management and updates.
- Be only build using other pre-published subsets.
- Only use simple translate, rotate and scale transforms to position the individual elements.
- Contain only referenced elements
- Contain exactly one top group, with all the content parented under it.