Skip to main content

Pipeline

Yeti was designed to be used by studios of all sizes while ensuring maximum flexibility across different domains.

Grooming should be considered a non-blocking process, enabling artists to work independently.

Two key features of Yeti help make this possible, proceduralism and non-topology dependence. Both of these allow groom descriptions to be used on any input meshes to produce a similar result thus decoupling the need for finalized up stream assets.

This allows a single character consisting of a model, textures, rig and groom all managed independently to eventually be assembled to create the final asset. Each domain may be the responsibility of a different department (larger studios) or a single artist (small to medium studios).

Two example workflows follow. These are just examples of how Yeti may be integrated within a pipeline for reference purposes and not a requirement.

Workflow​

The first example workflow assumes each domain publishes generated artifacts independently to be consumed by an asset build process prior to entering the shot context, a simplified workflow is provided below as an alternative.

Asset Pipeline​

  • Modeling will publish geometry that is used by Look Development, Rigging and Grooming departments and eventually the Asset Build process.
  • Look Development will publish Shaders and Textures that will be used by the Grooming department and the Asset Build process.
  • Rigging creates both an animation rig (lightweight, fast to pose, etc.) and a deformation rig (with full deformations, muscles, fur/grooming controls etc.) which will be used by the Asset Build.
  • Grooming will create a fur description which will be published and used by the Asset Build. Yeti's Groom (GRM) files can be saved as an encapsulated groom to be published and referenced in the Asset Build.
  • The Asset Build process will combine all of its dependents to created a published final asset. A new Yeti node can be created on the rigged final model and the published Groom can be referenced, even if the input model has changed the Groom will still work.

Shot Pipeline​

  • The Animation department will used the published Animation Rig for their performance and publish new versions as they iterate on a shot.
  • The published animation will be combined with the published Asset, with the animation being assigned to the deformation rig. Depending on a studios workflow a cache may be created for the deforming asset.
  • If Simulation isn't required an Animated Groom Cache can be created and published to be used by Lighting & Rendering.
  • If Simulation is required then the animated asset, or baked animation caches, will be sent through the Simulation process at which point a Simulated Groom Cache can be generated.
  • At this stage the Character FX department has the option of creating corrective grooms based on the results of the Simulation step. Any fixes can be re-cached and published taking precedence over the Simulation results.
  • Finally the Lighting and Rendering departments can reference the published cache files.

At any point in this workflow an upstream domain may publish a new version of an artifact causing the dependency graph to re-evaluate each stage non-destructively.

Simplified Workflow​

A more simplified workflow relies on the individual domains being combined into a single initial Maya asset, model files and textures may still be external dependencies.

Asset Pipeline​

Modeling, Look Development, Grooming and Rigging are all combined into a single Maya file.

Shot Pipeline​

  • The Asset is animated on a per shot basis.
  • If Simulation isn't required the Animated Asset may be passed directly to Lighting & Rendering if Maya is being used. Caches may need to be created for other DCC's like Katana and Solaris.
  • If Simulation is required then the animated asset will be sent through the Simulation process at which point a Simulated Groom Cache can be generated.
  • At this stage the Character FX department has the option of creating corrective grooms based on the results of the Simulation step. Any fixes can be re-cached and published taking precedence over the Simulation results.
  • Finally the Lighting and Rendering departments can reference the published cache files.

Continue reading to learn how Yeti's toolset supports these varying workflows.