Kavita Bala receives 2020 Computer Graphics Achievement Award

I tried several areas of research before I settled on graphics. When I arrived at MIT, I was interested in Compilers and Systems, and I completed my Masters in Operating Systems. Around that time, Seth Teller and Julie Dorsey both joined the MIT faculty; I attended their job talks and just found their work so fun! I was very interested in human perception, and loved the way their work connected that with visual knowledge and algorithms. I went to SIGGRAPH 1995, before I had taken any courses or done any work in the field. And I found it incredibly inspiring: SIGGRAPH is one of the few (if not only) academic conferences that is accessible to anyone. Even if you aren't working in the field, and just want a taste of what's going on, there's a part of every talk that makes sense. You can understand the motivation, and maybe even some of the techniques they use, even if you don't understand the details. Before attending SIGGRAPH, I had mentioned to Seth that I might want to do graphics; but I came back from that experience determined to make the jump, so I said "Yep, I'm in!" And I've been here and loving it ever since.

I started out by looking at scalable physically-based rendering, and then over my career incorporated a whole series of work on material models, perception, and visual recognition. Most of these projects came about organically, and I see them as a natural progression. For example, the goal of physically-based rendering is to produce realistic images. But material perception is inherently part of this: if I want to reproduce a fabric like silk or velvet, what properties of that material need to be replicated in order for us to perceive it correctly? The natural corollary in the real world is, 'why does silk look like silk, and velvet like velvet? What is it that we care about from a perception point of view?' Even before these complicated materials came into play, rendering researchers faced similar perceptual questions. For instance, what approximations can you make such that a rendering looks 'good enough' while being as efficient/scalable as possible? In my early rendering research, we tried controlling the quantitative error introduced by the approximations, but ultimately you're producing an image for a person, so perceptual metrics are critical. Once we've identified a cool problem, we just keep chipping away at it, and asking ourselves "What is it going to take to make this really work? What does this need to be practical and useful?" Then we follow that thread wherever it takes us. This is what drives a lot of my work in both Graphics and Vision.

This wide array of projects and techniques also suits my personal research style. Some people have a favorite tool or approach, and they like to stick to that signature thing in all of their work. Lots of great research can come from that! But for me, variety is exciting. I like pulling these very different techniques together, to solve a single broad problem end-to-end. I don't have any favorites among my projects, as each of them are fun in different ways. I like the full array of types of thinking that comes into my projects: some days I design perceptual protocols, and other days I get to work on more physics-y or mathematical problems. If you are also like that, feel free to enjoy that breadth! Don't feel like you have to box yourself into a single area that you don't enjoy as much.

In my SIGGRAPH Award talk, I discuss 4 strategies for selecting research problems:

1. Expand the problem domain: Don't box yourself into the same problem the field has always solved. In rendering, once we started to succeed with simpler models, we introduced new layers of complexity with more intricate materials and lighting setups.

2. Critically consider whether you are solving the right problem: This is related to the first point, but assumes you have found your problem domain but may still be solving the wrong problem in it. For example, we have worked on the problem of Intrinsic Image Decomposition, where the goal is to decouple the albedo and shading layers in an image. When we approached this problem, the field had reached a stagnant position: everyone was optimizing for the same benchmark, and the errors had gotten close to zero in state-of-the-art techniques. But at the same time, everybody knew that these 'perfect' algorithms did not perform well on real world images. One of our biggest contributions was to challenge the status quo, by saying 'There's a real world out there, and it has nothing to do with this academic dataset. We need to gather real-world data with meaningful perceptual labels, and work off of that.' This opened up a lot of new possibilities for growth.

3. Pretend your problem is fully solved, and explore potential applications: We did this with visual recognition, where we assumed that a perfect tool existed, then teamed up with a cultural anthropologist to explore the kinds of things we might do with that tool. This kind of cross-disciplinary work is very exciting because it can open whole new areas.

4. Pick problems that you love working on: You'll do your best work when you are having fun.

As far as scoping goes – this is often not a precise strategy, and it varies from paper to paper. In this case, deadlines really help. Some fields like Vision also impose a page limit, which affects the scope of your project, but SIGGRAPH doesn't have that. There's just this sentiment in SIGGRAPH, that I really like, that an idea needs the number of pages it needs – you don't have to stretch a 4 page idea to 8 pages, or shrink a 12-page idea to fit. Instead, you have the freedom to look at your project and say "You know, this is useful as is. Sure there's more I can do, and I can keep waiting for the next three years, but this is a nice chunk." This is especially useful when we don't have an obvious solution to the next part, so we can ship the current piece out, then step back and scratch our heads a little bit.

My former PhD student Shuang Zhao has a particularly effective approach for scoping: he defines the "dumb zero", or the simplest possible approach to our problem. We'd think that this would be easy to get done, then plan all the things we'd do once it worked. However, that first step often turned out to be a whole substantial paper, because it usually ended up being very hard! It wasn't dumb, and it wasn't zero: it took us a while to get it working, and ended up being a big contribution on its own. There's almost always more to do, but we share it because we think it's at a point where other people in the community might find it interesting, and it has the potential to seed more research threads.

I love the intellectual growth and the people I get to work with as a Professor. You are learning continuously as a professor – whether you are teaching, mentoring, or doing research. Even if you've taught a course 20 times, you will still make new connections, and have realizations about new ways to think about concepts. And in fact, if you get to the point where you've taught a class so much that you aren't learning from it, you should take a break. You should never get in a rut. As far as I'm concerned, the secret to eternal youth is not about the state of your looks but rather the state of your brain – as a professor, you constantly get new students with great new ideas, and the joy of working with them is hard to beat.

After I completed my Masters in Operating Systems, I briefly considered leaving academia; OS research wasn't quite working for me, and that would have been a logical time to transition to industry. It's hard to say what I would have done if I hadn't been drawn into Graphics at that moment – maybe it would have started working for me, or maybe I would have left, I don't know. But I decided to jump to Graphics. The move was scary and sometimes demoralizing, as I was a senior student but I felt far behind the younger students that had been exposed to graphics much earlier. However, it was also one of the best decisions I've made and I'm very happy with my choice!

(Laughs) I always felt I was not ready for this new job (whatever this job was). But I enjoy learning, so I find trying out new jobs incredibly exciting. I love the early stages of a new job, when you're learning what the new challenges are. The start-up experience was a particularly good example of this. I was an academic through and through – having moved straight from my PhD to postdoc then Faculty positions, in a small, tight-knit Graphics community. The startup is the wild west by comparison: everyone's on the ground floor together, and nobody knows or cares who you are. Many academics-turned-entrepreneurs find this challenging, but I enjoyed it, and the way it questioned my assumptions.

Similarly, when I came back from my 2-year sabbatical, I immediately jumped into my new role of Chair of Computer Science, and now more recently as Dean of Computing and Information Science. This is one of those surreal transitions, like when you first become a Professor after being a student for so long, and suddenly, you realize you are the one in charge. As Chair and now Dean, I sometimes have the senior-most members of the department looking to me for guidance, and there's a moment where you think "Oh, that has flipped around." But if you are committed to learning in your job over time you build the experience to trust your instincts.

In general, I think that trying new things makes you better at what you are. For example, if you're considering taking on your first student mentee: that's exactly the right thing to do! You'll learn so much while being a mentor that it will teach you about being a better researcher, too. Or, if you're thinking about serving on a Program Committee: people often say no to this because of the time commitment, but I've gotten a lot out of serving on committees even when the load adds up. In particular, serving on these committees gives you a sense of the intellectual growth of the field, which is very hard to get if you disconnect from the larger community and say "I'm just going to write my papers and send those out, but I don’t have time to review papers." All of these things are supposed to work mutually, to benefit the mentees and the mentors. So dive in, and trust your instincts!

Managing all aspects of my life (personal and professional) can be very intense, with long days and weeks – this is maybe not what I should say, but there are entire semesters when, for most of the time, I've run on 4 hours of sleep per night, with a little bit of catch-up on the weekends. But I did it because what I was working on was fun, and that's the most important criterion to use. It's not like I had to set an alarm for myself to wake up in the morning; I would just pop right out of bed at 4am and get started each morning.

I have three children with my husband, who is also a CS Professor at Cornell, focused on Security and Programming Languages. We joke that we don't necessarily achieve work-life balance, but rather what we are aiming for is a lifestyle that is both intellectually and personally deeply rewarding. But it can get quite imbalanced at times between all the competing demands. Two of our children were born before either of us were tenured, because we didn't want to wait on our personal life. We felt that we had to live our lives, not put them on hold for academia's timeline. Our third child was born just 12 days before the SIGGRAPH deadline, where I was working on two different papers. In those days, I was having so many long Skype calls with my co-authors that the baby probably thought they were all part of the extended family! My husband and I figure out how to balance each other’s professional commitments. Our deadlines don't match, so we just go back and forth between us to make sure that each of us, and now our children too, is able to achieve the personal and professional fulfillment we hope to achieve.

I think overall, you just make it work if you love what you do. Of course, you won't like every aspect of your job. Take teaching, for example. I love teaching and I love working with students, but I hate re-grade requests. In fact, I don't particularly enjoy grading either, with rubrics and people complaining about grades. But it's all part of the deal. Similarly, as Dean, it's amazing to think about the Departments and their strategy at a high level, to shape programs and decide what the priorities should be. But at the same time, you are the one who gets to respond to the crises and complaints as well. And of course, it's the same with research – there's a part which is really fun, and for me, that's actually thinking about what the problem is, and doing the work with wonderful collaborators. On the not-so-fun side, your paper can get rejected, and you have to revise your papers. Every job comes with an unpleasant part of it, but in totality, if the things you enjoy overshadow the things you don't, then it's worth doing.