| |
Interview with Gordon Cameron
Animation Software Engineer at Pixar Animation Studios, Gordon Cameron talks about the current state of software development, the invention of the Animation Mixer, the differences between proprietary and off-the-shelf 3d software and the most difficult areas in animation.
January, 26th, 2007, by Raffael Dickreuter, Bernard Lebel
 |  | Gordon Cameron, Animation Software Engineer
at Pixar Animation Studios.
| | | |
| |
| | | |
|
Tell us a bit how you got started in the cg industry and why
I grew up in a pretty isolated part of Scotland in a little town called Banff that had at the time a population of about 3,000 - watching movies was a bit of a chore given that we didn't have a movie theater in the town and that the TV at home had only 3 channels, but my school did have a film club, and there was a traveling cinema that would touch down across the bay - occasionally we'd take a trip down to Aberdeen to go to a 'real' cinema. I remember seeing Star Wars, Buck Rogers, Battlestar Galactica, Raiders, Battle Beyond the Stars, Tron & The Medusa Touch (!) and a ton of other movies of that era in combinations of those venues, wondering how the worlds were being created (or destroyed) - I wanted to be a part of that film making process somehow, but of course I had no clue how to do so given that I was a young kid living in the boondocks. I started buying magazines like Starlog and Starburst with the money from my paper round and reading as much as I good about the 'effects' world wondering how on earth I could get involved..
Around this time I had gotten interested in computers at a fairly young age thanks to the kindness of a neighbor with an Apple II Europlus he'd let me code on whenever I wanted. So that hooked me on programming at a young age, and I then got the bug of trying to write little visual programs around the time that the Spectrum was popular in the UK - being disconnected from the world made it easier to imagine that anything was possible, oddly, so I had the confidence to get things published in some magazines of the time, work with a games company when I was coding on the Oric-1, create a column for a wonderful Atari magazine called Page 6 and those sorts of things - that time in the UK was really quite amazing for a young kid interested in coding - it really was quite a remarkable period where enthusiasts of all ages were pitching in and working with technology on Sinclair’s cheap machines, Orics and imported Commodores and Ataris, and those running the publishing industry were open to the idea of giving people a chance and helping them out.
As I grew older and sitting through end roll credits, I'd noticed that ILM's name kept cropping up -the BBC also screened a TV documentary on ILM/LucasFilm Computer Graphics (later to become Pixar) where they'd shown some of the 'The Adventures of André and Wally B' work as well as detailed some of the making of Wrath of Khan, and I'd also become aware of the games division after getting addicted to "Rescue on Fractalus" - I eventually jotted down ILM's address from the credits on Cocoon (!), and wrote them a letter naively asking if they would give me a job, or tell me how to get one :-) They replied with a very nice letter (I'm amazed they received it given that I think had addressed it to ILM, Marin County, California, USA and that was that), essentially saying 'no' but giving me lists of stuff I might want to read. In meantime, I went to University in Aberdeen and decided to major is Computer Science - my final project was a robot vision draughts playing hybrid thingy - that got me into the field of computer vision, which led to me to my first real post-Uni job as a research assistant at University in Edinburgh working on industrial computer vision and model recognition. Vision and graphics go hand-in hand as they represent in many regards two sides of the same coin, so I next moved to work on scientific visualisation and parallel programming which gave me the chance to actually start working with the SGI machines that were, by this time, being used to create the effects for the sorts of movies that were popping up in cinemas (Abyss, Terminator 2, Batman, Jurassic Park, The Mask and such). The folks in my team were doing scientific visualisation & parallel simulation by day, but we had an interest in how the same machines were being used for visual effects. I started to get engaged in the graphics community by visiting SIGGRAPH, editing their magazine, and trying to start to make connections in that world.
My big break came after a visit to SIGGRAPH one year where I noticed this cool company called Softimage that had worked on software that ILM had used for Jurassic Park and the Mask. Char Davies (one of the founding directors) had some work in the art show that had impressed me, and I wrote her a letter saying so - she replied and I thought 'hey, I'll apply for a job there', and forgot about it. In middle of night when I was working in Edinburgh I got a call from Lucy Boyd-Wilson from Softimage who mentioned they were looking for someone in their motion input team, would I be interested (!) and could I come out for an interview. I did, they offered me a job, I accepted, and I moved to Montreal about 4 weeks later I think. From there I was lucky to work with some wonderful people on amazing projects at Soft - I ultimately decided I wanted to focus more on production and was fortunate to get the chance to move to Pixar Animation Studios, which is where I am now.
I guess one of the main reasons I am in the industry is due to the willingness of a procession of people to take a chance on me, and for that I am eternally grateful.
What do you like to do in your spare time?
I try and read as much as I can, take the time to travel a little more, cycle, swim, watch movies, enjoy music - the usual sort of things. My wife from Montreal doesn't work in the same field (she's a painter), so this helps in keeping me less obsessive than I was in the past.
Explain us your role at Pixar and what responsibilities it involves
I've most recently been working in the production engineering group developing technology that spans our currently in-development features. I've tended to work on tools and technologies specifically targeted toward animators (Pixar has its own proprietary animation system) – tools to work more fluidly across time, adding secondary animation and deformation effects, staying in context, retiming, and so forth. Since we are all in the same building it makes it very easy to collaborate on tools and projects directly with our 'users' and get a much faster feedback loop than is perhaps possible when developing external software applications. Of course, on the flips side, when things break we hear about it very quickly and often need to address concerns as a production priority.
I've also worked in other teams embedded within specific films, developing custom technology that the animators interact working within that specific production - Pixar is very good in that regard, in that if you have a notion for a project that you might want to develop and follow, it is quite possible to move around a little to develop new skills in different areas. That has certainly been my own experience.
In addition to tools development we all have a collective responsibility to ensure that we stay in touch with what production needs in the moment, whilst trying to plan for the in-development features technical needs – for example, on Finding Nemo it became critical to find a way that animators could work with very complex shots involving many animated characters (the shoal of talking fish for example) so we beefed up support to allow layers of baked animation to be replayed in realtime. You see a lot of interaction between the tools group (building cross-production tools and workflows), tds on the specific shows, animation, articulation and such. The tools group is also able to act as a technology ‘memory’ to some degree, ensuring that we can learn from deployment of technology on one show and carry forward and improve across future productions, rather than starting from scratch each time – so future shows can benefit from the Finding Nemo baking optimizations, for example.
What makes it special to work at Pixar and might distinguish it from any other place?
Well - in many ways the studio is run like one big co-op or family. It really does feel like the 'company' really cares about its employees, their health, family and well-being. We work in such close proximity with all the other departments (with a shared common atrium that forces people to interact) it is very easy to feel that we are pulling toward the same goals and I think that helps give folks a feeling of empowerment and part of the final film, regardless of what their role within the company may be. I think it's fair to say that Pixar places a great deal of value on the individual regardless of the capacity in which they contribute.
The company is also prepared to take chances on people willing to be proactive - and that in itself is tremendously empowering - there are numerous stories of people moving from entry-level positions to radically different leadership roles over time. There is much less in the way of politics than you might expect for a company of this size, and those that sit in management positions are very visible and approachable.
To what extent do you think does Pixar see animation different than most commercial production houses?
I think the main thing that Pixar prides itself is in the notion that everything we do is in service to the story. The projects are developed internally and driven by the directors according to their artistic vision and the story they want to tell - that process of developing projects and story is the heart of what we do, and as a result their is a degree of purity in the process that perhaps is less present in other production studios? John Lasseter always publicly states that story is everything and I know that externally people may find it hard to believe that this can be true, but the company has done a remarkable job of protecting that idea, and shielding the workforce from external market or financial concerns so that we just concentrate on the best stories and projects possible, and in creating and delivering films that reflect those visions.
It is being heard that Pixar sometimes has special parties/events. What is one of the most memorable ones to you?
Prior to the wrap parties the most exciting thing is in seeing the film in its final form, to be honest - we normally hold the screening right before the wrap party, and in the past it's been in this beautiful art deco theater - that is typically the first time the employees (and family) see the whole thing cut together. It's pretty exciting, and the whole company is there incl. the other films' crews.
The wrap parties are always pretty special. The last couple parties have been held at a large hangar on a disused naval base and those are really cool affairs. That is always a huge thrill. (Sushi at the Finding Nemo party was great and a bit odd - funnier for me was my wife cutting Steve Jobs off to get earlier in the sushi line - inadvertently of course :-).
Since you developed the Animation Mixer, to what extent does Pixar also actually use non-linear animation tools?
I probably can't comment too much on what technology we develop or use internally here, other than to say that its a mix of both off the shelf and proprietary, and that we try and keep up with current trends and technologies. Animation is certainly a complex pipeline, and we have developed tools to try & manage that complexity of motion, share, reuse and so forth.
The animation department has developed a pipeline whereby they develop and share animation in a reusable form collaboratively early in the shows during character development.
If you look back tell us a bit about your job and your times working at Softimage
I had an absolutely amazing seven years at Softimage, working with a wonderful crowd of people on exciting projects, and developing some remarkable software of which I am a very proud. Of course in amongst that process was a great deal of work, stress and a fair share of mistakes.
I started working on motion capture input/output stuff (Channels), live performance capture tools and playback, in-camera viewing tools, was involved like everyone else in the port to Windows, implemented crash protection (I'm the person who stupidly added the loud cymbal crash sound effect when SI|3D crashed and tried to recover!), worked a little on SDK, then was one of the original developers of the animation mixer in XSI, I became project lead of the animation team on XSI's first few versions where we developed the hierarchical animation, constraint system, IK/FK, Expressions and such, then a development manager overseeing XSI development. I'd also been able to work on some other projects directly such as first hair integration (which is a whole story unto itself!).
I was really interested in making connections with customers, and the job allowed me to do so right from the get-go, which was wonderful - I had chance to work onsite a little bit at EA right after joining, to travel around to give talks at conferences in US & Japan (and meet Yu Suzuki!), and we had a good interaction with users on both SI|3D and XSI.
In my seven years we went through many challenges - development of first windows versions when Microsoft acquired us which meant a tremendous amount of relearning, the decision to develop a completely new product, XSI, atop a shared windows platform with DS, the subsequent sale to Avid and so on. But for the most part these challenges were remarkably instructive (using Microsoft as an example, people have this impression of them as being a corporate behemoth and no doubt at the outer level this is true - at the same time the company consists of a large number of remarkably talented and driven people, and engages in very progressive workplace practices when it comes to position, rewards, reviews, equal rights and such, and much of that was helpful in improving Softimage's own internal processes).
I was able to do some substantial work on Softimage|3D and with its customers before moving on to the first version of XSI, but I know that for some of the younger developers the XSI development was much harder as they were working on something 'blind' without that context for many many years until first releases and deployment when the feedback really started to come in, so I do feel lucky in that regard. I have to say that in the development of Softimage, XSI and other products I worked with some of the best architects, QA people, build folks and many others that I've ever encountered, and we achieved so much with an amazingly small crew. Special Projects in both LA and Japan were instrumental in helping us stay focused on task and at the same time maintaining a presence in the user and client world while we went away to work on XSI, and I can't speak highly enough of the work those groups, the demo artists, internal animators and clients willing to invest their time in our alphas and betas did in making XSI what it eventually became.
Best personally satisfying things for me were probably being involved with the animation mixer, having the privilege of leading the animation team as they created some great technology, and watching how we were able to alter the workplace over the years to make it more conducive to family life for the employees I think! The hardest thing as a developer who ends up taking on more responsibility is in letting go of the technical bits and bobs, and I'd like to think that at the point I left I'd perhaps at least started to get that and take satisfaction from what everyone else was doing!
What can you tell us about the development of the Animation Mixer in XSI and its history?
Softimage had been very interested in the ideas of transportable, non-destructive editing of animation from various sources given experience with motion capture, the games industry and in watching people work, or try to work, with increasingly complex data. Early tools such as the dopesheet allowed some degree of higher level of control, and in Softimage|3D we had implemented an animation sequencer that was well received by our games clients and that supplied a great front end to doing chop sequencing as well as introducing the notions of motion abstraction and transportability. Prior to this, the Special Projects team had itself developed a sequencing system for combining motion clips. The film and interactive industry of the day was really starting to leverage motion capture, and the games world was making heavy use of large numbers of clips of motion (this was the days of Virtua Fighter 2, and when the likes of EA were starting to heavily invest in their mocap studios) - there was, however, a disconnect between the needs of the industry and the available tools - I'd organised a panel in '97 (ref) that sort of touched on one aspect of this and investigated character animation and motion capture - at that time the worlds were remarkable polarised and one of the main reasons for this was that there really were few if any tools out there to allow artists to work with these different types of motion source - hand animated, simulated, captured and so forth - without a great deal of pain.
With all this in mind, Gareth Morgan and Rejean Gagné had spent quite a bit of time thinking about how we could develop and deploy tools to work with motion at a higher level of abstraction than splines and knots on fcurves, that leveraged our own experience and that looked to other fields for inspiration - and the idea for the animation mixer and non-linear animation came from there - trying to come up with a set of highly intuitive tools heavily influenced by those familiar to audio and video technicians who had worked with mixing software for years, but tweaked for 3D animation, and married with the notions of clip transportability, non destructive editing, speed, extensibility, re-use, and such. (You can see their original designs reflected in patents visible on google's patent site).
Glen Fraser & I became involved at a very early stage to talk about precisely what we would implement and how we would go about doing so. This was very early in the development stage of XSI, so we had a great opportunity to develop the technology as the core of XSI itself was evolving. Glen and I worked on the architectural design together, and then we split the engineering - I worked on the runtime mixing, aggregation and evaluation, with Glen doing the work on data representation, interfacing, instantiation - we shared the rest and collaborated very closely with the core team who were at the same time actually building the low level plumbing. Christian Roy implemented the entire first version of the UI himself, so it really was the three of us for most of the initial functionality.
There were a great many challenges along the way of course, not least of all being the fact that we were relatively new to the PC (where we were doing our primarily development), and to COM/OLE (the object technologies we were leveraging in addition to basic C++) - the core itself was changing very rapidly, so we worked quite hard to come up with an architecture that could survive and develop in tandem, but in general I think we made very rapid progress. Glen & I both had experience with large and very dense data-sets (from the mocap team days, where we worked together), so one of the things we concentrated on early on was making sure we got good performance and scalability. The most satisfying early moment I remember was in doing a staff demo which was the first time we'd shown the work, really - Gareth had this character called "RudeKid" that he'd modeled and created some loops for, and we did a demo where we loaded the character then dropped down some motion clips, overlapped and transitioned them and it worked! It was immediately apparent from that point onward I think that we were onto something, and people got what we were up to.
After the basic 'create some clips, associate with model, instantiate and mix' workflow we designed and implemented a bunch of the other things people saw in v1 such as the mapping templates for connection and value, different transition types, compound clips and so on. Rejean, Glen and I worked very closely to try and come up with a stable feature set that would be usable, and as the project proceeded we also started to get help from some wonderful other folks - Ronald doing the shape animation, and a few co-ops such as Marty and Francois who helped kick the software into shape (We had some awesome QA folks who also kept us honest, great help from special projects and demo artists and of course end-users who were testing everything and coming up with useful feedback).
Version 1 shipped and we were able to take a bit of a breather and step back to see what things looked like - I guess my observation then, and now to a greater degree is that we had built something that was quite impressive and powerful, but with hindsight we could and should have invested more into the interaction & UI so that the cost of entry was a little lower for our users - there was a lot of functionality there from day one, such as compound clips, ability to reference scene entities with an expression in a clip and have it do the time conversions correctly, compound clips (although only to 1 level), ability to slip-scrub clips in time - a bunch of interesting things, but we hid them beneath too basic a UI I think. One of our great regrets I think was that we just didn't have the bandwidth or time on the schedule to fully expose the mixing ideas in a way where they could be used seamlessly in tandem with 'standard animation' - i.e. more like a layer above scene animation. We'd implemented some prototype code early on in this regard, but it is great to see that Brent and others have implemented this idea much more powerfully than we had envisaged in XSI 6's layers.
As a footnote and last anecdote - after shipping, I ended up spending a lot of time engaged with Softimage customers and users of other packages in forums and such, talking about what we had been trying to do, why we were using the term non-linear animation, how we believed we were trying to create something significantly different from Houdini, Animation: Master, Nichimen's Mirai and such (without taking away from what those very capable packages were doing) - after shipping, I noticed an interview with marketing directory of our main competitor in, I think, "3D World" where he was saying, essentially, that NLA was a fad and nothing particularly new or desirable - fast forward to the subsequent trade show a few short months later and I see the same company showing their own subset'd attempt at precisely the same interface and workflow, very literally borrowing particular visual elements we'd developed - fast forward even farther to today and every shipping animation system has some sort of NLA tool embedded within their product and the user base takes that for granted, so I think that the ideas and our own attempts at a product had been vindicated at least to some degree ! (So much so that we managed to put together a panel on the area in 2001 (ref))
Easily the most satisfying parts of that entire experience were working with some brilliant engineers such as Glen, and the feedback we got from internal and external users like Kim, Laurent, Thomas, Brad, their extreme patience in giving new workflows a try in their pipelines and bearing with all the problems and bugs, and seeing the final results in individual and student work, through music videos, ads, television to the film pre-pro and production work in the likes of "Panic Room" through "Happy Feet".
P.S. I don't want to give the impression that the mixer work was a solo (or trio effort) - by time of release, and beyond v1, a tremendous team of people worked on making it ship shape - there's a little easter egg in versions of XSI at least up until 5 I think, that tries to credit those folk :-)
What is the big difference between being a developer for a 3d software company compared to developing proprietary software for a studio?
The main things that for a developer differ I suppose is that, at a production studio such as Pixar you have a much tighter focus on a particular set of problems related to making animated movies - for example, we have a very varied animation user base that is significantly less technical than the Softimage customer tends to be, so that shifts the emphasis from trying to add as many new features as possible for as wide an audience as you can to one of trying to make a smaller set of tightly focused intuitive tools that address the needs of your user base. Your customers are in the same building and although this is tremendously helpful, you will still find that tools development even internally tends to at least somewhat align with production schedules, so it is not as free-for-all as you may imagine in terms of release management. The huge benefit in having everyone here is in the development process, pre-production and planning - it is possible to feel very much a part of the productions and closely connected with what ends up on the screen - much more so than when you are working with external clients who are leveraging a small part of your toolset in their production.
On the other hand, Softimage has an absolutely fantastic, diverse and engaged user base across the world, and it is very satisfying to be able to engage with such diversity of opinion, suggestion, usage patterns and such - I remember being constantly surprised with the creative uses clients were making of the software - often extending and leveraging in ways we completely did not expect. Also, at an external company it is crucial that you stay informed about what the rest of the world is doing in terms of tools development, as you are competing for the same customers with those other companies - at a production house it is perhaps easier to stay isolated for the duration of the productions, so you need to make an extra effort to keep engaged within the larger community rather than have that happen as a necessity.
If you compare a bit the level of tools Pixar has available and compare it to off the shelf software, would you say there is a significant margin in between or they are at a similar level, with proprietary software simply being more tailored towards a big studios needs?
I think the latter. At the commercial studios, the differentiating lifeblood tends to be the workflow, pipeline and how specific domain knowledge of that film making process is embedded within the tools. They can more closely align interactive tools with the needs of a user in a way that would not make sense for an external software company. For example, given that the animation studio animator probably accounts for a probably very small percentage of the overall package sales it makes little sense to tune the workflow of the package to that area - in a studio it makes perfect sense and this is where we can excel. On the flip side, it is hard for many studios, I think, to justify doing their own modeler as there are so many capable packages already out there - it's somewhat of a mature area in which a studio can't really add value.
Research is another area where we can deliver and deploy unique solutions for say water and hair very quickly for a production, much more rapidly than it would take for an external software company to develop, release, test, gather feedback and refine.
Do you think commercial software developers should spend some time in studios to understand the production side better?
That's a tough one - having worked in both areas, I can say that from a studio point of view of course we would love to have the tools evolve in a way that more suited production pipelines, so the embedding of developers makes perfect sense (if schedules can allow for it). On the other hand, commercial software sales at the current price points rely on shifting many units, and over dedicating of resources to a specific market (e.g. film effects) is something that the vendors are wary of I think. This is a very different situation to when I started at Softimage and licenses ran to tens of thousands of dollars, so one could cater more closely to the needs of very specific clients and workflows.
I do believe would be very desirable (for all parties) if 3rd party developers were able to rotate into positions where they can sit with users of the software across the range of different users - whether they be in games production, film effects, school, training and such. From my own experience this is the absolutely most efficient way of getting a feel for what the users are going through, understanding what is important and what tools one should develop. e.g. if you are embedded in the middle of production, you develop a sensibility for what kind of tools (and what fixes!) your customers _want_ as you see that production pain each day. And if you sit in with people using the software at different levels, you don't skew the development too much in niche directions.
(As far as production specifically goes, however, I will also say that what tends to happen is that the workflows, scalability issues and such that a package will face in a high-end production one year trickle down to be issues for games, student or home use very very rapidly these days, so sitting with those directly in production does indeed hold promise for showing the problems that the graphics community may face en masse down the line).
With every feature animation film, the bar of quality and scale is raised significantly. What do you think about that? Where is this going?
I think that that has been true up until fairly recently, but that if you look at the current range of animation pictures I think that, in many cases, it's not the technical quality or scale that is rising so much any more, and it's more the variety within the genre, how the stories are being told that is burgeoning. There are many, many films being made now using established technology to tell stories at lesser cost ( Barnyard, Jimmy Neutron, Hoodwinked )- at same time of course you still have the big productions from the likes of PDI, Sony, Disney and Pixar, but there's also a peculiar renaissance I think happening now within the animation genre - from old school 2D and stop motion (Corpse Bride), to big production detailed 3D (Open Season), to cheaper fare, investigating different less-literal renderings that fuse genres (Flushed Away & Laika's project with Selick), crossing genres (Manga 2D and 3D multiplane in the Animatrix films and tekkonkinkreet) and merging techniques (mocap and traditional in Monster House and Happy Feet), creating fused hybrids of live/animated form (Avatar and many of the superhero or monster movies of late, Waking life), and perhaps leveraging technologies such as runtime game engines. (ref nytimes article)
I think where this is going is into less rigid taxonomies within the animated feature form - rather than seeking pure realism I think you'll see more imaginative use of technology to tell different kinds of film that look radically different to what you've seen before - not so much in terms of seeing hair and water that look better and closer to reality than anything you've seen before, but rather something less literal where the style or look is less based on our physical world. Happy Feet is also an interesting example in combining different types of performance perhaps more successfully than any prior feature that has used motion capture - although of course something like LOTR is also pointing the way in that regard. At same time, I think you will see a revival in the neglected forms - 2D animation, say - that were abandoned in the mad rush to computerize all animated stories.
Whats your view where animation is heading? More non linear? Extensive use of Mocap blending with hand animation? Share some thoughts on the topic
More bullet-time kung fu sequences? :-) Let's hope not... I think the idea of what animation is in itself changing, as are the types of stories being told - and that is interesting. Developing tools for these different kinds of hybrid forms I think will be very challenging.
What is still one of the most difficult areas in animation to solve to make it accessible for animators?
There are so many - Better character interaction and contact - the majority of animation shies away from contact and this will change. Also other sorts of interaction with the environment need to pass back into the animators hand so they can act with more access to that environment at their fingertips, rather than having secondary interactions occur down the pipeline in sim. Also needed - tools to help animators collaborate on shots, fix and augment shots after the fact, work more fluidly with poses over time and most importantly context switch as seldom as possible. There is _much_ work to be done to improve tools for animators, and much of that work is in usability and interaction as opposed to raw functionality- off the shelf tools still require too much technical knowledge and switching on the part of the user.
I’ll give you an example from production on usability – we have our own FFD type deformers that we let animators play with and that they used quite a bit on The Incredibles, and will leverage more on Ratatouille. There is this very complex shot with Helen in the tunnel stepping back into the wall and deforming to get out of the way of a rushing train – this was all ‘acted’ by the animator using a series of overlapping lattices that he ad hoc added. Now, we developed the tools so that they could do this sort of job, and the deformation itself was not a problem – what we did not do was think about the end-to-end workflow for how an animator would setup, install and edit/repeat and share such setups and this caused us more grief than it should have – we concentrated on the core functionality entirely with not enough emphasis on usability. We learned from this so that the end-to-end pipeline is now highly optimized for non technical animators – we have some new technology in Ratatouille (the upcoming DisneyPixar film, releasing June 29, 2007) for animation where about half the work was in getting the interaction and pipeline right, with other half in the ‘technology’ – the result is we get a lot more usage of the tool than we would have done by just throwing the tech out there. Interaction is important.
If you look at XSI now all these years later, what is your impression and how it developed?
I think that the early years were very hard for everybody - clients and Softimage employees - people had to deal with multiple acquisitions (Microsoft, Avid), the blind-siding to some degree by the release of the excellent Maya 1.0, the port to a different primary platform and learning of new technology. For the first few versions people were working ridiculously hard to try and deliver a working package. The initial ideas and core behind XSI were very strong however, and if there are one or two people you need to thank for the product evolving and getting to the stage where it was a viable production tool (around 3.x in my opinion) than that's Rejean, Marc, Jean and people in the field such as Olivier and Bob - the company kept focused through the lean years and is in a very good state now, I think, to turn things around.
The core is very powerful and has very strong legs for the future - and the development team is a very impressive bunch of individuals who have done amazing work over the past years. With recent advances in performance, scalability, SDK, the modeling engine, animation improvements, compositing, shading both offline and real-time - it really is an enormously rich & complex product that is now becoming easier for people to integrate within other pipelines.
At the same time, along the road several mistakes were made - the company became, in my opinion, too concerned with interactive applications (web) not related to our core business, we neglected to listen to comments about what was good about the older product (dopesheet :-) when implementing new functionality and were too slow to react with improvements, the basic templates to make the package easier to use by those who were coming from e.g. Maya were not in place until much too late of a version, things like particles lagged behind for too long, we were less successful than we could have been in getting the software to a state where it could be embedded in school curriculums and so forth, and 'interesting' management decisions were made. But the individuals developing the software were ALWAYS focused on trying to do the right thing, even when we were failing! - and along the way many innovations fell out in high level animation, rendering, modeling and such of which people should rightly feel proud.
One of the things that has happened since I left that is enormously positive is a better integration and interaction with both the Digital Studio team, and Avid in general and I think in great part that is down to Marc's leadership.
What features of XSI do you think could make it desirable by Pixar to use at large scale?
I probably cannot talk too much on these sorts of topics specific to Pixar, but, in general, for an external piece of software to be invaluable to a studio, the bottom line is that software needs to understand how to integrate within an _existing_ pipeline, and to do so as seamlessly as possible. It also has to have clearly articulated benefit beyond a slate of existing tools, as the opportunities for movement to other packages are limited by production schedules. And one of the most important things is that the package needs to 'feel' familiar to those using existing tools - whether that be by emulating keyboard commands, or by building something that is so incredibly intuitive and discoverable that it requires no additional training to be enticed in.
Whats your advice to software developers out there who would like to work one day at Pixar, what special skills should they try to get?
Know your customers, understand what their day-to-day struggle is like, and by doing so you will have a good feel for what tools and advances to focus on.
I think in a strange way the best thing is not to try and focus too much on getting a specific skill set from the get go but rather trying to get as much broad experience as you can before specializing, and most importantly doing whatever you can to gain domain knowledge in the area you are interested in. For example, if you are interested in becoming a lighting developer of course it is important to gain knowledge of the latest state of lighting technology and research, but almost as important is in doing all you can to understand what the artistic process of lighting is, how lighting fits into the larger pipeline of a feature production and so forth - you can do this sort of thing by frequenting mailing lists and forums, reading about production (Cinefex), trying to do your own small projects in collaboration perhaps with friends to make a small movie, and also investigating areas that are less literally connected to computer graphics. For example, an understanding of vision and parallel programming was extremely useful to me in moving to graphics - you can see new ways of connecting the dots in research across different genres if you have at least an awareness of those other disciplines. So I would recommend knowing your desired area in detail yes, but also reading and investigating/looking broadly with a few to seeing your area in novel ways, and understanding how others in a production may _observe_ your area.
If you gain this kind of knowledge you will be valuable to a studio, and you will also be in a better position to contribute and learn from all those around you if you have a common language to communicate in.
Related Links
Siggraph Newsletter
Siggraph Newsletter - Gordon Cameron, Editor
Motion Capture and CG Character Animation Panel - Siggraph 1997
Patents
Non-Linear Animation for Production - Siggraph 2001
Oscars - The Penguins And People Look Great, But Are They Animation?
Discuss Article at the forum
| |
|
