File structure is something we have struggled with and changed a number of times as our needs changed and grew. Our most recent iteration involved a lot of planning and discussion of the future to try and create something we wouldn't have to often change. The most difficult thing to take into consideration for us was that there was so much information we needed to have, but didn't want it to feel overwhelming to the user, and didn't want to hit the windows limitation for max file path length (260 characters).
Some things we needed to make sure were in our path are:
- Project Name
- Shotgun Type (Asset, Scene, Sequence)
- Shotgun Sub Type (Character, Prop, Env)
- Shotgun Code
- Pipeline Step (Lighting, Rigging, Animation)
- Task
- Context (Renders, Caches, Textures)
What we finally came up with is above. Our solution involved heavy integration with Shotgun. The user would go to Shotgun, create an entity like normal, assign some tasks, then when ready, check a build check-box on the desired tasks. A shotgun event daemon would be listening for this check-box and proceed to create the correct paths for the user in both perforce and on any other drives. The user would then proceed to work in a folder based on those tasks.
The golden rule of this solution is that the user has to work under a task. Any outputs the user creates have to have a context, and are placed in the outputs folder. This way we have a direct easy way to get Shotgun information for a given path, and a clear division between files still in progress, and files that are able to be used down the pipeline.
Once we figured out what needed to be in a path, we dove into the filename itself. We came up with a solution that would allow us to parse most of the info we needed from the filename. This prevents the need for metadata files, while keeping the name relatively short. A filename consists of the following parts connected with underscores:
- Shotgun Code
- Optional Label (Used for any extra info needed)
- Task Name
- Variation
- Representation
- Version
- Optional Sequence
- Extension
We are currently following the version naming recommendations from a DigiPro Pipeline Talk by Bill Polson from Pixar. The basic premise is that there are three parts to a version. A variation, a representation, and a revision.
- The revision is what everyone is used to, the number/iterator for the current version.
- The variation is for a change in artistic intent, usually from the director that you aren't yet sure is a final change. For example you have a red ball, and the director wants to see what it would look like if it were blue.
- Finally the representation is the technical intent / format of the file. For us this describes the container and content of the file and may include the extension. For example h264-HD-8bit-24, would be a video with h264 compression, with HD resolution, 8-bit color, and be 24 frames per second. We only include as much information in a representation that is required. So for example if every file for a project is using 8-bit color, we would take that part out.
After working on several additional projects, this new file structure has really made an impact on how much easier it is to find files. While there are still areas for improvement, we are in a spot now that feels much better and allows for a much larger amount of flexibility.
