I’m giving Adobe Contribute a go. I’ve been usiing it in concert with Dreamweaver, to manage some of my utility websites. Thought I’d see how it manages this blog. I’m very much liking it actually. From a workflow persepective, it makes a lot of sense. Your writing staff can focus on writing. Your web developers can focus on web developing.
We’ll see how it goes in the long run.
random note on something that was hard to figure out:
bash tab complete using:
complete -C [commandtorun] [commandtocomplete]
it will run the "commandtorun" command with three arguments.
Had to write an exe to write out the incoming args to a text file to figure this out. the docs are a bit thin on the matter.
I have left my role as the Director of Software and Pipeline at Method Studios, in order to focus on FIE.
This is a really exciting time for me and I’m looking forward to dedicating myself full time to technology and consulting under the FIE banner.
Method and I have discussed a continuing consulting arrangement and hopefully we will continue to work together in a new capacity going forward.
I’m launching mDAG, a project I’ve been working on, during the weekends, at home, while working at Method.
I’ve open sourced it under the Artistic License, 2.0 for a few reasons.
Firstly, I think its a tool, sorely needed in the visual effects community, in general.
Second, I’d like to see it adopted, and generally supported.
Third, I’d like to start using it at Method and felt open sourcing it was the clearest and cleanest path to Method’s ability to use it.
My hope is that as it grows, it will become a standard at many studios and facilities, and that many visual effects and animation artists will grow to love it and adopt it as a tool in their arsenal.
Actually, this is old news. As of January 2010, I took a staff position at Method Studios.
For FIE, this means the consulting and software facets of my company are going into a bit of a frozen state. I will continue to develop software and tools in some capacity outside of Method, but will limit that work to open source tools most likely.
The creative development half of the company is still moving forward however slowly…
I found it somewhat unintuitive and unpublished, so I thought I’d post my findings here.
Nuke’s brand new GPU support is only currently set up to run GPU operations on the viewport. It will not return them to the next node in the chain.
This is accross the board in all 3 hidden GPU nodes that come with Nuke 5.2 and appears to be built into the IOp calling mechaism (the closed source part of Nuke). So for all those with visions of GPU accelerated compositing… not yet.
I cannot really intuit the design intentions to the level that I can say if this will change in future versions. The one really odd part is the hidden node: BlockGPU. It makes no sense to have a node that blocks the usage of the GPU engine in a tree, if the only way to use the GPU engine is to view a node that uses the GPU engine directly. And secondarily… it doesn’t block the node if you view it directly.
Anyhow, to me it looks like they got just enough code in there to accelerate their new GPU LUT functionality, and left it at that. That’s probably why the GPU nodes are hidden rather than exposed. Maybe in Nuke6.0?
VFX World has published an article on previs, in this summer’s blockbuster movies. Leading off the article is Iron Man. Kent Seki, the previs and HUD effects supervisor gives a good window into what we did and how we did it. He also details quite thoroughly the tools and techniques I developed for the film. I’ve also detailed a similar account on my blog a few weeks ago.
There are a number of videos embedded in the article. However this one is a surprise. This is one of my range of motion tests from early in the suit design process.
PLF’s short summary of the effort on “The Incredible Hulk” is a good primer on what was done for the film. My good friend Erol Gunduz did a great job of stepping up and taking the main TD burden on the job. My contribution was in the areas of training, tools development and some Mocap supervision in Toronto.
Iron Man finally hit threaters and so I finally get to talk about it in the open, and what I did on it.
If you watch the credits, under Pixel Liberation Front, you’ll find me crediated as Brad Friedman, Technical Artist. This is actually a mistake. My credit is supposed to be Technical Lead, as my supervisor submitted it. I’ll assume it was a transcription error and not a willful demotion. If I’m really lucky it might be fixed for the DVD release, but that’s pretty unlikely.
So, what exactly did I do on the film? What does previz do on films like that? How does it relate to FIE? How will it help my clients?
Well, I’ll answer the last questions first. On Iron Man, I developed a brand new previsualization pipeline for Pixel Liberation Front, in Autodesk Maya. PLF has, in the past, been primarily an XSI based company. Though they have worked in Maya before, its usually for short jobs (commercials and the like) or working within someone else’s custom Maya pipline (such as working with Sony Image Works on Spider Man 2). This was the first time PLF was going to really take on a modern feature film as the lead company, completely under it’s own sails in Maya. And it was my job to make it possible.
The tools and techniques I developed were the backbone of the previsualization department on Iron Man for the two years PLF was actively on the project, even after I left the film. The pipeline also moved over to “The Incredible Hulk” as we had a second team embedded in that production. I’ve actually been talking to PLF about further expansion and will probably be expanding their pipeline in the coming months for upcoming projects. All those designs and ways of working are currently being updated and reimplemented into my licensable toolkit. They will be available to my clients.
I’ll get into the specifics of the tools and designs as I describe the challenges of the production further.
When we were first approached by Marvel and the production, one of the requirements for being awarded the job, was that we work in Maya. We quickly evaluated if we could do it. And the answer was “yes.” Very quickly we were awarded the job and we sent our first team to the production offices, embedded in Marvel’s offices in Beverly Hills. The team consisted of Kent Seki, the previsualization supervisor, Mahito Mizobuchi, our asset artist and junior animator, and myself, the technical director and artist.
My frist major task was to help the designers in the art department with the Iron Man suit design. At the time, there was no visual effects vendor. And the hope was that I could do Visual Effects development and vetting with the art department, avoiding the need of hiring the VFX vendor early in the production. John Nelson, the VFX supervisor was particularly concerned with the translation of the designs on paper, to a moving 3d dimensional armor. He didn’t want obvious interpenetrations and obvious mechanical imposibilities to be inherent in the design. He wanted the range of motion evaluated and enhanced. He needed us to be able to build the art department designs in 3d and put them through movement tests. He needed us to suggest solutions to tricky problems. All that weight fell on my shoulders with the assistance of Mahito’s modeling skills.
For a number of months, we rebuilt the key trouble areas again and again as the design was iterated back and forth between us and the art department. The abdomen and the shoulder/torso/arm areas were where we focused most of our time. I rigged a fully articulated version (metal plate for metal plate) of the trouble areas about once a week, trying to solve new and old problems different ways each time.
Finally, we arrived at what has stuck as the final articulation and engineering of the suit after a few months of work. The suit has gone through many superficial redesigns and reproportions since then. However its mechanical design was sound and survived all the way to the screen. The design eventually went to Stan Windston Digital for further work and to be built as a practical suit. It eventually went to ILM for final VFX work, once they were awarded the show.
I think what this aspect of the project shows is a very smart VFX Supervisor and VFX Producer
figuring out how best to utilize a top notch previs team to save money and get experts in the right places, without having to pay a premium for a full VFX company early in the production process. This allowed them to go through a full bidding process for the VFX vendors, without being rushed into an early decision, as their VFX needs were met by us. To give you an idea of how early in the process this was: Rober Downey Jr. was not cast at this point. The production designer started work a week after we did. The script was not complete. The Director of Photography was not chosen. The main villain in the film was NOT Obidiah Stain at the time. This is really early and ultimately the final decisions on VFX vendors didn’t come until about a year later.
Once our initial suit design chores were handled, I moved onto the main previs effort and we started working on sequences of the film.
Previs has some very special requirements. It has to be done fast. It has to look good. It has to be cheap. I think its the most demanding animation project type there is these days. On the triangle of neccesity, it hits all three points. Fast, Good and Cheap. Usually you can pick only two of those to accomplish at the expense of the third.
Historically, previs got away with skimping on the “Good.” Characters would slide along the ground, making no effort to pump their legs. It was pure blocking. It was fine though, because the previs was a technical planning tool. The aesthetics were irrelevent as long as the previs was technically accurate enough to plan with. However, as previs has become more of an aesthetic tool and less of a purely technical tool, the quality of animation has had to increase exponentially. It has gotten to the point that on a lot of shows, we’re doing first pass animation. And in the extreme, even first pass animation is not enough to convey real human acting. We are expected to be able to generate real human motion without giving up on speed or price. Some might find this antithetical to the concept of previs (infact a lot of people do) but our reality as a previs company is that “the customer is always right” and if the customer decides they want it, we need to be able to provide it.
So to sum it up, I was faced with being the only experienced Maya user on the team. I needed to hit all three points in the triangle of neccesity fast cheap and (exceptionally) good.
By the end of my time on Iron Man and Hulk, I created the following
Beyond the tools I built directly for the previs jobs, Iron Man also opened the door for us when it came to motion capture. The production had scheduled a series of motion capture shoots with which to test out the suit designs and see how they moved. We made it a point to capture some action for the previs while we were there. Our previs characters were already loaded into the systems since that was what the production was using to test our the suit design. We used some of the mocap for the previs on Iron Man in a more traditional motionbuilder pipeline that was functional, but slow. I immediately realized that mocap could be the solution to the, better-faster-cheaper problem with the bottlenecks sorted out with custom tech. And I moved in that direciton. Within a year, PLF had bought a Vicon mocap system. I set to the task of making it work for previs and within the year, we were in full swing of doing previs mocap for “The Incredible Hulk” due out later this summer.
The remaining question is: do these technologies have relevence outside of Previs? And the answer is, Yes. All of these technologies were built to dual target previs animation and production animation. They’re generic in nature. We have used all of these systems on finsihed render jobs, game trailrs and the like. What I’ve built, is a better way to animate, that is rig agnostic. All the old animation techniques and rigs still work. I’ve just incorporated them all into a higher level system. I then built a high volume motion capture pipeline as one potential animation source in that higher level system.
But it doesn’t stop there. In reality, I only really got to develop about half of the systems and tools I felt should be a part of the pipeline. In their new incarnations, the tools will be even more functional.
I saw the movie the other night and it was a real thrill to see all our shots and sequences finished and put together. A number of my own shots made it through the gauntlet and into the final film, which was a real thrill. More so than that, it was great to see people enjoying it. I felt good about knowing that I had in a very real way, built a large section of the foundation for it. My tools allowed Jon Favreau to work on the film in a more fluid and intuitive manner through the previs team, which really created an unprecedented ammount of previs at an astounding quality. The more previs we were able to do, the more revisions and iterations Jon could make before principal photography. And the film is better for it.
GlobalStorage solves a lot of problems I’ve been pondering for a long time. Here are some of those problems.
An experienced artist will look at my list of issues and immediately start listing application features, workflows and tools to deal with the problems one by one. And lets not be unreasonable here. Most medium sized facilites have at the very least, solutions, standards and practices that mitigate a lot of these problems to varying degrees. Here are a few:
The better solutions listed here fall into the category of Source Control Management (SCM) systems. SCMs solve a lot of problems. They were created to manage the first real digital assets, computer sourcecode, many years ago. Modern SCMs manage locking and versioning of complex directory trees. They can manage collisions down to the file level and if your files are text based, they can often manage them down to the line level.
Perforce and Alienbrain have been optimized to work with digital media assets (which are usually characterized as being big binary files rather than text files). They are however, proprietary and expensive. If you choose one of these solutions (and many digital media production facilities do) you will be stuck licensing each artist seat, or buying a rather hefty site license. They are proprietary and therefore, closed source. And as much as they can provide plugin APIs, anything thats closed source is more difficult to customize than an open source solution.
Subversion on the other hand, is open source and has a large volume of support. Subversion has been my favorite SCM for years and I’ve used it in production a number of times.
However, Subversion is not the end solution to the problem. All SCMs I’ve worked with including Subversion, have a few problems.
Anyhow, what I’ve built and have running in Alpha right now, is what I’m terming GlobalStorage. Its a suite of tools that use Subversion to implement a more robust SCM thats tailored better to production. Basically, it a system built on top of Subversion and more common filesystem tools, to act as the single storage solution for a digital production studio.
Here are some features in no particular order:
The 900 pound gorilla in the room has the word "Scalability" shaved into his chest hair. This of course being a serious issue and the cause of many growing pains.
There are a few ways to deal with this.
Firstly, I’m going to add a "round robin" load balancing system into GlobalStorage, where a newly created asset is put on a randomly selected server from a pool. Assets will also be able to be created on specific servers at the user’s requ
est. And assets will be able to be moved to specific servers at a user’s request. GlobalStorage will magically merge the assets into a directory structure on the user’s machine when they are checked out. Their location on the network is irrelevant as long as it has access to the repositories.
The round robin solution is pretty powerful and will probably meet the needs of a large number of facilities. With the application of minimal brain power by the artists, assets will move to unencumbered servers every once and a while.
However, what you’d really want is what’s known as a clustered file system, where it appears a single server does all the work and it runs really fast. In reality, a cluster of servers is moving data around and load balancing in a logical data driven manner. You also would want redundancy at every step of the way to avoid having a single point of failure to keep your uptime in the 99.9% range even when you have a bad week and 4 drives and a network switch fail on you.
Clustered file systems are a pain to set up and usually quite expensive to license. However, one of my goals over the next few months is to put together a set of virtual machines and infrastructure to make the deployment of a clustered filesystem based on commodity hardware and open source software a simple matter.
GlobalStorage is designed to work just as well in a Clustered environment as in a round robin environment. But there’s no doubt that at some size, you’ll really want to put a storage cluster into your facility rather than maintain many individual servers.
