Getting all Procedural on the City - Interview with CityEngine's Pascal Mueller

I had the good fortune (and Alpine connections probably) to get to talk to Pascal Mueller the founder and brains behind Procedural who make one of the crazier bits of design software I've gotten my hands on CityEngine which you can use to design cities from the street and block up.

J: So why cities?

P: I believe cities are very fascinating from an architectural point of view, from a geometric point of view, and also of course from a social point of view. I’m a big fan of architecture and computer graphics, and cities are one of the biggest challenges in computer graphics. And, in the meantime, we learned that urban planning also has its challenges, and we can sometimes solve the corresponding problems they have with our methods, which we actually developed for computer graphics.

J: So it just came from graphics, then? It didn’t come from architecture, or did you just feel you were somewhere in between?

P: Somewhere in between, yeah. When I started my studies, at the last time before the deadline, I had to decide between architecture and computer science. At the end I took computer science mainly, and as a specialty graphics. But then in my master’s thesis and PhD I could come back to these things at the end. So, it’s kind of a hybrid thing.

J: So, you couldn’t make the decision, basically?

P: Exactly.

J: What about the suburbs, though? It seems very city-centric, but you know a lot of people don’t actually live in cities. They live outside of cities. Have you thought about this at all, or does this effect city engineering or your work with procedural modeling at all?

P: From a production point of view, suburbs are very easy to reproduce.

J: Okay.

P: There’s also a bit of a definition we had in suburbs. Designing good suburbs is something which is all about green life, quality of life, etcetera, having good connections to the big streets and stuff like this. Generally, suburbs are very important, but unfortunately they are created in a very procedural way, which often leads to not so nice suburbs. But, yeah, these can be simulated very easily.

J: It’s interesting that you said that suburbs are very procedural. Can you talk about that for a second?

P: Sure. I’m going to go to London. You have this London kind of style in the outer areas, and every building looks a bit the same. It might be the outer ring of London. In every building, on the floor you have the living room, and then these very thin buildings, red bricks on the back-side of every long garden. There’s a small garden. So all the houses are very, very similar. Of course, they do differ in a very, very small amount, but you know they are the same. The same thing goes the more you go out of the city, and they’re often single-family houses similar to each other. Of course, there are exceptions. For example, in the Netherlands all the buildings are built in the same way, which is of course totally different than, for example, Italy. But there you have other climates and other conditions to fulfill the customer’s needs.

J: Sure. So it basically worked like a computer program, but they developed organically. Like you said, they’re procedural already.

P: But I think what’s also a big influence here is investment money. Investing into suburban areas is something which gives the most profit when you create one building and place it along the street and repeat it four thousand times. Then you can optimize your profits, construction costs, et cetera. In the USA you have lots of these kinds of suburbs where one company says, “Oh, let’s go build another quarter million here,” and they create it.

J: Do you think CityEngine is set up like this? That it does it in the most economical way by default?

P: You can of course use it for this, yeah. But on the other side, you can also do the planning differently yet with more quality of life. You can do the planning better with CityEngine. Of course we hope that old methods, which can be very easily used in CityEngine, apply; that with CityEngine, we can apply the methods and improve them significantly. Hopefully you can plan it, and then you can also reduce the costs.

J: In the setup for the new users- I used the demo of CityEngine, and one of my colleagues in University of Nottingham did as well- you’re presented with these city models. I went through Berlin, Barcelona, all different types of models. One is, I think, ring-based. I can’t think of the names of the others off the top of my head. But it seems that in CityEngine- and there’s one that’s futuristic, which I think is really interesting, a future space city or something- there’s already a kind of basis, meaning that real life influences CityEngine. Do you think that the opposite could be true? That, eventually with software such as yours, cities and suburbs will start being influenced by the way that software works? To give an example, graphic design was very influenced by basically being able to lay things out on a computer. And that really changed graphic design a lot. I’m just curious about your thoughts on whether maybe the same will start happening in architecture and city development.

P: Definitely. As I said, it’s the old story of graphic design. Often you hear that these kinds of tools make a slave out of the designer. But, in my opinion, having good tools that help your design manifestations is not something which should be prohibited. I really think it’s a problem of the designer at the end, if he’s slave to the tool, and it’s not the problem of the tool. There’s the old saying one guy said once: “Shit in, shit out.” So really the tool is just the tool and nothing else. But because it’s a tool, it also allows new applications. For example, in CityEngine they can encode their zoning laws, so I think it’s not such a thing as having space-age stuff. Of course, cities have future visions, but in the real world, city administrations are pretty happy if they can have correct three-dimensional building envelopes, building shells with a number of stories. And then, for example, let’s assume they say we can change our zoning laws and you can build nearer to the streets. What are the consequences of such a decision? Stuff like this can be simulated in CityEngine, because zoning laws are nothing other than modeling rules. This is one the things I want to go into. Of course, we currently have a very professional user interface for pros, and not for the everyday city administrator. I think that what we have right now is the basis. I really hope that we can create better, more sustainable cities using procedural methods, and we have a very good basis for this.

J: Yeah. Yet, you were talking about what’s called in CityEngine “the rules.” So that’s how a building is formed from the street or a lot or a subdivision, like you said “zones,” and then the user can build, or rather let these things grow kind of semi-organically, or procedurally. But have you thought about- or maybe this is already being implemented- non-architectural or structural rules? For instance, let’s say this neighborhood’s collective income drops twenty percent, or this part of town is taxed higher. Would building happen differently, or is this part of zoning, like you said? Kind of economic rules, basically.

P: You can include such things, because we have the functionality called “reporting,” and we can generate Excel tables. Actually, it’s a very powerful feature, but we haven’t pushed it yet very much. We haven’t done much talking about it yet. We have such possibilities. Cities can change, for example, their floor area ratios and then the whole thing can be regenerated and recomputed in a very short amount of time.

J: So you could say that this part of town lost a lot of income, and then maybe buildings would start falling apart, or maybe building would happen more in certain areas. Because it seems like it does it all over the place very evenly and nicely, but as you know- well in London at any rate- it doesn’t happen like that at all. It’s very messy. Things happen in clusters where jobs and money are basically.

P: Yeah, of course you can control this with image maps in CityEngine if you want to do it manually. What we do not have yet is the needed context sensitivity. We have prototypes for this, but you need to know if you are in an area where there are no schools, but lot of industry. Maybe it’s a wrecked down part of the city. Cities are highly complex networks. We don’t do facility management, we don’t do graphic simulation, and stuff like this. Our focus is really urban planning visualization. And, of course, for urban planning you need the inputs at least from traffic simulation and urban planning, and you also need data from the current infrastructure, how it works, etcetera. For example, I think it will take at least ten years until building information models (B models) are also available to cities. For example, a city administration who knows each screw of each building in the city. It’s kind of scary.

J: Yeah, almost.

P: But this is stuff which will be known. We don’t want to do this scary database shit. What we want to do is create software so that people can design better.

J: Better cities. There seems to be a lot of talk on the internet about innovating services in cities, like there’s sites like in Australia it’s called “Buggered Mate,” and I think it’s fixmystreet.com. So there’s this thing about reporting anything using location-based services, but for things in the city, like broken water mains. Do you ever see CityEngine fulfilling this type of role? Like you said, if you know everything about a building, you can fix parts of the city, or maybe help it run better over time. So not just planning it, but helping maintain it through the city services.

P: Or report your neighbor.

J: Or that, yeah.

P: I know these kinds of services. We have been in talks with one of these guys. For me, it’s a little bit dangerous to watch it.

J: Why is that?

P: I don’t know. It’s just a personal opinion. Rather than reporting the hole in the street, reporting the hole in wall of the house of the neighbor. They go in that direction a little bit. Or graffiti and that sort of thing. It sounds a little bit like Brave New World. But anyway, from a technology point of view, I like it very much. I think it’s a great application. Generally, I don’t see this stuff yet going three-d. I think two-d is enough at the moment for these applications. You need to map where your issue is, and you photograph, and that’s it. Of course, if you can visualize it in a three-d way it is interesting, but again you have to send someone there to fix the street. For that, you don’t need a three-d model.

J: And just one last question. CityEngine’s procedure started basically as a school project. How, or even why, did you make the transition to a full-blown software company?

P: It was in 2007. The economy was very good back then. I got offers from the industry, but I also could have continued my career. I had a pretty good offers for post doc positions at Stanford and New York, but what fascinated me most about creating a company of my own, is that you can realize your ideas in the most effective way. At academia, the more you go up there, the more you just do money-raising and stuff. Before I started my PhD I worked two years in industry. I was always fascinated by creating innovation near to the industry. That’s a little bit the goal of procedural: to create a place of innovation, design, and engineering, which pays off.

J: So you can see other people using that to create their own businesses on top of procedural, or rather on top of CityEngine. Is that what you mean?

P: Long term, yes. Short term, I think it’s more a place for people to realize their innovative skills.