Stitch Pipeline

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Stitch Pipeline is a metadata format that has the similar idea in mind as XML, but is specifically formatted for visual effects (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 that as metadata is built, it in itself becomes data and can be stacked. A .stc file calls another .stc file, and so on.

The Format[edit]

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

Defining Types[edit]

  • defineType
    where Type refers to one of the stitch types: ( RenderPass, Light, Element, Material, and so on )

More information on specific kinds of defineType:

  • group
    Grouping is used to separate areas for different needs. In geometry files we use it as a null and in a file we might just use it for separation of materials.
    Material is used when we are assigning any shader attributes.
    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.
    Used to bind any type of materials from shaders to objects.
    Lists elements or "ghosts" in a scene.
    defines a light.
    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.[edit]

   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}

   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

Stitch Pipeline Files[edit]

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 the phases from modeling 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.


  • 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


The easiest way to do rigging is to save it with the model with no change to the stitch files; stitch enables separating such as 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


  • 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


  • 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

Shot Production[edit]

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 is an optional section and depends on the shot type.)

  • Create files from a GUI
  • Set up a scene. If a model is not rigged, use top node to position.
  • Export,,, eagle01.anim


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,,,, eagle01.anim

Shot Directory[edit]

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,,,,
  • Import the stitch files into the UI (maya, xsi, etc.) and light the scene.
  • Export all the stitch files and checkin/publish them.