I feel that scripts and software made for internal use should follow the naming convention of ‘nounVerb’. This provides a number of benefits such as people can easily remember the names of your tools, they are easy to find, you can use tab-completion, etc…

Some possible examples for names of tools that work with images:

dpxView
exrView
imgConvert
imgCrop

It is important to remember the differences between the two.

Here are the definitions for each, courtesy of Dictionary.com

con·sen·sus (kən-sěn’səs)
n.
1. An opinion or position reached by a group as a whole

col·lab·o·rate (kə-lāb’ə-rāt’)
intr.v. col·lab·o·rat·ed, col·lab·o·rat·ing, col·lab·o·rates

1. To work together, especially in a joint intellectual effort.

In a dynamic environment such as production, a culture driven by consensus generally sacrifices speed for constraints (and meetings).

Whereas with collaboration, you work with your colleagues towards a shared goal. Each individual may have their own opinions of how the goal should be achieved, but as long as the end goal is met: it works well, in an efficient manner, is easy to integrate and can scale well, then the methods of implementation are secondary. A risk you must manage to avoid with consensus is ‘trying to please everyone, but not completely pleasing anyone’.

Consensus does have some advantages. It can result in a more well rounded view and solution of an issue. And when developing software/projects in a waterfall style method (vs agile) it may be quite favorable. The waterfall approach allows for planning ahead exactly how everything will be done and reaching consensus.

But, I have found that for groups such as production engineering, the agile/collaboration approach tends to work best.

On core R&D development, the waterfall/consensus approach can work well, but I have seen the agile/collaboration work well on these type of projects as well.

All key people (especially the end-users and clients) should always be given the ability to provide input. One best practice that I have seen in the collaboration process is to assign each person involved in a project an area of focus that matches their expertise. This person is the owner of their area, and it is their responsibility to facilitate all of the input and feedback, weigh that against their own knowledge and experiences and propose a result that is in their best judgment the right way to proceed.

Directory Structure and Naming Convention

An organizational structure for job specific tools, shot, and asset groupings. Naming conventions provide tool repurposing and the ability to structure assets.

Variable System

A variable organizational structure to share job and shot configuration information among tools which provides:

• Naming convention control

• Tools standardization and version control

• Tools pathing

• Shadow tree management

• Filename repathing

• Image resolution control

• Sequence and shot override control

Asset Management System

Assets contain data that describe the geometry; the behaviour of that geometry (rigging), texturing, and rendering properties. Assets are brought together into scenes and shots which are controlled by an Asset Management System. Assets are grouped into different types in which they share common attributes. Each production department uses the Asset Management System to access assets in a common manner.

Revision Control and Distribution System

A set of tools that control versions of animation data and the distribution for production and rendering workflow. This system allows production departments to work independently of each other without overwriting each others files. Files are merged back into a common master tree and redistributed for updates to other departments and segregated rendering.

Job Navigation System

The Job Navigation System provides all users the ability to traverse the large directory structure required for an animated feature efficiently. It also provides concurrency across all production trees.

Production Tracking System

The Production Tracking System provides production management the ability to track assignment of shots to individual artists, follow the progress of each shot through production, and assures that on each shot any necessary changes or follow-up work are completed on schedule.

Every time that I’ve started working on a production, be it a film or video game, the issue of naming comes up. Nobody likes the way things have been named on previous productions, and yet no one wants to be the person that creates and enforces a naming convention. Can you blame them? It’s never fun to be the person who has to put the figurative “smack down” on a production team to get them to name things correctly.

Naming conventions can have various levels of stringency. The most basic of naming conventions covers just the characters used to name files and directories in a production tree. A step beyond that could be setting some rules for naming files of a specific asset-type. And so forth. I imagine with some effort you could cover most every file in the production.

So what is a good balance between the chaos of having no naming conventions and the draconian restrictions of too many? Before addressing that let’s take a look at why naming conventions are necessary.

Why Have A Naming Convention?

Here’s my answer; so that the production can run smoothly, efficiently and focus on the creative issues of the product instead of the minutiae of the production processes.

Does a naming convention really do all that? No, not by itself. However it can help to create an environment in which you can have an efficient, smooth and creatively satisfying production experience.

The most basic benefits of a naming convention include:

1. Makes the naming of files and directories easy and predictable.
2. Becomes easier to deal with a large numbers of files and directories in an automated fashion (e.g., batch scripts).
3. Facilitates the transfer of assets between productions.

For a large production the second benefit would be reason alone. The automated processing of data is critical. Whether you think you will or not, you will be, at some point, automatically processing some or all of your production data. A naming convention will greatly simplify the scripts that you will have to write to perform the automated processing.

There you have it: a strong, compelling reason for instituting a naming convention. The next step? Figure out exactly what the naming convention should be!

What Should The Naming Convention Be?

All files and directories should contain only lowercase letters, numbers, and underscores.

This is the minimum basic convention that you should employ. Even this simple convention can help considerably for technical tasks, like those involved in the automated processing of data.

* Files and directories are sorted consistently.
* The generation of file and directory names is straightforward.
* The parsing of file and directory names is straightforward.
* Regular expressions won’t require complex quoting of special characters (which is often a source of bugs when writing regular expressions).

This can also have a positive impact on your production team.

* Separation of words by underscores is easy to read. It is a natural mapping from words being separated by spaces.
* It is easier to deal with a large volume of files visually.
* It is easier to navigate directories of files for someone whose first language is not the same as the production team’s predominant language. In the realm of video games this can have considerable impact on the effort it takes to localize the game for another country.

For the productions I’ve been a part of, this simple convention, coupled with asset organization conventions (more on those in another article), make the development of production scripts straightforward. Wouldn’t you rather spend your time working on a practical production issue instead of figuring out how to locate the data?

You can extend this convention beyond what characters can appear in file names. However, you should have a solid reason for anything beyond the basic convention. The danger is in having so many conventions that people can’t remember them all. You can publish the conventions all you like, but if a majority of people can’t keep them in their heads then they won’t get followed.

One of the most common places for extensions to the naming convention is in the various production disciplines. Modelers, animators, lighters, texture painters and FX developers all have workflows that are tailored to what they work on. It follows that you would build upon your basic convention differently for each discipline.

When you want to extend your convention ask yourself these questions:

1. Does it make it easier to write production scripts and tools?
2. Does it address an area where asset naming is inconsistent or inefficient?
3. What effort would it take to deploy the convention? Don’t forget about the time required to train the users on the new convention. There will also be additional support issues during the transition period.
4. Do you already have more than 5 or 6 conventions in place for a particular production discipline?

Answering these questions should help you to refine your reasons. There are no hard and fast rules. Trust your instincts. Only you know your production and the people involved with it.

If your production has never had a naming convention, start with the basic convention. Just getting your production onto that convention will be challenging. Once you have that solid base you can begin extending your convention where it makes sense.

Automated Enforcement vs. Social Pressure

Once you can get a team to agree on naming conventions, then the next question that comes up is how to enforce those conventions.

Some level of technical enforcement is typically the initial approach.

* Write all your scripts so they name files and directories correctly.
* Have scripts stop processing or “error out” if files or directories aren’t named as expected.
* Create scripts that build placeholder structures for your assets, complete with correctly named files.
* Have your asset management tools enforce naming during the importing of files and directories.

The other common approach is via social engineering.

* New user training.
* Ongoing production training.
* Peer guilt.

Where do I stand? I am always in favor of technical enforcement when it makes sense. Technical enforcement should serve to remind people of the correct conventions. It can, however, get to be fairly complex to manage. I would suggest putting your logic for naming conventions into a common library or module. All tools can then leverage this common code. Additionally, writing code to enforce your conventions is the best way to understand the complexity of your conventions.

I feel that in the long run social engineering will give more lasting results, especially if the studio takes training seriously. Productions really shine when they have a strong training program. New users are more productive faster and understand the production processes more completely when they get good training. Naming conventions (along with asset organization) should be the cornerstone of any production training curriculum. With ongoing training all users will know what the conventions are and why they are important.

When used in conjunction with technical enforcement and training, peer guilt can easily get you 99.9% compliance with naming conventions. There is no better reminder than having your cubemate turn around, tap you on the shoulder, and point out how your misnamed file broke her automated processing script!
So Get To It!

You should now have enough ammo to go to your manager and request the time and resources to help get a naming convention in place. The time you save during production will greatly outweigh the time you spend getting a convention up and running. Time is money to a production. Nothing makes a producer’s eyes light up like saying “We are ahead of schedule!” And you will have your naming convention to thank.

–kev

Editorial support from Steve Carter, Marlon Montgomery and Courtland Townsend.

Montgomery simplifies pipelines and workflows at AITF

Industry gives two thumbs-up to AnimationXpress.com AITF, presented by Intel

CG Animation Studio Essentials by George Bruder & Marlon Montgomery

The Anatomy of Production Pipelines

• the best animation business books of all time
• the best management books of all time

This is a first-draft list.  If you have any suggestions please feel free to add them in the comments of this post. I haven’t attempted to sort them or rank them yet; the order is completely arbitrary.

There are a variety of factors that need to be taken into consideration across all areas of the studio’s business.

One of the first items that should be nailed down is how your staffing requirements align with the business, production, and technical goals.

• Are you going to be using production processes that require artists with a higher degree of technical aptitude and/or an investment in training? Or, are you going to adapt your toolset and workflow to be more ‘artist’ friendly. What is the local talent pool available to you?  Are your skillset requirements realistic?
• Does your studio intend to use project based hires or plan to retain artists for the long-term? How does this affect your training requirements? What is the learning curve required for new recruits? Will you be able to use proprietary tools in a project based hiring paradigm?

You must ensure the effective use of network and storage technology to enable efficient data access and boost artist productivity. Your workflow, pipeline, and infrastructure must allow for quick shot production (in large scale), without bringing your network and hardware to it’s knees.

When designing your pipeline and toolset, you will be best served taking a modular and adaptable approach. You will want a system that can easily adapt to a variety of styles and looks as you move from project to project.

You will want to have a system that can be easily replicated, as your studio may grow to handle multiple simultaneous projects, have multiple work sites, or face a need to work with outside vendors.

When making the buy vs. build decision for your toolset, you will want to consider the business ramifications of making yourself dependent on 3rd party vendors. In turn, does building your own tools provide any competitive advantage or cost savings in the long term?

Inevitably in a team, disputes sometimes occur ranging from minor differences in opinion, to fundamental differences in ideology. It is my job to handle such disagreements constructively, ensuring that the team remains focused on achieving its goals. I always encourage people to stand back from any disagreements and look at things objectively. By doing this, any differences between the team can be more easily resolved and possible conflicts can be avoided.