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.

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.

It's been a while since I updated here, but I thought I'd throw out a tidbit from something I've been working on.

Part of any vfx pipeline project involves making your different software pieces communicate with each other. Part of that, of course, is being able to write common file formats. Sometimes that's for sharing generic data, such as through XML, or basic channel information that can be written to a tab or space-delimited text file sometimes referred to as a chan file.

Other times, though, you'll want the packages to communicate more intimately, and Maya provides a method to closely integrate different software packages with it as long as the other packages have the ability to do port-level communication. If you haven't written IP protocol software before, this can be a little daunting, so I'm going to share a couple short code tidbits that'll make talking to Maya a little easier. I'm assuming some basic MEL experience, and some background in Python wouldn't hurt either, though you should be able to follow along with any amount of coding background. I'll be skipping the tedious details though, so if you need a programming refresher that's beyond the scope of this post.

First, you'll want to pick the port that Maya is going to listen on. For my example, I'll use 7777 - basically because it's not used by another widely used protocol, and because it'll be easy to identify in the example code.

In Maya, either in the script editor or as part of another MEL script, you'll want to execute:

commandPort -n ":7777";

Now, this will open a port on 7777 which I should give you a little warning about: ANYTHING that is sent to that port will be executed by Maya, as long as it is running, and until that port is closed. This includes quitting maya, saving or deleting your scene, or even executing system commands. So you may want to have the data coming across that port filtered by a MEL procedure first, or passed to a command. In that case, you'll want something like this:

commandPort -n ":7777" -pre listenOnPort;

In the former case, anything you send to port 7777 will be executed by Maya. In the latter case, you'll want a procedure like:

global proc listenOnPort(string $argv)
     {
     string $args[];
     int $argnum=`tokenize $argv $args`;
     // Code to process $args should follow here...
     };

Now of course, you need some way to communicate with Maya. This is where it's actually a little tricky - since you'll need a socket client to issue commands. I'm providing only the most basic example: this one is asynchronous and one-way only. There is no way for this routine to receive any feedback from Maya.

#!/usr/bin/python2.5
import socket
import sys
HOST = '127.0.0.1'
PORT = 7777
CMD=sys.argv[1]
try:
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
except socket.error, msg:
    sys.stderr.write("[ERROR] %s\n" % msg[1])
    sys.exit(1)
try:
    sock.connect((HOST, PORT))
except socket.error, msg:
    sys.stderr.write("[ERROR] %s\n" % msg[1])
    sys.exit(2)
sock.send("%s\n" % (CMD))
sys.exit(0)

By calling:

talktomaya.py "select -all"

You will be able to send the indicated command to Maya to be executed, or in the case of the -pre example, pass the command to the procedure for parsing.

More sophisticated implementations may require sending to machines other than localhost (127.0.0.1) as in the above example, and that's left as an exercise to the reader. It's a simple matter to send commands to a range of machines across a collection of IP addresses. Examples of this might include having individual users register their interest in a particular piece of data - and when that data is released, those users are notified automatically that the data is available, say an updated model or a revised animation, and giving them the ability to then update their scene with the new data. It might also be useful to centrally request an update from all users who are currently working on assets required for a particular shot - and obviously many other options are available when you can communicate directly with the maya instance of each user in a facility.

The tricky bit is that I hadn't seen a clear example of a script to send instructions to Maya - and there it is, in its most basic form.

I just read that Ubisoft bought Hybride Technologies - a large video game company buying a medium-size visual effects house.  The article had a lot of talk about the future of video games and movies and seemed to miss the point when it quoted recent reviews of "Beowulf" that said it was like a "long video game scene".

The point was that wasn't a positive statement...

But it got me thinking: there's been so much talk about how video games will become as good as movies - and it's a pet peeve of mine that writers can be so ignorant.

What??? You say?

Sure.  Video games will eventually look as good as what you see when you go to see Hellboy this weekend.

But when that happens, movies won't look like that any more.

Now eventually, and we're not talking in the next year or two, we're talking a decade down the road perhaps, video games will start to look a lot like what you see when you walk outside (except of course that there will be zombies or terminators in the video game and may or may not be killer cyborgs and diseased undead prowling your real-life neighborhood).  By then, feature films may well be predominantly 3d - but your video games probably won't be.  Another five or ten years and then maybe the playing field will be levelled.  Except that the movie theaters will have vibrating chairs, a better sound system than you're likely to have at home, misters and blowers and scent generators, actuators to lift and tilt the chairs.  Oh - and even better 3d and higher res displays than consumer televisions can deliver (what, you thought HD was the best it got?  Please.  Not even today.  But don't count on a 4k home television standard any time soon.)

Oh, and their screens will always be bigger than yours.

The constant talk about video games 'replacing' movies on some level just sounds like people talking 100 years ago about radio replacing books.  The internet hasn't even replaced books - though it has put printed encyclopedias out of business, but then how many people ever kept a consistently updated set of encyclopedias in their homes?  If you ever even owned a set, chances are you owned one that still talked about the USSR and the apartheid government of South Africa.  If the internet replaced *that* bookshelf dominating monstrosity, I'd say that's not even surprising.  Public libraries had been replacing private encyclopedias for decades already.

Ubisoft's purchase of Hybride is motivated by the same thing that's making companies like Digital Domain say they want to get into video game production: fear. The fear that they won't be prepared if things go that way.  The fear they're going to be missing out on something.  They see something like the release of the new GTA and it looks like video games are the road to making billions.  It's just not true, any more than a small multimedia house in New Orleans should look to Wall•E as the future of their company.  Ubisoft doesn't need Hybride to understand how to make better CG. And the guys at Hybride probably can't help much with getting their ideas into the game engine: because that's an entirely different discipline.

My point is, video games will change.  But I don't think they'll "converge" with feature films any more than television "converged" with feature films.  Television is still a poor substitute for going to the movies and as much as we make the decision to sometimes catch something when it comes out on television/pay-per-view/dvd/bluray/what-have-you, as a society the rise of television has done nothing to diminish movie attendance.  Now we just expect more entertainment, and predominantly entertainment that we can enjoy just by sitting on our ass with a bucket of popcorn in our lap or a plate of nachos on the coffee table and no video game controller anywhere in site.  A theater full of people aren't going to be strumming their Guitar Hero guitars or thrashing around with their Wii controllers, and next year's Batman installment isn't going to require you to learn to drive the batmobile.

Unless of course you want to.

I was talking to a friend today about what I'm doing with regards to managing data through an animation pipeline using XML. The more I work with it and the farther I get into the project, the more flexible and powerful the whole thing seems. Of course the goal to doing the implementation in Python is that virtually every software package in the vfx industry is python-friendly - so once the core routines are written, everything from Nuke and pyShake (the python plugin for Shake - if you haven't seen it yet, check it out here) to Maya, Houdini and RealFlow will be able to make use of them. I think most places are doing that these days, with a few nods to TCL/tk here and there - but broadly supported scripting languages are King and open description formats like XML are Queen.

My friend marveled at how nice it would be if one day, a couple years from now, everything was able to talk that smoothly: that a character animated in Maya could be pulled into Houdini, for instance, as something other than an OBJ sequence or a separately rigged character that you had to tediously (or with a lot of specific coding) link to exported channel data.

I wonder if that interoperability thing will ever extend beyond each individual studio's implementation. Everybody has a way of getting software to talk amongst themselves, some solutions being more elegant than others, but when you invest in creating something as elaborate as this it becomes your own proprietary tool. If you develop a tool that an animator can take an animated character with a complex rig on it, arbitrarily select additional elements that were never *really* meant to be animated and animate them anyway, and the modeling team can modify the model and issue a new version of it - and the animation gets seamlessly transferred over to the new model, even able to be read into RealFlow, substituting a different set of low poly independent objects that are driven by the data in that XML file: you don't put that pipeline tool on the internet for everyone to download for free.

That tool becomes your secret weapon. As a studio with an investment in a powerful and unique proprietary tool, even charging for it may not mean as much to you as the edge you gain during the heat of production.

Being XML based and implemented in Python does put my current project a wee bit closer to being an open standard, though. Even Shake will take Python scripts now - and they're really powerful in it and getting more so as development continues. The readability thing for XML is a gigantic plus, and the way it represents data is great. I can build a module that will write out the translation of a locator in both world and local space, as a baked set (every frame has a value) and as a set of keyframes (values only for those frames where the value was explicitly set by the artist), as well as screenspace UV values - so the same XML file could reconstruct a scene for a lighter to light and render from or another animator to tweak the animation curves, or for RealFlow to drive low-poly proxy objects with to disturb a drifting mist, or for a compositor in Toxic to link an effect to. And it's all one XML file - not a half dozen formats (often multiple versions of each) and a hundred-unit sequence of geometry exports.

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.

After a fairly exhausting week, tonight was my night to really kick off a weekend... and what better way to kick off a really world-class weekend than to go see an old friend perform with a band in Hollywood?

Went to Relax Bar out into the sorta sleepy grungy part of the Boulevard of Broken Dreams (better address and directions at the link above)... Weird little venue, that. Meredith and I both were having college flashbacks of places we used to go hear bands back in the day. Difference for her was that here she was performing in one.

That Meredith would be Meredith Meyer, who some old Orlando friends of mine may know. It's not every day you find someone you've known in a different place and time that's found a working niche for themselves elsewhere - but there it is. It was exciting to me to get to hear her tonight, and doubly good to see and hear just how beautiful she sounds live. Am I gushing? *shrug* Maybe. But it's deserved.

I'd love to go on more about the evening: it was excellent. Found another couple bands that I really enjoy hearing live. The whole night was good, but a couple of those bands were ones I'd go hear again and again - and in a city packed to the rim with excellent bands, that's saying something.

As I'd mentioned before, this blog is going to get more technical and I'll be spawning off a personal blog shortly. For now, bear with me non-technical readers: I'm about to talk geek for a bit. When I was teaching at FullSail, a lot of my "curriculum development" time, as well as a substantial portion of my free time, was spent doing R&D on advanced topics - things that are done at a handful of visual effects studios around the world, or even things that nobody was doing yet except in university settings.

Things like relighting using what's called a bent normals pass (a special render pass that contains information about the direction a point on the face of an object is pointing) - a process that enables you to gain a fair bit of control over how the rendered object appears to be lit, long after the frames have left the render farm. Other experimental tools like an algorithmic forest and crowd generator, or today's topic: retexturing in the comp, instead of at rendertime.

There are a couple of tools for doing this already: basically, you render out a diffuse color pass, full intensity colors, no shading, but instead of finished shaders, the elements are textured with these especially bright and colorful red/green gradients. The color of each pixel corresponds to its relative location on the UV map, so even after the texture is wrapped around an object and that object viewed from an arbitrary camera position, each pixel still holds information about its original position in UV texture space.

Now, most of the tools I've seen for this sort of thing will apply one texture to one UV pass. Certainly an exciting demonstration, but hardly practical: a typical scene will often have dozens of texture maps at the very least, frequently hundreds, even thousands. Naturally, each of these may be rendered as a separate UV pass, and each separate element brought into the comp: but that can make for some pretty unwieldy scenes and a headache to maintain all those passes in the pipeline. Re-render an animation, and the number of potential UV-passes can quickly make each iteration into a big undertaking.

Of course, if you're dealing with 8-bits per channel UV-coordinate textures, like a typical JPEG, then your possible texture size to project onto that is fairly small. 256x256 to be exact, and for practical reasons, maybe only about half of that. Hardly anyone even uses textures that small in games these days, let alone feature films. If you crank those UV-coordinate textures up to 16-bpc, now you wind up with some pretty impressive texture space: each of the red and green channels can now represent up to 65,536 coordinates: the equivalent of 16 4096-pixel-wide textures. Even if we want to be similarly conservative like in our above estimate, you can see where I'm going with this...

So my tool, which I call "OpaqueWhite ReMap Plus" uses nice, big UV coordinate textures, all generated by your rendering application in 16 or 32 bits per channel, rendered as described above as an unshaded UV-coordinate pass and is designed to accept up to 16 separate textures at a time, anywhere from 256x256 to 8192x8192. I provide a collection of high-res, high-bit-depth UV-coordinate textures for users to set up their render with, and a tool that is able to interpret the data from that render pass and automatically re-plot the texture in the render-specific UV space.

There's a lot more stuff going up on the site shortly. It's ALMOST THERE, I swear. To those that might be interested, you can learn a little more about and (soon) download my Shake Tools here.