Comp-Fu Answers Part 3

More recurring search terms that have led people to my blog!

optical flares for fusion


what the user wanted
what the client wanted
what the customer wanted

I think you’re all after the same thing┬á­čÖé


source: unknown

vfx naming convention

Now, this is actually quite an interesting topic. I’ve worked at a dozen small to medium companies as a freelancer and one thing’s for sure: everybody does it differently. Some places even opt for a content/asset management system that allows artists to name things the way they want. Only when checking something into the database, files will get tagged and renamed.

For the rest of us, it’s probably enough to have a naming convention that works on the file system as it is. This is usually done by combining so-called “tokens” via underscores (“XMEN_04-100_comp_v012.0001.exr”). Depending on the departments you have and whether your project’s shot are split up into sequences, things differ wildly. However, here are some best practices. Interestingly, all of them are just workarounds for the fact that file systems and the file managers that come with each OS are really, really bad for VFX work. So the database-driven CMS isn’t such a bad idea after all ­čÖé

Rule no. 1:

Write scripts that take care of file names. Every time an artist has to enter a file name or – heaven forbid – create a directory manually, chances are he’ll fuck it up. Scripting is easy for compositing or 3D apps, but a nightmare for AfterEffects, Photoshop or e-Mail attachments.

Rule no. 2:

Don’t over-engineer things by stuffing everything into a file name. That’s what metadata is for. But do make sure you can figure out where a file came from just by looking at its name: call it the same as the scene/comp/script that created it and then some but think twice about adding a department code, artist name, image size token or color space info to every frickin’ file name.

Rule no. 3:

Adjust to your file manager’s capabilities. They suck on every OS but even with an asset management system in place you’ll want to browse directories sooner or later. This means files should be easy to find and sorted logically:

  • General strings first, then get more specific as you add tokens to the file name. It’s better to do┬áshot_task_version┬áthan artistname_shot_version.
  • Dates should be written as YYYYMMDD so they sort correctly.
  • Version and frame numbers should have a fixed amount of digits, padded with zeros (e.g. v003)
  • One file sequence per directory, named the same as the directory it’s in. Exceptions for multi-pass renderings (put em all in one folder) or multiple output resolutions of the same shot (split into subfolders like “jpg1080p” or “hd_exr” so the files themselves don’t have to contain this token).
  • A new version of a file (rendering/comp/animation) should only differ in one predictable place: its version number (which may occur multiple times if you consider the whole path name as well). That makes scripting easy and allows versioning up in Nuke. If you put a comment token or artist name somewhere in the path name (\SHOT100\Spaceship\renderings\v005-newShading\…), you’ll need to write smarter pipeline scripts for no good reason.
  • What happens if somebody accidentally moves a whole directory somewhere else? If you have a directory named “Shots” in every project folder, you can even wipe out a whole project on MacOS (drag “Shots” from one project into another and blindly click OK). Windows and Linux are not prone to such a major disaster but if you merge two shot folders have fun untangling them.┬áBetter use a short, project-specific prefix for the 2nd or even 3rd level directories inside a project folder.


Comments are closed.