EddieOffermann dot com

I've been doing a bit of coding specifically to make it easy for Big Blue Ceiling to be deployed into a facility that already has an established file structure.

By itself, this is a natural approach - and not that complicated. Because everyone with *any* sort of organization will have arranged their projects by job and by shots on that job, even though the exact heirarchy may be different it's easy to predict where the *gaps* in that heirarchy may exist and allow those to be configurable by the end user.

For instance, Company A, using predominantly linux machines may have a path to their publishing directory like this:

/FACILITY/cg/PROJECT/SUBPROJECT/shots/aa010/pub/

Company B may use a path on their Macs more like this:

/Volumes/Share/projects/PROJECT_SUBPROJECT/shot/aa010/publish/

It's not exactly brain surgery to identify that in the first case, the meaningful root directory is "/FACILITY/cg/" and in the second it's "/Volumes/Share/projects/" - then there's identifying the delimiter between "show" and "subshow" or "campaign" and "spot" or whatever your nomenclature is for project & subproject info. Maybe they're grouped as folder/subfolder, maybe they're companion folders.  Maybe there's no concept of "subshow" at the facility and we can treat both the delimiter and the subshow as empty.

But this got me to thinking: what I'm doing is creating a visual effects pipeline that is essentially filestructure agnostic.

A large part of a formalized visual effects pipeline is putting the filesystem behind an abstraction layer from the user.  Camera data moves along from artist to artist with each artist knowing nothing more than what shot they're working on. Someone will have specified, early on, what assets will be needed in the shot: ideally, when the shot comes to the animator, they pop open Maya and click a button that makes it populate their scene with the camera, models, set geo, rigged characters, etc.

They don't need (nor do they really want) to know that the model is called "candyBarDancer_v09.mb" and it's stored in "/Volumes/Share/projects/CANDY_DANCE/shot/cd090/publish/rig/".  They don't need to know it, they don't want to know it, and I believe they shouldn't even be *aware* of it because that information is nothing but a distraction from what they're trying to do.

When they're done, they can save a copy of their scene wherever they like for their own edification.  But the data needs to travel to the next artist - and they shouldn't have to tell the next artist where they saved it: again, they shouldn't even *know* this information because the data that gets written out isn't directly usable by them anyway. It's the formal vfx pipeline toolset that manages the handoff and makes sense of the data. Not the artist.

When the pipeline is properly structured, it's perfectly reasonable for multiple artists to work on the same shot at the same time: all the while getting regular updates of animation being done by other artists, receiving model changes relevant to their scene, etc. - all without having to be conscious of where this data is coming from and without having to do anything more than click an "update scene" button.

But here's the big deal!

By building the pipeline software itself around a filesystem agnostic abstraction layer, it allows us to link up established remote facilities. Company A in Los Angeles and Company B in England could be working on the same shots on the same shows, can still actively collaborating using something like Big Blue Ceiling coordinating between their facilities. The fact that their filesystems may have different naming schemes and different heirarchies, even calling the job and shots by different names, isn't going to affect their ability to actively communicate with one another.

Think about it: you have a small studio in Santa Monica and you're working on a medium budget feature with only a handful of effects shots. One of the sequences, however, needs a large set extension and a matte-painted cityscape in the background. You task your team to get to work on the foreground elements of the set extension and contact a small studio in Austin, passing along the requirements for the elements and having them install the toolset for using the shared effects pipeline. They can easily fit it into their filesystem and in no time, they're up and running.

As your artists work on the foreground elements, they register with the system to receive notifications as elements are updated. They click a shelf button to update their scene and as they build the foreground, they see the background elements and matte painting slowly taking shape: right there in their scene.

There's no messy FTP'ing of files back and forth, and no complicated backend server synchronization to set up. They don't even use the same file heirarchy: but that doesn't matter because structure and naming conventions are handled by the pipeline software, not the artists, so there's no confusion.

This is the promise of truly good pipeline design.

And Big Blue Ceiling is going to make that a reality.

As long as we're here, let's take a look at a commercial that I look on fondly, because a lot of what's described above I already wrote once when at Asylum and was used to create this spot.

Name (required)

Mail (will not be published) (required)

Website