A Rose By Any Other Name
“Decades and decades of using different pipelines and I still can’t just rename an asset!” an exasperated VFX Supervisor once vented to me. “Why is this so hard?”
I mean, shouldn’t it just be a matter of changing the file name? Or a directory? Or maybe tweaking a row in a database somewhere? Easy peasy lemon squeezy, right? Well, no. In fact, to quote the film In the Loop, it’s “difficult difficult lemon difficult.”
Naming things well is widely accepted as a challenge, but renaming things poses its own set of difficulties.
- Each production asset needs to have a unique name which identifies exactly one asset.
- Throughout the pipeline, this unique name will be used to refer to that asset in order for everyone — every computer and every human — to agree on which specific asset is being talked about.
- Changing the asset’s unique name in one place will break references anywhere else that is still using the old name.
And yet, here’s the kicker…
- People often want to change the names of things.
So, sure, that VFX Sup could have changed the name of the asset file or directory from “sofa” to “couch” or something, but then every reference to “sofa” throughout the show’s production data would be broken and production management would have been apoplectic that all work on “sofa” seemed to have suddenly ground to a halt and unscheduled work on something called “couch” was now skewing their planning scenarios. All that trouble just because a human preferred one word instead of another.
Let the Computers Win
Computers would be perfectly happy if production assets were only ever referred to by Universally Unique Identifiers (UUIDs). For example, instead of “sofa” or “couch”, 74fbd636–4fc5–11e9–91a2-ecb1d74481b4 could be referenced everywhere throughout the lifetime of the show and would always refer to the same thing. But then that VFX Sup would be complaining about how he keeps having a hard time differentiating 74fbd636–4fc5–11e9–91a2-ecb1d74481b4 from e67339d0–4fc5–11e9-b769-ecb1d74481b4 when he sees them embedded in files. It’s a similar case to how networks don’t mind speaking in the language of IP numbers, but users much prefer having DNS so they can speak in the plain language of URL names. Considering the tempo of production, sometimes a human needs to be able to quickly open a file, read it, and have it make sense. Perhaps “human readable” should be a consideration, but a consideration which drags in a new set of difficulties.
No, Wait, Let the Humans Win
The term “reference” means a thing that refers to something else. That other thing that is being referred to is called a “referent”. It’s like a finger pointing at the moon: the finger is the reference and the moon is the referent. A hexadecimal string can remain immutable because it’s only utility is being a pointer to something else. It’s a reference to a referent. That’s all it does. The reference doesn’t carry any extra meaning in or of or about itself. It just points.
However, human language is much more complicated than fingers or strings of hexidecimal. Words carry additional information about themselves, not just about what they refer to. In the fancy terminology of semiotics (the study of signs), the pointing finger is called a “signifier” and the moon is called the “signified”. What the signifier points to is its most basic level of meaning, what’s called its denotation. But the signifier can also have secondary meanings attached to it, surrounding it like a cloud or a web of other ideas. These are called connotations. Consider the differences between these asset names:
- couchA
- Jennifers_couch
- dilapidatedCouch
- couch_leather_overstuffed
- heroCouch
- davenport
- cuochA
Each name gives a human more hints about that thing than just where to look for its files. The names themselves hint about the kind of couch or its condition or its owner or its material or its importance. (That last name even hints that someone types with fat fingers!) Computers don’t care about these connotations, but people find them really useful and helpful.
Okay, Let the Humans Win But Be Strict With Them
If we want the advantage of meaningful, human readable names, we could institute policies and processes that forbid renaming. We could insist that whoever names something is taking full responsibility for establishing a permanent, irrevocable name. So, they should be sure to, as the old carpenter adage goes, “measure twice and cut once.” No take backs. No do-overs. The downside of this option is that your coworkers will hate you when one of them invariably makes a minor mistake and it can’t be fixed. And, unfortunately, lots of things can change during the lifecycle of a show.
Alright, Let the Humans Win But Be a Little More Forgiving
We could institute a system where names are permanent and immutable, but we allow for new names to point to already named things. Someone could create the asset “cuoch”, realize their mistake, and create a new name “couch” which points back to the old name “cuoch”. The old name and the new name would be co-referential. Anywhere the old name was used would still work, it would just be ugly, and the new name could slowly propagate throughout the rest of the show. There are two problems with this approach. Aside from the general confusion of having a single asset referred to by multiple names, you have burned the old name so that it can never be used again in the future. If the character “ashley” is changed to “ashanti”, we can never add a new character named “ashley” because that name is technically already being used.
Fine, Let the Computers Win But Let the Humans Think They Win
We could use UUIDs for all assets but then associate a unique human readable label with each one. The label could be changed to different values without affecting any of the references throughout the production data, because the production data would use the human unfriendly UUIDs for their references. People still won’t be happy seeing hexadecimal strings whenever they crack open a file and try to read it, but maybe we can get away with that if we make them a tool that easily dereferences those UUIDs to the current label and hide the UUIDs from them whenever possible everywhere else.
Making the Hard Decisions
There is something of a fault line which runs between production management and artists on the floor. Each side has their own needs, workflows, and sometimes even vocabularies. Technology straddles that fault line. Here at Blue Sky Studios, production management uses Shotgun to schedule and track all production work. However, we have been writing our next generation pipeline, Conduit, to manage the underlying production data. Naming changes on one side have ripple effects on the other side. What this means for Conduit is that naming choices made in Shotgun will become embedded — or, perhaps, fossilized — in our Pipeline Resource Identifier (PRI) strings which will, in turn, end up in production data files. Making these PRIs semi-human readable was chosen over using more flexible but less friendly UUIDs. We may revisit the need for name forwarding, name labels, or aliases of some kind in the future, but for now we’re encouraging disciplined naming. There’s no perfect solution. All anyone can do is try to make the most number of people as happy as possible, as much of the time as possible.
