Stitch Pipeline

Stitch Pipeline is a metadata format that has the similar idea in mind as XML but is specifically formatted for VFX. The main idea is to define information in a scene into a simple format that is humanly readable and editable. The extension .stc is used for stitch files. Stitch stays true to the idea of metadata in the fact that as you build metadata, it in itself becomes data and can be stacked. A .stc file calls another .stc file and so on.

The Format

In its current state, stitch is broken down into multiple different types of files with minor differences but share the same concept. There are basic building blocks that each of the stitch files have in common.

Defining Types

*;define"Type": where "Type" refers to one of the stitch types: ( RenderPass, Light, Element, Material, and so on )

More information on specific kinds of define"Type":

*;group: Grouping is used to separate areas for different needs. In geometry files we use it as a null and in a pass.stc file we might just use it for separation of materials.

*;material: Material is used when we are assigning any shader attributes.

*;include: Includes can be used in any file when you want to append information to the current one. Used the same way as a c .h file we might use it in a geometry file to load geometry from a master scene or a master light set to append to our current light set.

*;materialBinding: Used to bind any type of materials from shaders to objects.

*;element: Lists elements or "ghosts" in a scene.

*;light: defines a light.

*;shadowCam : defines a shadow camera.

The Stitch format is malleable. Meaning that the name-structure for each type of file can be used differently. Look at the example below, the name "group" is used as a null with a transform in a Geometry: file in a Shader: it is used as a separation block.

The separator "defineType" is a special name where there is only information that is being defined for one type: element, shader, light, etc.

There is also the brackets {} that are required to enclose each type of data. For example defineLight key {} encloses the entire define group below and lightSphere key_LightSphere {} encloses the entire lightSphere group but it still inside of the defineLight key {} group.

Below you will see two different files. These are used to save and created a light. One is used to hold shader information and the other holds light geometry information.

lightGeom.stc:

group Model { transform: {0.0 0.0 0.0 0.0 0.0 0.0 1.0 1.0 1.0} defineLight key { lightSphere key_LightSphere { transform: {0.0 0.0 0.0 0.0 0.0 0.0 1e-12 1e-12 1e-12} } light Model.key { transform: {0.0 0.0 0.0 -45.0 35.2643896828 30.0 1e+12 1e+12 1e+12} } } }

lightShader.stc:

defineLight key { material: /home/user/lights/spotlight { category: fill, parRayContrib: 0.0 intensity: 0.75 maxintensity: 0.825000047684 lightcolorR: 1.0 lightcolorG: 1.0 lightcolorB: 1.0 shadowCam Model.key_ShadowCamera { ShadowCameraLinker True resolution 1024 samples 4 } } }

titch Pipeline Files

Along with the Stitch file format there is also a base set of files that "hook" together. These files are created during each stage of production.For example the following is how an asset would be taken through from modeling all the way to rendering.

Example: Create an asset named "eagle01" and save it in format .gto

NOTICE: In these files there is only 1 number. This is not a version, it is a numbering system that allows multiple models with similar names to exist like eagle01, eagle01 and so on. This works well for packages like Massive and such or even if you have a flock with small similar characteristics.

Modeling

*Create a hires model eagle01_hi.gto
*Create lowres/bbox version eagle01_lo.gto/eagle01_bbox.gto
*Create stitch files: eagle01.ref eagle01.mtl eagle01.look
*Render out turntable for verification
*checkin/publish the model and stitch files

Rigging

The easiest way to do rigging is to save it with the model which does not change the stitch files at all. Though with stitch we can separate if desired.In the case that we want to separate the rigging from the model.

*checkout/import eagle01.ref file
*Rig as needed
*Save rig separate from the model
*Edit the eagle01.ref
*Render out an anim cycle for verification
*checkin/publish the rig and stitch files

LookDev

*checkout/import stitch files: eagle01.ref eagle01.mtl eagle01.look
*Shade and Texture by editing the .mtl and .look files
*Render out turntable for verification
*checkin/publish the final stitch files eagle01.ref eagle01.mtl eagle01.look

Matchmove

*Import bg plate
*Matchmove and create basic objects needed
*Export camera and objects. This process would auto-make the stitch files for new geom and camera01.ref. The camera would retain all animation and geom in one file.
*checkin/publish the camera, objects, and stitch files

hot Production

At this point, we are finished with a model asset. We can go on to shot production. There are various steps for shot production and they are based on what was created already.

You will see below some of the variances that exist.

Layout

(Layout is an optional section and depends on the shot type.)
*Create master01.stc files from a GUI
*Set up a scene. If a model is not rigged, use top node to position.
*Export lightShader.stc, lightGeom.stc, pass.stc, eagle01.anim

Animation

The files needed for animation are based on what has been created already.
*Set up a scene. If a model is not rigged, use top node to position.
*Export master shot01.stc, lightShader.stc, lightGeom.stc, pass.stc, eagle01.anim

hot Directory

The shot files are dependent on what information is in the published area. Coordinators should know where the shot currently sits.

There are multiple scenarios from which a shot can be built. In this example, we have a bg plate, animation, the eagle model, and a layout scene for shadow elements.

*;import/create: Shot01.stc, elemMaster.stc, pass.stc, lightShader.stc, lightGeom.stc.
*Import the stitch files into the UI (maya, xsi, etc) and light the scene.
*Export all the stitch files and checkin/publish them.