#0047 Ten Essential Rules of File Naming : 7- There Can Be Only One

Asset Management 101 – part 5

Previous:     
Asset management 101 -- part 4 : Ten Essential Rules of File Naming 4-6

In this post, the fifth to look at the basic concepts of Asset management, we will look at the seventh rule of File Naming, call it the Golden Rule:  There Can Be Only One of Each Version

It's called revision control for a reason.  

Take control.

Every CG Pipeline Production Command and Control System depends upon the identification and tracking of asset revisions and shot takes to avoid chaos and confusion and promote efficient workflows. Equally vital is the association of each asset revision with its source files. So let us talk about best practices in file naming for takes and revisions.

best practice:
Call Composited Shots "takes"

Image by Kid's Birthday Parties via Flickr

What is a take?

Before I go on, let me clarify that in my thinking, any movie asset or sequence should be called a take. This is the terminology used on set for a shot revision that is rendered (captured) by exposing the film or digitizing the image. A take is a unique rendering of a shot.

If you currently use the terminology “version” or “revision” for a shot or element render, please change your thinking immediately and call them takes. It's important, because it puts you more in the language of filmmaking and more into the right mind set. It will help you remember that it is perfectly acceptable and often desirable to present multiple takes to a director for seleection. It will help you remember that a take can have good and bad qualities, and that at some point, you and the director need to accept a take and move on, because there is limited time for production.Finally, it will help you separate and track what the client sees from what your team sees in internal reviews.
 

On the other hand, your still art images, CG files, and other files used to make a take can be called versions if you like, because usually the goal is to produce one final refinement. While one can argue that at the end of your production, there will be one final version of each shot, I still recommend that you think of your composite outputs as takes.  To take this further, I usually number these with a "t" instead of a "v", but as we shall see, using a letter at all is sort of unnecessary.

best practice:
Put Modifiers After Revision Number

In the absence of a solid naming convention that correctly manages the various needs of revision control, artists and coordinators will invent there own ad hoc solutions. which will cause nothing but confusion as supervisors are forced to contend with a mish-mash of file names and, even worse, the destruction of sort order (see rule #5: Protect Sort Order).  The most important thing, is to keep all modifiers after the revision or take number.

Artist names are modifiers
 For example, artists tend to think that it is perfectly acceptable to separate their work from every one elses, and put a revision number after their own name, like this: shot12_jack_t01. This can be really annoying if you're looking at the folder and see that shot12_jack_t01 is newer than shot12_jill_t07.   As soon as you notice this, you know you can no longer count on name sorting, and must now sort and select files by date.  This, by the way, is the most common violation of sort order.  A  more correct way (but not ideal) is :
example 1

shot12_t07_jill
shot12_t08_jack

If you need Jack's and Jill 's authorship to be part of the file name, it should go after the version number, and version number uniqueness must be maintained.  This is the only acceptable way. 

Options and descriptions are modifiers
Another example is the artist decides to put a descriptive modifier before the version number and then makes files:  shot12_redOption_v01.psd, shot12_blueOption_v01psd.  Again, this destroys sort order,   A more correct thing is to put the option description after the revision number:
example 2

shot12_v01_redOption.psd
shot12_v02_blueOption.psd.

You should note that in addition to moving the option to be after the revision number, I incremented the revision number for the blue option.  This will help with tracking, because now no  one will need to include the words "redOption" or "blueOption" when discussing the shot and logging it in software.  If your software takes revision and take numbers, you don't have to design it to accept non-numeric data.

Observe also that the ad hoc introduction of letters after your revision number is also just a modifier, like "red" and "blue", but it adds no real information.  Don't let artists call variations "v003A" or "t02B".  It adds  nothing and causes confusion.  Instead, use a more descriptive word or establish codes for common needs.

best practice:
Tie Render Passes To A Revision

Another kind of modifier comes when rendering CG elements.  Most contemporary pipelines give compositors more final control with multi-pass rendering.  Again, pass names belong after the revision name:
example 3

shot12_v01_rgb.####.iff
shot12_v01_depth.####.iff
shot12_v01_ao.####.iff

Remember File Naming Rule #6, Rendered Files Must Refer to Their Script?  By keeping the CG pass information after the version number, one can infer that all these passes come from the same MAYA file, shot12_v01.mb.  This provides an essential association- anyone assigned to revise a pass knows exactly what script generated it.

Suppose you want to adjust the specular pass for shot 12 and add a dirt pass.  You would modify the script, save it as "v02" and then render only the new passes.  The compositor then would have these assets, and each would tie to a Maya file.  Even though the other passes may render correctly from v02, their source is v01. 
example 4

comp assets from shot12_v01.mb

shot12_v01_rgb.####.iff
shot12_v01_depth.####.iff
shot12_v01_ao.####.iff

comp assets from shot12_v02.mb

shot12_v02_spec.####.iff
shot12_v02_dirt.####.iff

best practice:
Use Takes and Versions Together

When it comes to managing shot take numbers, a company may have a policy to only increment take numbers when a shot is presented to the client, as opposed to increementing the takke number each time a take is rendered for internal review. Each policy has its merits, and we won't debate them, but let's look at how the two policies affect your revision control numbering system.
The first method, which we can call Internal Take Numbering, is to assign a take number each time the script is rendered for review by a supervisor. This is a very simple system and works well with the naming conventions I've describes so far. For example, these NUKE scripts will generate the shots shown
example 5

shot12_t01_jill.nk → shot12_t01.mov

shot12_t02_jack.nk → shot12_t02.movx

shot12_t03_jack.nk → shot12_t03.####.dpx

But suppose your company policy is to use Delivery Take Numbering. In this system, only takes delivered (presented) to the client for review or approval are numbered. Suppose in the previous example, the Quicktime (.mov) takes were for internal review. A company using Delivery Take Numbering might name the files and takes a bit differently:
example 6

shot12_t01_jill.nk → shot12_t01_jill.mov

shot12_t01_jack.nk → shot12_t01_jack.movx

shot12_t01_jack_02.nk → shot12_t01.####.dpx

Do you see the problems here? First, Jack appended a _02 to his second take, which he used to render the delivery take. Second, jack preceded jill in the alphabet. So when sorting, the sort order is broken. This is why earlier I said appending the artist name after the shot revision number is not ideal.
The better way, when using Delivery Take Numbering, is to do what software companies have done for years- modify the release version with a sub-release number. In this case, what you do is use a take and a revision number at the same time,, and no one is allowed to reuse a combination. For example:
example 7

shot12_t01v01_jill.nk → shot12_t01v01_jill.mov

shot12_t01v02_jack.nk → shot12_t01v02_jack.mov

shot12_t01v03_jack.nk → shot12_t01.####.dpx

shot12_t02v01_jack.nk → shot12_t02.####.dpx

In this system, after the take number there is a revision number. Note that in this case, the revision number and artist name is used, and appear only in renders for internal review. Final deliveries are renamed or rendered without the revision number. Of course, this is optional, there is no reason (except embarassment?) to hide the revision number from the client.

Modifications of this system would be to use an undescore or period instead of the v. A period is undesirable, because it could cause confusion in some software, but an underscore works fine. Or you could just concatenate the revision number and use it without punctuation:
example 8

shot12_t0101_jill.nk → shot12_t0101_jill.mov

shot12_t0102_jack.nk → shot12_t0102_jack.mov

shot12_t0103_jack.nk → shot12_t01.####.dpx

shot12_t0201_jack.nk → shot12_t02.####.dpx

I'm personally not a fan of the last suggestion, but if it works for you, go for it. I like this best, and would drop the user name if convenient:
example 9

shot12_01_01_jill.nk → shot12_01_01_jill.mov

shot12_01_02_jack.nk → shot12_01_02_jack.mov

shot12_01_03_jack.nk → shot12_01.####.dpx

shot12_02_01_jack.nk → shot12_02.####.dpx

Make sure your revision modifier policy is understood
If you do use revision numbers after a take number, you have one more decision to make.  It's a big one, and everyone needs to understand the studio's policy: does the revision number modify the current take or the last one?

In software, the revision modifies the release.  For example, 8.2 is a modification of release 8.   to clarify, do you want take 02_01 to come before or after the release of take 02?   In the examples I've given so far, it  comes before.  This is a violation of sort order, so while this may be one way of doing it, I suggest making revision 01 of take 02 to be thought of as the first revision after delivery of take 02.   A look at a shot's comp script files would then give the correct sort order and sequence of revision, the ideal in revision control, and in this system, it is unaffected by the addition or omission of artist names.  In this example, I will use the period to separate take and revision fields:
example 10

shot01_t00.01.shk  → .mov output for internal review shot01_t00.01.mov

shot01_t00.02.shk  → .mov output for internal review

shot01_t01.shk  → .mov output for client review

shot01_t01.01.shk  → .mov output for internal review in response to new direction

shot01_t02.shk  → .mov output for client review

best practice:
Use Codes and Punctuation Sparingly

In the examples 8and 9, I dropped the code letters “t” and “v” aand in one case, concatenated the numbers without punctuation and in the other, seperated the information with an underscore.  In example 10, I used a period.  In each case, what I am after is simplification and improved legibility. I dropped revision numbers for client releases, but that, like so many other suggestions I make here, are really a matter of preference.

However, while you may use a period as a field separator in a script or other asset file names, image sequence file names with extra periods must be avoided:
example 11   the wrong way

shot01_t01.01.aep →  shot01_t01.01.####.dpx 

instead, replace the period with some other punctuation

example 12   the right way

shot01_t01.01.aep →  shot01_t01_01.####.dpx

It's called revision control for a reason. 
Take control.

In summary, the rule for revision control is simple: 

There can be only ONE.  

While there will usually be more than one take or revision, there can only be one take one and only one take two and only one take three and only one ....

Please, defend this rule with vigor! Don't let artists break this rule, ask them to rename their files, and make sure every file has a revision control or ID number (even one off files like a quick Photoshop element or a reference) and make sure every file's revision control number is unique.  

Next:            
Asset Management 101 – part 6: Ten Essential Rules of File Naming 8: Abbreviate Consistently