Folder Layout pt. 3

A Better Way

Wouldn't it be great if we could avoid separating any data at all? If all data could live happily under the same roof?

The end goal is to simplify data navigation. You want to be able to locate what you need as quickly as possible. As we have seen, some data may be logically paired with other data and so a hierarchical approach may seem like a good idea. Other data however provide a less rigid constraint towards its source, such as a user and his shots, and may perhaps be better suited for tagging and filtering. A user working on a shot deals with the shot "entity", various rigs and output pointcaches supporting assets such as audio, images, notes, feedback and so on. The user does not care whether some data are stored in one location and some are not, the user only wishes to quickly retrieve the data he needs at the time he needs it whilst still being able to work on the physical files his chose application. We would like to find one unified way in which all of this is possible.

A closer look at the previous example reveals some more superfluous use of structure.

Some data within a cg production however have no binary data, and yet contain metadata as well as other pieces of data. Consider an asset such as the Simulation Setup for a Ladybug. The rig has no binary information related to it, it is "abstract", yet it contains versions in which binary information are stored. Each version in turn has metadata, such as date of creation, author and changelog and so on.

At the root, we have an item referred to as Studio. The studio contains everything related to a studio as a whole. This includes jobs, users, settings, running processes and so on.

Each item hosts information relevant to its type. Job holds data relevant to a single job. This includes all sequences and shots, assets, users working on this job and related metadata such as who the client is, when the job is due, media such as storyboards, reference images and videos.

Moving forward, we have the Asset which contains everything related to a single asset, such as a Character. This includes models, textures, rigs, shaders and associated data and relationships to other data.

Certain types of objects are designed to host certain other types of objects.

In this example, the job beast is host of the items work and published. From a users perspective, when mining a job for resources, be it assets or which shot to get on working with next, this is all that is required at this level. On disk however, beast may host a multitude of items other than its resources.

The items appdata and userdata host application-specific data and users home directories respectively. Note the extensions. These are rather ugly too look at and would be better represented by icons other than the default windows explorer ones. Certain names also contain reserved keywords. In this case, __properties__ host generic metadata about beast and __settings__.ini contains user editable data, as hinted towards via the .ini extension.

The various types required to make up a studio and all of its resources can grow quite large, that's why it is important to structure it in an as manageable form as possible.

Firstly, lets look at some of the assumptions we can make about the users of Pipi.

The target goal is to facilitate the creation of CG images and as such the major components can be broken down into Sequences and Shots, each shot capable of having one of more Assets.

Assets include elements such as Characters, Props, Vehicles, Set Dressing objects etc. Each Asset may contain additional elements per department. I'll bring in Bob and the Ladybug project from the previous post to aid in the explanation.

Bob works in modeling on the hero character Ladybug. Ladybug has got several models associated with it, such as the body, the face, character-specific props such as clothing, a wristwatch and so on. Whatever model Bob eventually finishes, since Bob is in the Modeling Department, his published material will go under the department category Modeling.

When Bob works on the body model in Maya, Bob saves his scene every now and then. Generally, Bob will only share material with other departments once he is happy with his results and so application files, such as scene versions, are stored separately from those happy results. This helps keep the database clean and minimal, whilst still allowing Bob to make as many revisions to his scene-files as he needs. This results in the following hierarchy.