Dane's Pipeline Organization Notes

Contents 1 File Referencing 2 File Organization & Naming Conventions 3 Modeling Team 4 Rigging Team 5 Animation Team 6 Shading Team 7 Lighting Team

 

File Referencing

1. Don't overdo the use of file referencing in your pipeline. The more file references you have, and the longer your file reference chain, the more files you will have to traverse through when trying to track down the source of a problem that is showing up at the top level. File referencing is most beneficial for including items that occur in almost every shot (i.e. the set and characters), and in instances where you want to allow for multiple people to work on different aspects of the same shot simultaneously (i.e. lighting vs. motion vs. effects). See the following two figures for good and bad examples of a file reference chain.

Too many references   Much more manageable

2. Use Namespaces for every reference you create. Simply providing a prefix string for the reference is not good enough; you must make sure that the "Use Namespaces" checkbox is always checked. Rather than using the filename as the namespace (default), instead use short strings that uniquely and tersely identify the contents of the file that is being referenced. Some examples from last year's production:

• CL = Character Lighting
• FX = Effects
• MO = Motion
• SET = Set
• MDL = Model
• SH = Shaders

3. Use the full "//ntdfs/cs/unix/projects/instr/production1/" path for every file reference and texture file that you include in a scene. Never use local drive paths (C:), mapped network paths (Z:, Y:, W:, etc.), or network paths beginning in //preproduction/ or //production/. All of these paths are only compatible with Windows; the only path compatible with both Windows and Linux is the //ntdfs/cs/unix/projects/instr/ one.
4. Save files as MayaAscii (.ma) rather than MayaBinary (.mb). This recommendation comes straight from Alias (see [1]). The reason is that it is much easier to troubleshoot and fix problems arising as a result of file referencing when you are working with MayaAscii files. If someone accidentally makes a reference using their W:\ drive, which they've mapped to production1, the only way to fix the path (without creating new problems), is to open the file as MayaAscii using a text editor and edit the line which creates the file reference. The file reference information is always stored in the first few lines of a MayaAscii file. Example:

To fix the reference to W:/effects/shot_0100.ma, you would need change both lines containing that path -- the line beginning with file -rdi 1 as well as the one farther down beginning with file -r.

5. Use a standin set for your animators to use in place of the full-detail set. The standin set should only contain the elements of the set that the animators will need (i.e. the ground plane and any other item the characters may need to interact with) and no shaders. The animators then have the option of unloading the reference to the full-detail set to improve performance as they animate.

File Organization & Naming Conventions

1. Enforce a strict file-naming/folder-hierarchy convention from the beginning. A typical setup is to have each area (i.e. motion, effects, lighting, models) in its own folder on the production server, and within each of these main folders, break it down into subfolders based on sequence name, then subfolders based on shot number, as shown here:

The most important thing is that other people should be able to easily find your files and identify the latest iteration of it without having to consult you or go on a wild goose chase across the network.

2. Save iterations of your files and keep them around for reverting back to in the event that a problem arises in the latest iteration. The best way to organize this is to have every asset live in its own folder and contain a subfolder named "iterations" which contains all iterations of that particular file. The latest iteration exists both in the iterations folder and as the top file outside the iterations folder, as shown in the following figure:

There is a production script which automates the process of saving new iterations of the file you are working on. Follow these instructions to set up the production scripts on your profile. The file iteration script is the button named "Save" in the Shared. It will create an iterations subfolder under your current working folder if one does not already exist and save your file as a new version. Every time you click the button, a new version is saved.

3. Never use spaces or capital letters in the names of your files and folders, for maximum cross-platform compatibility. Stick to lowercase letters and use underscores in place of spaces. This is recommended because there is a very annoying difference between Windows and Linux: Windows is case insensitive when it comes to filenames, whereas Linux is case sensitive. So suppose that you have a file named file1.ma and another one named file2.ma which references file1.ma. Now suppose someone is working on file1.ma and for whatever reason they decide to save the new copy as File1.ma. Windows will not complain when you open file2.ma since the reference to file1.ma will resolve to File1.ma. But when you try to render this shot on Linux, it will complain that it can't find the file1.ma reference inside file2.ma. So, by enforcing a rule like "all files and folders must be entirely lowercase", you eliminate any ambiguity and uncertainty in the names of your files. You will know before rendering whether or not a file is going to break on Linux based on whether or not it is all lowercase. Enforce such a rule AT THE BEGINNING of your production. NOTE: There is a Linux script located at /production1/Scripts_and_Plugins/tolowercase.sh which, if run inside an ssh shell to one of the Linux servers, will automatically rename every file on production1 to conform to this rule (replace capital letters with lowercase ones and replace spaces with underscores).
4. Setup your profile to load the shared production scripts. Instructions on how to do this are found here. This will automatically source every .mel file found inside /production1/Scripts_and_Plugins/Autorun/. To add .mel files to the auto-loaded production scripts, simply place them in the Autorun folder. Additionally, all shelves found in /production1/Scripts_and_Plugins/Shared_Shelves/ will loaded on startup. Any changes you make to shared shelves within Maya will NOT be retained across sessions. To make permanent changes (which will affect everyone), save your new version of the shared shelf into the Shared_Shelves folder.

Modeling Team

Before handing off your models to the rigging or set dressing teams, run through the following checklist:

1. Final models for Foo (smoothed and low poly), should be in production1/models/foo/foo.ma and production1/models/foo/foo_low.ma. There should be no other files in folder foo.
2. Delete all history on everything.
3. Delete any construction curves, display layers, and image planes.
4. Give EVERY piece of geometry a unique, descriptive name. Use Modify > Search and Replace Name... for mass renaming.
5. Group everything under one top level node.
6. Make sure you have NO layers at all.
7. Turn on "Display Shapes" in the Outliner and make sure there are no transforms with more than one shape node.
8. Turn off "DAG Objects Only" in the Outliner and clean out any unnecessary crap (i.e. brushes, partitions, ikSolvers). Generally any item critical to the file will be read-only so you won't be able to delete them.
9. The model should already be in the correct units so it doesn't have to be scaled to fit the other models.
10. Make a single object set for the lighting/rendering team which contains only the surfaces that are to be visible in the final render (select the surfaces and go to Create > Sets > Set).

Additionally, if the model is a tree:

1. Make sure that trunk bottom lies in the xz-plane.
2. Move the pivot at the center of the trunk bottom.
3. If you have a shader save it in a separate file, strip the final model file from any shaders.
4. Duplicate the model to make 3 versions of varying detail:

1. A high poly version (clouse up to camera)
2. A mid poly version (for imediate background trees)
3. A low poly version (for far in the distance)

Additionally, for character models which are going to be rigged:

1. They should have the bottoms of the feet on the XZ plane (use grid snap to be exact).
2. All nodes should have "Freeze transforms" on them. (Modify > Freeze Transforms)
3. The model should ideally be symmetric around a plane, such as YZ (those doing the weightpainting will thank you).
4. Merge all vertices. The character should have no open seams or split vertices which break apart when the character deforms.
5. Duplicate the model to make 3 versions of varying detail:

1. A high poly version (for rendering). Smooth the geometry and delete all history after smoothing.
2. A mid poly version (for animating). Use the original unsmoothed geometry and delete any unnecessary detail/accessory pieces of geometry (i.e. belt, gloves, patches, earrings, eyeballs, hair, teeth, mouthsock, etc.)
3. A low poly version (for animating). Copy the mid poly version and cut it up into separate pieces at each joint location.

Rigging Team

1. Final model Foo, should be in production1/rigging/foo/foo.ma. There should be no other files in folder foo.
2. Before doing anything, make sure there is absolutely no history on any piece of geometry.
3. Bind the 3 different versions of the model to the same skeleton. Each version represents a different level of detail and is intended to provide the animators with faster/lower detail versions for quick posing of the character, and slower/higher detail version for fine-tuning their animation and applying facial expressions.

1. The high poly version should contain the smoothed geometry and the facial blend head. Perform a smooth bind on it and weight paint on this version.
2. The mid poly version contains the unsmoothed geometry. Perform a rigid bind on it and call it good.
3. The low poly version contains the unsmoothed geometry broken up into separate meshes. Each piece should be parented under a joint. This allows for optimal performance for the animators, while still providing a good visual approximation of the character's pose.
4. Add a channel on one of the controls, such as the root con, for switching between each of these 3 modes.

4. Keep the controls and anything else an animator may be keying (i.e. eye aim locators) in a completely separate hierarchy from everything else (skeleton, geometry, rivets, clusters, etc.). Never change the name of controls or joints after animation has begun on the character.
5. Lock and/or hide every channel that you don't want an animator to accidentally key.
6. Setup display layers to allow animator to toggle the visibility of skin, joints, and left/right/center/facial controls. Be sparce with leyers, you can't change them afterwards. Name them clearly.
7. Create a quick select set (Create > Sets > Quick Select Set)containing all of the keyable attributes of the character so animators can quickly key every control when they do their blocking.
8. Name everything clearly.
9. Organize everything (geometry, joints etc.) in a clear hierarchy all grouped under a top level node.
10. Do NOT delete history after making a rig! (a rig is part of the history)

Animation Team

1. When starting a new motion file, REFERENCE the rigged characters, standin set, and props, and IMPORT the camera from the animatic (so that you can make any necessary camera adjustments inside the same file).
2. Lock all channels of the camera or else you will inevitably move it at some point, thinking you're looking through the perspective camera.
3. It may also be helpful to display the resolution gate of the camera and increase the camera's overscan above 1.0.
4. Be sure to have the production scripts sourced in your profile. One of the included functions is a framerate check that runs everytime you open a file to make sure your framerate is set to 30fps.
5. When a character is interacting with a prop, constrain the prop to a joint of the character rather than the character's geometry.
6. For an added level of control, group props underneath themselves once, then constrain the top level node to the character, and set keys on the node right below it for any secondary motion you need.
7. Avoid using the Mute Channel function -- there's a bug that can cause problems in parent files higher up the reference chain.
8. In your Timeline Preferences, it may be helpful to change the Update View to All and the Playback Speed to Real-time.

Shading Team

1. Optimize your shading networks by reusing file nodes everywhere possible. Otherwise unnecessary copies of the same file will be occupying space in memory during render time.
2. Don't overdo the filesize of shader files. A leaf seen from far away does not need a 4096 x 4096 pixel image. Use only as much detail as necessary basd on how close the camera will be getting to the surface. The rendering team will thank you.
3. When finished applying your shaders to geometry, delete all unused shading nodes. Hypershade > Edit > Delete Unused Nodes.
4. The "shading" folder should be used for storing all of your texture files as well as iterations of complex shading networks. Once a shading network is complete it should be IMPORTED into the model file onto which it will be applied.

Lighting Team

1. Make your light links between light sets and object sets rather than between individual lights and pieces of geometry. See [2] for details.
2. Try to avoid using the Relationship Editor for light-linking (it's buggy). It's better to use the Lighting/Shading menu, which contains Make Light Links, Break Light Links, Select Objects Illuminated by Light, and Select Lights Illuminating Object.
3. The shared production scripts contain the helpful functions printLightLinks, which prints to the Script Editor all of the light linking information in the current scene, and clearLightLinks which completely wipes away all light linking information in a scene. Both of these functions can be invoked through the Shared shelf.