EddieOffermann dot com

I've been working on the spec for Big Blue Ceiling and thought I'd share at least an introduction to what the project will deliver. I've changed jobs recently (still in the vfx software/pipeline/td world) and that, among other things, has interrupted the project a bit but I'm ramping back up on it now.

Below are some thoughts on what a pipeline is and how I envision Big Blue Ceiling.  There is so much more to say, but much of it will have to remain unsaid until the project is closer to launch. I believe it will change the world and transform how and where we do business.

What is a visual effects pipeline?

A vfx pipeline is a collection of tools, processes and standards that permit and ensure the following:

-    Efficiency of communication of assets

o      Models

o      Animation

o      Camera data

o      Textures

o      Lighting information

o      Simulation data

o      and anything else necessary to assemble a given scene

-    Standardization

o      Filenames

o      Storage hierarchy

o      Version management

o      Tools

-    Show, Sequence and Shot Management

o      Structure

o      Dependencies

o      Assignment and Evaluation

A formal visual effects pipeline in a traditional effects house serves to automate the transfer of data by abstracting it. Separating camera characteristics, lens and movement data, from its strict representation inside the software package. Treating models, rigs and animation and separate elements that can be updated individually: for instance, animation may begin before a character design is finalized and the models updated on the fly, per shot or across the entire show without losing the animation data or requiring a complicated manual process to transfer that animation onto the updated model or rig.

On the compositing side, it may involve providing an additional set of facility-wide tools that standardize certain effects or provide a particular look.  Tools for grading and color management may be developed for the facility or the particular show and distributed between the artists to ensure that different compositors are able to deliver visually similar shots with minimal headaches.

For the entire facility, a formalized pipeline will ensure that assets and media are located with predictable names and stored in standard locations, along with maintaining project history and asset version information. If the last animation, the last comp, or last week's version of a model are preferable, it's easy to return to that version - often this can be made to happen at the level of producers without having to send the shots back to an artist to make the necessary adjustments.

What then is a cloud-based visual effects pipeline?

With the emergence of cloud computing, many common applications are moving onto a new platform: instead of being contained by a conventional desktop operating system or local server infrastructure, they are being moved onto platform-agnostic, internet-based hosted application clusters. Popular examples that many users are familiar with are such services as Google Docs, the office suite provided online as part of Google’s service offerings, or Photoshop.com, Adobe Corporation’s online photo editing and gallery hosting service. Medical information, insurance software, procurement & fulfillment systems, and tons and tons of software development have all left localized corporate infrastructures and moved onto the Cloud.

For visual effects and other CG projects such as animated features or game development, the process is a little more complicated. It’s still impractical to move software like Maya, 3D Studio Max or Houdini off of workstations and onto a web-based platform. Pipeline management has been complicated by the sizes of files that are often involved, but more recent developments in existing internet infrastructure have brought fast broadband into the range of slower local area networks, opening up the option of intelligent management and delivery of data by software such as Big Blue Ceiling. While many facilities are hesitant even to share projects with other facilities because of the combination of file transfer times and manpower overhead involved in delivering hard drives or preparing data before and after manual transfers over FTP. A Software-as-a-service or cloud-based system such as Big Blue Ceiling handles the typical database and project management aspects of a traditional in-house pipeline, as well as managing data for effortless transfer between facilities or between facility and remote artist.

What is a “Software as a Service” solution?

Software as a service (SaaS, typically pronounced 'sass') is a model of software deployment whereby a provider licenses an application to customers for use as a service on demand. SaaS software vendors may host the application on their own web servers or upload the application to the consumer device, disabling it after use or after the on-demand contract expires. The on-demand function may be handled internally to share licenses within a firm or by a third-party application service provider (ASP) sharing licenses between firms.

What is Big Blue Ceiling?

Big Blue Ceiling is a special subcategory of SaaS solutions referred to as SaSS (Software as a Secure Service). Software as a secure service (SaSS) is a derivative of software as a service. SaSS denotes a class of software as a service which emphasises security, not only in the link to and from the service, and the storage of any content by the software providing the service, but also in the security of the user in terms of the ability to make consistent backups and restores of any data stored in the service, in a non-proprietary format. In other words, security in transmission, storage and control over the user's own data.

In the context of a Cloud-Based Visual Effects Pipeline Software-as-a-Secure-Service, Big Blue Ceiling is a method of providing the sort of sophisticated visual effects pipeline normally restricted to larger, established visual effects houses, not only enabling it to be used by smaller studios but at the same time decentralizing it in such a way that it is as efficient for a group of broadly spread artists working in different locations as it is for a tightly integrated team of artists in a centralized studio.

Why would I be interested in a cloud-based, software-as-a-service solution for my visual effects pipeline?

The traditional rationale for outsourcing of any IT system involves applying economies of scale to the operation of applications, such that a service provider can offer better, cheaper, more reliable applications than companies can themselves. Several important changes to the way people work have made the rapid acceptance of cloud-based solutions possible and these changes are even more notable when we consider the visual effects community.

I.               High performance computers are widespread: Most cg & visual effects artists not only have a home computer but have one capable of performing functions far in excess of the basic needs of checking email and consuming online media.

II.             Processing power is a commodity: In the vanishing past, innovations in hardware were considered strategic advantages. From optical printers in the analog days to the first digital to film transfer processes of the TRON era, for many years hardware was king. More recently, proprietary applications and software tools were viewed as strategic. Today, people know it’s the business processes and the data itself: customer records, artist techniques, pricing information, and good effects design. Computing and application licenses are cost centers, and as such, they’re suitable for cost reduction and outsourcing.

III.           “Insourcing” pipeline systems requires expensive overhead including salaries, health care, hardware, software and OS management, liability and physical building space: not to mention unproductively reinventing the wheel!

IV.          Applications have tended to standardize: with a few notable exceptions, most people spend most of their time using standardized applications. A handful of standard 3d software packages dominate the market and they’re capable of exchanging data in a small set of standardized exchange formats. This means that a comprehensive solution for managing digital assets will work for a wide range of projects and facilities. Purpose-built, facility-specific pipelines should be regarded as dinosaurs.

V.            Web systems are incredibly reliable: Despite sporadic outages and slow-downs in the past, most people today are more than willing to use the Internet as a critical component of their business. As of early 2010, the visual effects community is behind many other information-related industries in moving out of centralized work clusters and into the cloud, largely because there has been no sound approach to managing the complex assets and often considerable data transfers involved.

VI.          Security is sufficiently well trusted and transparent: Secure communication no longer requires a complicated VPN setup or, worse, leased lines. Confidential client data can be handled even remotely with little risk.

VII.        Bandwidth of wide-area networks has grown drastically following Moore's Law (more than 100% increase each 24 months) and is reaching the bandwidth of slow local networks. Added to network quality of service improvement this has driven people and companies to trustfully access remote locations and applications with low latencies and acceptable speeds. Additional layers of asset data management by Big Blue Ceiling additionally boosts apparent speed of access while boosting quality of the artist experience.

VIII.      Cloud-based “Software as a Service” solutions have the effect of democratizing software, allowing small and medium businesses to have access to functionality formerly the domain of large enterprises. Big Blue Ceiling provides pipeline services at a level that small and even midsize companies could never afford to develop on their own, with a continually evolving set of tools and features unmatched even by in-house proprietary systems.

Who can benefit from Big Blue Ceiling?

Simply put, nearly everyone!

An entirely centralized studio can use Big Blue Ceiling and continue working as a centralized facility, leaving ongoing pipeline development to the Big Blue development team, regularly rolling out new features, support for additional packages and powerful artist tools, while letting the studio focus on creativity and project execution. And that centralized studio can rest easy knowing that if they need to expand, open up other locations, or cooperate on projects with artists and other facilities around the world, a set of tools are already in place for them to make sharing data completely effortless!

Smaller, newer facilities, perhaps formed just to accomplish a single project such as an animated short or independent animated feature can benefit enormously from a convenient slip-on pipeline like Big Blue Ceiling. It’s low entry cost provides world-class effects facility capabilities at a budget that nearly any production can absorb. Your cost savings just in artist hours transferring files and maintaining versioning, will easily exceed the entry cost of the service for small projects.

Loose collectives of artists will benefit from the Big Blue toolset as well, whether they’re seasoned industry professionals working purely for the love of the art or students collaborating on a project, access to the class of data management tools provided by Big Blue Ceiling should easily catapult any group’s efficiency.

Mid-size and larger facilities will find the toolset handy not only for their in-house work but for the ability to quickly and easily add artists in remote locations, or to easily permit secure access to their assets and production database by producers and vfx supervisors who may be offsite.

Additionally, tools that monitor times to complete tasks are able to chart them against production cost estimates, easily indicating unexpected burdensome cost centers, suggesting areas that estimates might be adjusted or manpower requirements reconsidered to adjust schedules. These are benefits that very, very few pipelines can provide, even in large established facilities.

Matrix math is a bitch. And it's nigh impossible to find any good resources online. Every "transform matrix tutorial" or "matrix multiplication lesson" online explains in detail how to multiply matrices together.

That hasn't been my problem for about 25 years now. I get it. This is how you multiply a matrix with a vector. This is how you multiply two matrices together. Neither of those things actually *accomplishes* anything if you don't know what the data in those matrices represents or what adding, subtracting or multiplying them would do.

My problems always center around something more like this: I have a point at <10,20,30> with orientation <15,30,45>. Where is the point if I rotate it 15 degrees in y then translate it 100 units in the X axis?

What's screwed up is that I've so frequently solved this by doing trig that I know off the top of my head that pi/180 is estimated at 57.29577951. Some people pride themselves on the number of digits they know pi to: I find the radian conversion number to be far more handy. But for reference, pi to me is 3.14159265. Note the 8 significant digits behind the decimal number: can you tell what decimal significance I grew up programming in?

The thing is, I'm working on a number of tools for managing stereo cameras in Maya. I need to quickly determine from the transforms of one camera (derived from a track of live footage) the location and orientation of a second camera if we know (or can estimate or otherwise determine) the interocular distance (the distance between the eyes) and the convergence (how far in front of these cameras their line of sight intersects). Determining the angle of the second camera relative to the first is a straightforward bit of trig: think Pythagoras and arctangents and it'll come to you, or go find a good trig reference online - this part's easily found in a million places. Diagram that out for yourself, making an equilateral triangle with cameras at each base corner with convergence being the length of a line bisecting the triangle into two right triangles. If it's not immediately clear, work on it a bit: it might wake up parts of your brain that haven't seen the light of day since highschool.

The tricky bit is figuring out where a right-eye camera would be if it was offset along a line that isn't quite perpendicular to the left-eye camera.

I'm very nearly there - based on a given camera, I can find a point offset along that camera's X axis and apply a convergence factor to the resulting camera location by canting it back in along the Y. But rotating a known transform matrix by an additional value in the y axis *before* doing that x translation... still fussing with that bit. I can make that happen less elegantly - by actually transforming nulls through space in Maya - but I'm searching for the magical transformation matrix that'll make it happen in a simple series of math statements.

It's late. It'll probably be plenty clear to me in the morning.

UPDATE: Got it! Sleep did wonders - my tired brain just didn't quite get the matrix arrangement right before.  I'll write an entry this weekend covering concatenated matrix transforms.  Damn handy.  Damn powerful.

I don't know where I read that, but it amused me and stuck in my head.

Hi!  I haven't been updating the vfx blog because I've been crazy busy.  Work has me deep in MEL and Python code most of the day, writing software to manage animation data, shuttle it this way and that and process it in interesting ways.  There's also the secret project that everyone isn't talking about but is quietly and excitedly waiting for (assuming they have any idea what it is).   We're on super-special-secret-lockdown at work, I'm guessing for the rest of the month.  I can scarcely go to the bathroom or grab a soda without passing through at least two security doors now.

Ok, I admit it, we've been contracted to create the lost tapes of the lunar landing.  Seems NASA has gotten enough flack about the original landing with people claiming they can prove it wasn't real that they've decided to create more proof to put the concerns to rest.

Or at least that's my amusing cover story until I'm allowed to talk about the other thing.

Between all the other little tasks, I'm in the process of working up a new tool for moving complex animation data around the pipeline.  The idea is to be able to read and write an XML file that contains as much data as anyone would care to put onto a model.  The model can be updated, have new elements added to or removed from it, all sorts of parts of that model can be animated at a whim by the artist and passed along to subsequent versions of the model, low res or high res versions, keeping all of the data intact, allowing for scaling of the animation data if it's transferred to a different model entirely, even passing along worldspace location and orientation of parts of the model (and maybe even eventually the full animation) to other platforms like Houdini and Realflow.

It's a little important for what we're doing on The Curious Case of Benjamin Button, but the existing tools I developed are working ok there (even if they're still a little limited and occasionally awkward - they're getting better on a weekly basis).  There's already a small test of what I'm doing in a broader sense: we have a particular element with a moderately complex rig on it that I'm publishing and subscribing the animation data on.

The Big Goal for this tool will be on T4 which we should be working on soon.  That'll be a huge show and we've got some really epic-scale work on it: most likely we'll be needing the more sophisticated animation tools for managing our data throughout the pipeline - so that's what I constantly keep in the back of my mind as I script the current version of the tools.  They need to serve the current project in the most complete way possible, and they need to be able to expand to do more than I'd currently dream of asking them to do.

It's a lesson that's come up recently because of a little tool I wrote that I've mentioned here before "CurveBaby" - CurveBaby allows me to take a scene with an animated camera and one or more animated objects, preserve the camera's relationship to one of those objects but change that object's animation - or, conversely, reanimate the camera and have the animation of the object automatically adjust to still look the same from the camera.  It's a powerful tool, and one that I can barely imagine how I'd get through half a day without using it at least once.

Big tools make big projects go a lot more smoothly.

I noticed the other day that my own 2d crowd generation software tool (DynaCyc) is ranking higher on google than Massive Software's listing for their incredible 3d crowd sim software.

In fact, if you google "Crowd Generation" there are two hits for my own websites before theirs comes up.

While DynaCyc is nowhere near as sophisticated for generating realistic behavior (it's more of a dynamic matte painting tool than a crowd generator - I created it for doing plants and trees to algorithmically make forests and such), it's pretty cool that I'm placing so well.

I really need to get the tutorial for my uv remapping tool recorded so that people can start using it. At the moment, though, I'm working 12-14 hrs a day, 6 days a week scripting some fancy animation pipeline tools.

The funny bit is something I've come to realize of the last couple days: while I fully grasp the minutiae of what I do, some of what I'm doing just baffles me in the big picture. I wrote a tool for "recasting" an animation from one space to another. For instance, if there's an object in a shot done during previs, and that original object has a particular animation on it, and there's a camera with a camera angle that we like... but the object itself is given a different animation in our scene because it has to fit in the "world" relative to other objects and be moving at a certain speed, reach a certain place at a certain time... I can take the camera motion from the original animation and transform it to the new shot maintaining the relationship between the camera and the element... while replacing that element's animation.

That's tricky... but I know how to make it happen and I've embodied it in a deceptively simple tool.

Separately, I worked out a method for stitching multiple animated shots containing a common object and many separate cameras together. The object's motion remains constant, and the cameras follow it along the path. Additionally, I developed a method for steering that element so that I can change its motion, adjusting the cameras to follow it.

That last one works using the first tool... so they end up all being connected to each other.

Once that happens, it feels like magic. I no longer understand the big picture: how we now have nearly a hundred separate shots stitched seamlessly together, but with different animation... and still working with the cameras and tracked objects matching to the footage? That starts to get away from me... I can conceptualize it as steps, as stages to reach a goal... I can break it down into its component parts: but the whole big process I understand only in that way: as big steps. I don't hold the whole thing in my head at once, though I use the tools that make it happen several times a day.

What's also funny is how much I'm even animating at this point... and I'm no animator, believe me. Let me write you a few expressions, though, and I can sometimes fake it.

I am officially in crunch...

It's mini-crunch, though, because we're just working to get things together for the trailer. Most of the staff isn't actually working overtime, but there's a few of us... the dynamics/fluid guys, an animator or two, the cg supe and me, piecing together the necessary bits to get the shots ready for the trailer.

I wish I could be a little more clear on what exactly it is I'm doing... When the trailer comes out in a couple weeks I can at least indicate then what segment of the film I'm addressing - I'd rather leave that part as a surprise for when the trailer hits (not to mention that talking about things like that would get me in hot water).

In a sufficiently vague sort of way, I can say that there's a segment I'm working on right now that's around 76 shots long, each ranging from 50-300 frames, that has a common element that's travelling between them. Our tracking team has been tracking that element, and its progress through each individual scene, for each of those 76 shots (and at least that many more as well that I'm not dealing with yet).

The particular task I've been working on is basically a continuity script. It's a MEL script that gathers all of that data: cameras, animated and matchmoved elements, and stitches them together end to end in a master shot. This way, the element that's moving through the scene will maintain an accurate location relative to the CG environment.

To coincide with what's happening in each shot, it's necessary on that big grandaddy master shot to make adjustments: turn something here, nudge something there... and that affects the path of that common element throughout all of the individual shots.

Do you see where I'm going with this?

Basically, if we imagine that I'm talking about a man driving a car across the salt flats in Utah (not at all what's happening in this film), there are features on the horizon that we want to be consistently and realistically moving in relation to the view of the car. If the driver swerves to miss a rock, we want to change the path he's taking across the salt flats (even though in the original plates, that driver would have been sitting in a stationary vehicle in front of a bluescreen, with some hydraulics underneath making the car tilt and sway to add realism). Our view of the car from the camera should stay the same... Car and camera must maintain their relationship... but the position, speed, orientation, etc of the car and camera combined will need to change. If there's a guy on one of those sail-carts out there, we need to make sure his path is realistic and that he's in the right place in the background of each shot...

Remember that the car, the driver, and the camera are often the only real things here... the sail-cart, other things on the horizon, in fact the entire salt flats... all are cg or augmented with cg.

So I've been developing tools for funneling data from all of these shots... everything from camera data to object matchmoves, world-space offsets for each shot, and animation data... stringing it together into a seamless master scene, manipulating the paths and locations of elements in that master scene and transferring that data back into the individual shots. If we need our hypothetical salt-flats driver to swerve this way and that across several separate shots, I'm making sure that it doesn't just "kinda look right" but that we can get that data integrated into the object and camera motion of several live camera plates.

If somebody didn't ask me if I could do it, I'd probably have never thought it could even be done.

If I'm kinda scarce around here in blogland, it's because I'm catching a much-needed nap in between long shifts.

but I ended up going in to work today anyway.

I'd agreed without thinking more than "yeah, extra cash would be nice" and forgot what had been looming.

Annoying project. I mean, the spot's going to look cool even if it's a little froufrou. But the details of making it happen are tedious and I agreed to come in and track which I haven't done much of recently and am starting to not miss at all.

So I went in, tracked, found out it wasn't *nearly* as annoying as I'd anticipated... and briefly wandered off into MEL scripting territory to make a button that places arbitrary geometry at the location and orientation of any locators or mesh vertices that you have selected as well as constraining the new geo to the locators in case they were animated. I may change it to orient based on the vertex normal. That might be more handy. It was irrelevant for this purpose though.

That's more interesting and is more helpful for everyone else.

Besides that, I've a thought in my head: My WordPress blog, while inherently "personal" is more along the professional side. Same with my facebook profile... A sizable chunk of my facebook friends are people I know professionally: so glittery graphic "thanks for the add!" and stupid pictures get deleted from my wall. casual banter is fine: but things I wouldn't do or say at work don't happen there either. I've started deleting comments that wouldn't be appropriate to yell out at me at work. If you leave a comment that gets deleted: I'm not mad at you, I'm just not going to embarrass myself on anyone else's behalf.

Myspace is a filthy pit anyway, so I'm not policing it yet. Professional contacts on there are incidental, but I'm probably going to clean that mess up soon as well.