My previous blog post is a piece I have originally written for Casey Muratori a while ago. Casey wanted to dedicate one episode of his show “Handmade Hero” to tell a few stories of people switching career to software engineering. I was very happy to tell a bit of my story because I felt it is somehow different than many other people experiences I have heard. As Casey points out, some people want to move to tech because they feel they are not satisfied by their current careers. For me it wasn’t like that, I actually liked my previous career quite a bit, but I decided to switch to software engineering anyway. In this post I’ll try to go more into the details of why and how it unfolded.
I mentioned already that many life changing events are just fortuitous. Crisis and opportunities just manifest whether you want it or not. Sometimes you may not even notice them, while sometimes they are as subtle as a sudden slap in the face. For example, how I did move from Italy to Australia.
I wasn’t really satisfied with my career in Italy. It wasn’t bad, it was honest work, hard work… probably I was doing a bit better than several of my colleagues and young fellows coming of age with a master in media and communication, or architecture, and having hard time finding a job. I knew I had more to offer than the work I was doing day in and day out, I knew that because I was producing above expectations and I was constantly looking for other projects to keep me stimulated.
For many years my side-gigs – my personal projects – were yet more computer graphics work. I remember how my good friend and colleague Emiliano Padovani (now head of shading at Weta Digital) was oil painting and drawing comics when he was going home; while I was logging-in at my computer and modeling more stuff, cooler stuff, the stuff I would have loved to work on at my day job. That was my pressure valve to be able to keep on loving my work.
You may ask, why not seeking for a better job? Well, when you work at one of the best studios in your country there are only two things you can do, migrate or change career. Without an university degree it is pretty hard to obtain a working visa in countries like Australia or the US, so it took me a good 12 years of work in small shops in order to have enough provable experience to jump. Maybe I’ll write about the efforts and perils of migration in another post.
While I was not very satisfied at my daily job, I was also not satisfied with the tools I had. This is very common among 3D artists, I believe I don’t know a single one of them who doesn’t course their tools or at least some part of them. Most people take it as being part of life, not something they can do anything about. More of, when you work at small studios you also face the budget reality that better tools may exist, but you won’t get licenses for them and you’ll have to just do with what you have. This was particularly true 20 years ago when a single license of a DCC application was $20k or even more.
At some point I started thinking that in order to solve some of my problems at work I needed better tools and I could have created those tools for myself. So, how did I get to Pixar is really a series of unintentional moves, 20 years in the making.
The first piece of software I have ever I created was a Phong shader with a control to soften the shadow terminator. That is so random and so specific, hardly a disruptive app to overtake the market of photo sharing on social media (none of which existed back then). So why? The studio I was working for just switched production from Alias Power Animator 9.0 to Maya 1.0. Power Animator had true area lights, Maya didn’t. Area light are expensive but they create some natural illumination, while point lights do not. Suddenly it was really hard to get convincing look in design objects, all lights had hard light terminators and that was no good. I needed to do something about it. Luckily Maya had example plug-ins projects and one of them was a phong shader, ready to modify. The IRIS OS in SGI had a compiler, so I didn’t need to install much to compile the sample projects. Maya plug-ins are written in C++ and I didn’t know C++. At the time I had never written an actual piece of software. C++ is not the simplest of the languages, but when it comes to changing some math in an existing codebase, it’s not impenetrable. So I poked at the code without knowing what I was doing, just using some basic knowledge of trigonometry. I achieved the result I needed, I could create better art (or at least go back to a resemblance of what I could achieve before).
The first take at making software was encouraging. In the typical approach at learning you do learn something in an abstract form, without an objective in mind. For me that doesn’t work very well, the motivation is not high enough to make me retain the information, and when it gets too tough I may start losing focus and move into something else. In my case I had a clear purpose, I had an exact problem to solve: the shader sucks! The thing to learn is how to hack an existing example. Good I had strong will and I did crack that. Everything I learn in this process happens to cement in my mind in a rather effortless way, and every new concept and trick accumulates in my tool box in a way that is ready to use, I have new pieces to fit patterns with and I can connect more dots than ever before when a new problem emerges.
The second challenge appeared a year or so later. The studio moved away from SGI workstations, adopting Windows NT. Fantastic! I could have both Maya and Photoshop in the same workstation, a big boost in productivity compared to sharing a single Mac with the rest of the crew in the office. The problem was that with the move to Windows none of the shell tools to remote other machines were available anymore. Up to that point, in order to render a sequence I had a script that was dispatching the rendering to computers over the LAN using telnet. With Window NT we were stuck, I had to go desktop by desktop, logging-in and typing the render command to render from frame 1 to 10 on host A, and 11 to 20 on host B, and so forth… Imagine that! This was around year 98-99, there were no such tools available for download or even purchase. Those were uncharted territories! It was the wild west. So the next side-gig was to write a render farm scheduler.
I wasn’t completely naive though: I knew I got lucky with a sample plug-in to modify and compile. Step by step instruction in the documentation are kind of no-brainer. I knew this one project would have needed a little bit more foundation. Also I was not please by how easily I got away on my first project, the fact I didn’t understand the language I happened to poke at bothered me. So I bought an introductory book to C++, I digested it in 3 days, I guessed I aimed a bit too low. It gave me some rough basis though. So I bought two other books, one about the Windows MFC framework and a more serious C++ book (unfortunately I don’t remember which books these were and I don’t have them anymore). To tackle the challenge I took 2 weeks vacation with my two books and attempted to write a client-server application using windows sockets, along with a GUI to monitor the server and operate the client.
First step was understanding the language, that was actually not so bad. The concept of control flow, variables and program steps were not that dissimilar from what I remembered form Pascal, and the first introductory book gave me the footing. A much bigger challenge to tacked was the GUI. GUI looked like black magic to me. I had absolutely no idea how a program can wait for user input without being completely frozen, remember I didn’t study Computer Science. For me a program was a control flow that starts when a program begins, it perform some computation, then it terminates. That is how much I understood about software. So figuring out how to make a GUI was key step. I see this in people, wondering about software engineering, looking at it as some sort of witchcraft. It’s actually not that hard when you begin to learn the basic blocks. You simply need to see enough tricks to understand there is a logic to it and no magic. When the tricks are revealed, the magic looks pretty darn obvious! (at least some of the times).
I spare you the suspense: two weeks weren’t enough to create the farm scheduler, but I had a sketch of the GUI working and a much clearer idea of what to do next. I continued the development at nights. Now that I had acquired the basics I could afford to split focus between the artistic day work and the night time tech exploration. I don’t recall with precision for how long, maybe a month, but short after I had a prototype running and it was relatively stable. I could submit jobs to the other workstations and now adding new feature was easy. First let’s add a job queue: I want to be able to submit multiple jobs. Let’s add the ability for other colleagues to connect, so that they can submit work too. Let’s add a feature to the server to back-up the progress status, so if the server fails, work can be resumed. Let’s implement the auto-requeue function so if one frame-render fails it is going to be retried automatically. Wow, for the first time in my life I had a reasonable guarantee that if I submit a job at night, the next days all frames will be computed. That is magic! I started selling this tool to other small studios. I made pennies, but I started understanding the need to polish commercial tools, the effort in customer support.
After this I wrote a variety of small plug-ins for Maya, such as ik-solvers, Loop Subdivision Surfaces to smooth cloth simulation, and lots of scripts. That lead me to a unique challenge: I didn’t like the development environment for scripts. The Maya script editor sucks (no, no the one there is today, the one that had single level undo, no syntax highlight or even text search). So I went off a big endeavor to create an IDE for Maya where to code MEL scripts and expressions. This was before Maya had python. The project was MEL Studio Pro. I created my editor mimicking MS Visual Studio. I even created an experimental debugger able to line step MEL code… I started selling the tool, I think I sold a small number of licenses to most major Game Studios around the globe, including Microsoft, Sony PlayStation, EA, etc… My intent was trying to see if I could step up to something more than my not-that-satisfying day job. I made several thousands dollars in the process, but not nearly enough to become a primary source of income. Work was intensive, the product was good and polished, way beyond any alternative out there… the initiative failed never the less, the product was way too niche.
Whatever you do, do not break on failures, you have to try many time before getting into something. At the same time, recognize your limits and the real prospects of you endeavor, there are moments when you have to call it the day. In the meanwhile time matured for me and so it did my applied technical knowledge. The effort was not without its merits since that lead me to Animal Logic in Australia.
Working on Happy Feet as a lighter/compositor had been an amazing experience: so much to learn and so many opportunities to show what I could do. Tools weren’t perfect and in spite of my lack of experience in big productions, compared to several of my new colleagues hired from big studios in the US, I could solve problems autonomously while several of the others needed technical support. This established a pattern for me: I work on a production, whatever it is, from a product visualization for Nolan Helmets, all the way up to major Hollywood Blockbusters… I figure that I can do the same much better if I create some piece of software that helps me in the process. In the pauses in between productions I will create that new tools so that I am better equipped next cycle.
Wait a second? Isn’t that the purpose of each R&D department in each darn studio? Or at least the studios that are lucky enough to have one? In theory yes, in practice productions are very risk adverse due to the very small profit margins of the average show, and sometimes – sorry folks – the lack of vision… so if you go to a producer and say, “Hey I think I have a good idea. The shading system we are using is clunky and I have an idea on how to make it better”. They are likely saying something on the line of: “Look, we have spent so much already in creating that shading system, just use what you have got, ok? Is there anything else I can help you with?”. On average I have noticed I was up against two things:
- Risk aversion
- Push back from who created the previous generation of tools.
Sometimes I had to swim against the current. I still had to work at night to create prototypes to pitch the potential of my ideas. The hardest pitch are not those where you show the tech. The real challenge is on those where you have to show numbers, investments forecasts and returns. Yes, that producer that tells you “Is there anything else I can help you with?”, they may respond to a proposition where you present how a new tech will improve production value. You want to talk to a business man, you need a business plan.
Yes, at some point it wasn’t a simple tool for personal use that I was conceptualizing, it was major chunk of the production pipeline. Once I pitched a substantial restructuring of the company and how production departments ran and interfaced with each other, heads of departments and all, and you know what? The company took it… not without changes, the people that in my journey I had to leave behind deserves all the credit to pull it off, but sure I made that spark.
I want to joke about it: “don’t try this stuff at home”. You need to learn your limits and have data at hands. If you make some financial forecast it’s better be grounded. This is not something you can bluff at, not something you “fake it until you make it”, because what you are making or breaking is your career. What I am saying is: there is a progression, or at least there had been for me, from that little shader, all the way up to major projects.
Next time I’ll write about the story that lead to the Glimpse renderer, which eventually lead me to Pixar.