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.

Auto Rigging pt. 1

A somewhat overloaded term. What does it actually mean to "autorig" something? Firstly, let's look at why one would consider autorigging for their project.

Why?

Lets have a look at a simple task, such as setting up forward kinematics controls for an arm.

The video is sped up 5x and takes about two minutes to play out. Its quite the task! Also, note that after the joints have been drawn, no new information is added. The joints contain both position, orientation and hierarchical information which is all that is required for the subject to behave as expected. Everything past that point is implementation detail, technicalities, that can be automated. Also note that the drawing is the least time consuming process.

I think this will suffice as motivation for automation.

What else? 

Well, a human usually has two of these along with legs, each side being identical to the other in any meaningful regard. That means that the additional time it takes to also set up the other side is of equal length to the one we just set up, meaning that what you do you'll have to do four times to cover each limb of a character.

Put simply, rigging is a repetative task. The very many things you do for each setup are densly similar to tasks you just did or have done previously. How about a bullet list of some of the main things that automation can help you with?

Symmetry

This is a big one. We can cut out job in half if one side simply followed the other. Even if your characters suffers from asymmetry, such as zombies, chances are that features are still to be repeated to the other side.

Common features

Many things have been done before and works. Automation could keep you from reinventing the wheel more than once

Time well spent

Time spent repeating is time wasted and nothing hinders creativity more than that of wasted time. You'll spend half the time performing repetative tasks and the other half thinking of ways around those tasks. Not having to worry about things already solved will allow you to focus on moving forward and make things better and faster.

Ok, let's get crackin'

Hold on there. Even though the end result is to have an intutive control rig for the animator, the way to get there is often different with each artist. Before deciding whether to automate something, it is important to understand exactly what it is you wish to automate and such information is best taken from experience. If you're thinking "I dislike rigging and want to automate it in order to get it out of my way" you're reading the wrong post. Once you know what to do, you must also understand it. Remember, you can't design what you don't understand.

Lets have a look at another video, this time the video has been sped up only two times, is half as long and  contains twice as many features on four times as many limbs as the previous video.

What happened there?

As you can see, the result of this video is the same as the previous video, and more, in less time. What is missing from this video are things that have been automated based on the initial drawing of the joints along with their naming schemes. Remember, anything beyond that point is implementation detail and is repetative with each setup. Once you know how to setup forward kinematics, the same rules apply for each and every forward kinematic enabled setup you do and the same goes for inverse kinematics, twisting, bending, stretching, pinning, space switching and so on.

Currently working on this tool, the next incarnation will do more without requiring any more work from the user. Thats the beauty of automation.