Asset Management 101 – part 4
In my last post we looked at the first three of the ten essential rules: Let it Speak, Make it Short, Keep it Simple.
These provide the foundation of a good asset naming scheme. Before we go on, you will notice in this series I will use the terms file and asset interchangeably. For the most part, this is true, but sometimes an asset is a collection of files. For example, a sequence of image files actually is one asset.
Let's look now at rules four through six:
#4 Avoid Special Characters and Control PunctuationSpecial characters, like the colon, semi-colon, parenthesis, brackets, asterisks, ampersands, and so forth can and will choke some application you may use now or may need in the future. This may seem like real basic stuff, but it's also stuff that's regularly ignored. Here's a primer on what to do and not do – and why:
Use command-line compatible punctuationFor safety, I suggest keeping all file names friendly for UNIX or LINUX command line work. While most users today interact with file through file browsers built into the operating system or application, advanced users will rely on command line and scripted solutions to speed repetitive tasks. In UNIX, the only foolproof punctuation characters are underscores and periods. Anything else can and will cause problems. Escaping special characters will increase your in-house program development time AND errors will occur in file operations.
Avoid SpacesThe most famous special character to avoid, now widely violated, is the inclusion of spaces w i t h i n f i l e n a m e s. As illustrated, spaces can make things less understandable if overdone. You and I can read my little example, but a text parser will certainly not know what to do with it. While most software today, will tolerate a space in an asset file name well, but it only takes one application to puke and your whole naming convention is in the dumpster. If that application is your in-house back-up script, I pity the fool who loses a fi le with a space in the name.
Two periods maximumStick to periods to separate basename, sequence or frame number, and extension. Period. No extra periods. Extra periods will cause chaos with some software that expects the first period to denote the sequence number and the last (or only) to designate the extension. Period.
The hyphen – if you dareThe next one to risk –and I use the word risk with intent – will be the hyphen or short dash. The hyphen is tolerated well most of the time. But be careful, the hyphen in UNIX means command option. So while you can usually use it with safety, it is ill-advised because, like the space, it can break things. Pity, because it looks great in file names.
Use postScript NotationOther than underscores, the best way to separate words or concepts is what is called Postscript notation. It's now common in scripting languages, and to remind, it goes like this:
nocapitalCapitalCapitalCapitalCapital.extIn more words, don't capitalize the first word, eliminate spaces, and capitalize words that follow.
Postscript notation is great, but it breaks down when you have initials, and doesn't always read so well, and that's when underscores help out:
rGB_1stDetail_Layer.extYou'll notice that in this example, the “r” in RGB is lowercase. You can expect that users will violate the rules and make abbreviations like this all caps: “RGB_” at the start of assets unless you make the rule to keep leading abbreviations lower case:
Special EmphasisThere is no way to underline text in file names, but special emphasis can be achieved when necessary with doubled underscores. Notice how the word “1st” stands out in the next example.
#5 Protect Sort Order
Maintain ChronologyOften people will put dates in file names. When doing this, don't put the day ahead of the month or the month ahead of the year. Make sure all file names with dates will sort in date order by always putting them in year, month, day order. If you ever include time, make it follow the date. Never leave out the year because sooner or later, a project will cross over two years. (For short duration projects, you might be tempted to leave off the month, but again, think ahead....) Some examples:
comp_2010-10-14c.extThe last is a good example of when you might wisely use hyphens, if you dare. Note the use of double underscores in the first example. Note also that in the third example, the letter “c” follows the date. This is an excellent way to version date-named files, because it is distinctive and gives you 26 revisions with one character. (27 if you make “a” the second version.)
Variations and Passes after take or versionI cannot tell you how often I see labels identifying variations, particularly layers and render passes, before the version or take number. Almost always. Maya's built-in syntax machine does it this way, and, in my humble opinion, it's backward because it makes sorting on revision level break.
A render layer or render pass is always
Why this is important should be obvious if you are a compositor: you want the latest revision of each item. It is much easier for a compositor to go to the folder where the renders are placed, and get all the elements with the latest revision. If, assuming the compositor has been informed a new revision is ready, there are seven layers and only three new elements or passes, it implies that the prior revision is still valid. But if the version number is after the pass name, the compositor has to be more careful to collect all the right elements.
The final reason: it has to do with my next rule:
#6 Rendered Files Must Refer to Their Script
Asset Management 101 – part 5: Essential Rules of File Naming 7- There Can Be Only One