All right, hi everyone. I’m Madeleine Eggers, and I’m a senior computational designer at KPF, and I’m going to talk to you guys today about basically what I’ve backed out as the anatomy of computational building geometry, so basically these like foundational methods, or like atomic functions, underneath complex architectural design. Also, can everyone hear me okay? All right, cool, thank you.

0:24 So just a little bit about KPF: KPF is a global architecture firm with over 700 people and high-profile projects all over the world. We’ve built six of the world’s 12 tallest buildings, like maybe that metric has changed now, but while we’re known for our tall buildings, we’re ultimately focused on making great places, and we do this by basically believing in the power of urban architecture to transform cities. Doing this through crafted details and well-built interesting buildings, attention to context, and really affecting the built environment by what we’re putting there, and lastly doing this through innovative design.

1:02 So just a bit about me: I am a senior computational designer at KPF, I’ve been there for about four years now. My specialty is in exteriors in mega projects, and we’re currently like in the process of, I guess, conceptually realigning the computational design department, from see, being seen as like an internal consultant, to more of a key design collaborator, and we basically do that by plugging into produ projects at all phases. And it’s, it’s pretty important to like have a clear understanding of like what we’re trying to do as a team, considering that our team is really small, like we basically have four people right now in all of our offices together, fully fulltime on computation.

1:43 So, okay, so let’s talk a little bit about the big picture. So my thesis here is that computational design at scale is crucial to meet the industry’s evolving expectations. Like, this is not necessarily a new concept, like we’re all computational designers here, but the idea here is that, basically, as as we work to deliver these huge projects, what we really want to do is like basically be ahead of where the industry is going to be, like notice a trend and pick up on it.

2:08 So KPF delivers large-scale, ambitious and buildable projects, and so practically this means that details and articulation are getting worked out in conjunction with overall design moves, and may have a reciprocal relationship that will like necessarily transcend traditional design phases. So articulation and detailing are no longer happening like just in the later design phases, such as design development and construction administration, like we might be trying to anticipate these things in schematic design or concept, or like just that early in the project, just depending on the project constraints.

2:42 So also the amount of accuracy expected in early stages, such as like competitions, concepts, and even like a feasibility study, all of that is skyrocketing. So basically, to win competitions we need to show more detail than ever before, and have more things worked out than previously. Like a project that is going to win a competition in 2024 has so much more that we need to show we need to show like planning, we need to show efficiencies, we need to have the costs worked out, we need to have the the curtain walls worked out, like to be on budget, whereas in 2014 we might be able to get away with like eight renderings and some plans.

3:16 So basically clients are increasingly asking us, in the competition phase, to make projects with these ambitious concepts and iconic profiles, but also to show that we can make those things with simple kits of parts. And with the way that projects are moving and schedules are accelerating, we’re noticing that traditional design delivery methods of delting phasing clearly are declining and giving way to much more fluid boundaries between phases.

3:41 So just as a little bit of background: this is how architects design. We design in like very clear phases, so ideally we like settle these big design moves first in the early project lifespan, and then at the very end we’ll like move on to the details. So it’s like once the massing is done and dusted, then we can actually articulate it. This is all well and good for a non-accelerated schedule, but all of that goes sideways when construction schedules accelerate.

4:05 So kind of what benay was talking about, with the uncertainty principle, but when you’re on a mega project, a lot of that uncertainty comes from other people and procurement. So basically, like the level of design development is tied to procurement time, as opposed to traditional phases of like concept, schematic design, development and construction documents. So, for example, sometimes we have to get a curtain wall to 50%, like, while we’re still in concept, based off of the procurement schedule. So it’s very unpredictable.

4:32 So basically things are not linear like they used to be, large scale design is becoming more integrated at all phases. So, to get ahead of that, we need to integrate complexity early in the design process, and then crucially enable painless change down the line. So enter computational design, right? So for KPF it’s crucial to be able to iterate through design variations at a high level of detail when large design moves are still being settled. Of course, like the easiest time to change the design and catch issues is early in the process, so the earlier on we’re modeling in detail and optimizing over the whole scale of the project, the better.

5:06 So to me, this is computation value proposition. So big projects like KFS require a lot of coordination, optimization, documentation and complexity early on, so robust computational design at scale allows us to speed up our design decisions, validate them quickly, and then design while proactively anticipating change.

5:27 So this brings us to the idea of foundational methods, as a way of scaling up what a small computation team can do. So it needs to be said: making computational models of everything at every phase is very labor intensive. Like anyone who has ever done something computational will know, like it, it’s not short, it’s like, you know, some, some director will say, like, hey, you know, you have a magic computer, can’t you just like pull out like 10 options of this? We’re like, no, that actually takes a lot of time.

5:53 So when you’re working at KPF scale and speed, we need to be able to anticipate every computational task, but no two buildings are the same, and the problem with reusing our computational logics is that projects are very different. Like it might work for analytical tools, where the output is like amassing or analyz data, but when we’re generating detailed building geometry, the project constraints are very different. Like you could build the most robust tool in the world and still not be able to transfer that to another project instantaneously. So your constraints, your geometry, your data complexity, the things that you want to problem solve, these are all going to be different, and maybe even incompatible among projects.

6:33 So instead we’re looking at it with this framework: so every project is unique, we’re dealing with like different clients, contexts, optimization goals, but there’s a lot of consistencies and how we approach them computationally. So this idea is that we’re not recycling whole definitions, but instead breaking these computational logics into parts that are consistent, and then going about our computational processes more systematically. So through practice we’ve backed out these core functions that are instrumental to a lot of our computational design logics, and provide the underpinnings for most of our higher order design and analytical computational tasks.

7:10 So also taxonomizing our core functions like this lets us more intentionally reuse specific pro processes from project to project. So these methods are important because they form like the foundational 80% of the work itself. So the idea is that if we can document these processes and reliably turn them into re usable parts, we can speed up the foundational operations, which like make up 80%, and then spend our actual time on the 20% of the logic that’s actually project specific, in higher order. So basically the process is like, we find the basic operations that underpin what we need to do, we make those robust, and then we kind of just shuffle them around and recombine them from project to project.

7:50 So these are the core methods that we’ve identified as crucial to our work. So the first is data branching, where we’re placing geometry information into buckets to access and then process as groups. Second, we have point sorting, basically unifying the order in which points or other geometry are accessed and processed. Plane based calculation, where we’re setting the base plane from which every object is built or modified. Surface rebuilding, where we’re reconstructing surfaces or other geometry to process consistently or rationalize normally. And then cross referencing, where we’re creating permutations of data to process and access simultaneously, which is really great for testing all all like available options in your range of design spaces, or creating complex data trees.

8:38 So all of these are like fairly atomic functions, you know them, you love them, you’ve worked with them before, but basically anticipating what they’re going to do in every single context is actually what makes them robust, and kind of that’s where the challenge lies, right? If we can, if we kind of taxonomize and systemize them, the idea is that we can go about basically every single one of our projects by just recombining these in various ways.

9:01 So to get into that, I’ll bring up a couple of case studies. The first case study I’ll introduce is code named the cloud. So this is a 10-story double skin glass bubble that sits on top of a retail center, and this creates like a memorable icon in the skyline. So we were approached at the very end of DD, of course, to engage in a complex documentation task that had to be submitted in like 3 weeks.

9:24 So a major aspect of the submission was a 3D mod model with the position and fabrication information of every single panel keyed up and embedded, as well as CAD sheets for every panel. So the drawings had to be precise and responsible for documenting the design intent of every panel, which is not easy to do when you have a double skin facade containing 6,300 unique doubly curved panels, with each of which had unique frit and fabrication data. It’s also even harder when all of the outer shell has this unique frit pattern, to achieve this total gradient effect we were controlling every frit dot location down to 5 mm of resolution, so we had literally tens of millions of frit points that we had to process and document somehow.

10:03 So how did we do that? I will break down this process. So first, panels were given unique row column IDs to key in the workpoints, fabrication data and frit, so that’s basically our first step here, the row and column IDs. And also, I know it’s a little bit taboo to bring up a grass oper script on here, but since this is kind of the chef’s tour of like how do we actually do the things that we do, breaking it down into logics and then talking about how those things are actually recombinant, we’re going to go a little behind the scenes.

10:33 So this is where we basically assigned a row column ID to give it like basically a key in position, then we reported the panel fabrication information, so side lengths, positions, corner point locations, to excel, in 3D, and then to generate and document the frit we exported precise drawings of every panel’s frit location and scale, in addition to side, corner and ID information.

10:57 So let’s take a step back and look at the processes involved. Basically, to illustrate some of the core methods in play, I’m going to isolate this part of the process, the rebuilding and fabrication data reporting part. So this is what a seemingly simple operation like reporting all of the points and sides to excel actually entails, like if we work backwards from this. So the end goal is to report all the sides and points to excel, then we have to sort, so basically to get to that we have to make sure that all the points and sides are sorted in the correct order consistently across like 6,000 and plus panels and all the edge conditions.

11:32 So in order to get that right, we have to make sure that both of those are sorting along the same coordinate plane, and then to get that right we need to make sure that our sides are separated by the direction, and that the corner points are actually corner points. Like this is really hard when you have like a wraparound corner condition, or something that’s out of plane. Like things, things that seem simple when you’re like taking apart like one panel, suddenly get really really complicated, because you’re dealing with 6,000 of them, and not every single one is reported correctly.

Directly, then it’s basically branching it by row column ID, and in order to do all of those things we have to actually get those unified surface coordinate planes, and if we want to get the surface coordinate planes, we have to make sure that our surfaces are rebuilt correctly, so we can actually access those correct planes. So a lot of it is basically a complex operation that’s resting on a series of simple operations that are just, it’s crucial to get them 100% right, to account for every single side condition.

12:30 So the process seems simple. Yeah, when you’re accounting for hundreds or even thousands of unique edge conditions, you have to verify that all of the geometry at each stage is correct, to make sure that you’re documenting accurately in all cases, because you don’t always have time to check like every single CAD sheet and like verify it against the model itself. So the pro, basically, we just have to make sure that the process is correct.

12:49 So this is what we’re able to accomplish, so it’s a complicated documentation process, with thousands of edge conditions, and like a lot of frit data, which could actually just be boiled down into a series of chained and recombinant functions. So we’ll get a little bit more into that in the next case study.

13:05 So I’m going to present this one’s called One Island Drive in Miami. It’s a residential super tower with complex buildability requirements. So at the end of SD, the design team came to us with an emergency. So the client is, of course, cutting slab area to mute budget, but that was going to kill the major design move, which is this like big, you know, monumental taper.

13:27 So here’s the concept: we’ve got this like sail-like taper that defines the iconic tower form, and that’s like a big part of like the selling proposition here. Like they really didn’t want it to just be like this like, you know, normative like extrude from the ground, like it has to be this like really crazy shape. But also there’s these like big deep balconies that create furnished outdoor living rooms, that’s like the other big selling point here, is like this is an indoor outdoor living space, most of your life will take place outdoors. And then all of those outdoor living rooms had to have a brand view overlooking the Miami channel.

14:00 So of course, just to get into developer terms here, the unit selling value was a qu, was a, was a product of basically the quality of the usable balcony and the quality of the view. So here’s what the problem was: basically the balcony area was driving up the cost, but uniformly cutting it back to meet the area target would both, you wouldn’t be able to use these as an outdoor living room, because they just kind of become normal balconies now, so that, that’s out, and also it would really mess with the form. So basically this was a problem with the quality of the usable balcony.

14:33 Here’s how we went about solving it computationally: so first we worked with the team to identify balcony zones that drove value, so these are the areas where the depths really had to be maintained, in order to get that selling value up. Then we represented those critical areas as geometric regions, to basically use a class clash detection on. Meanwhile, we parameterized every point on every floor, and made them relational to both each other internally per floor, and then also so up the tower as the form is gradually changing. Then iterated through massing permutations and analyzed the results, basically area reduction versus the clash, and we did that for every floor simultaneously.

15:09 So we were running through 50,000 permutations of like every possible option of this tower, before arriving at an optimal range of options where we managed to reduce the slab area but include the most critical balcony zones. So we basically got it from like, they’re only meeting like 60% of their balconies, and they were already over area, we got it to be under area and meet 97% of like the balconies that we needed to do.

15:32 So how does that work? Chef’s tour: okay, so first we created the points and their motion constraints, then we sorted those points and created level and flor relationships, parameterized the tower curves, built out the tower, ran the clash detection, and then matched the outputs to the levels. And then lastly, at the very center of the whole thing, is the engine, where we cross referenced all of the inputs together, and matched up the inputs to the output, to basically say, you know, these are the forms that are associated with the best results that came out of this. So you can actually pull out 50% of this definition that is performing a core function.

16:08 So each of these operations is simple on its own, but can get quite complex when you need to catch like every single edge condition of a large project. So, ultimately, we were able to optimize the project to have great views, reduce the cooling loads, and actually have livable outdoor spaces, but we were able to do that like basically with a series of recombinant functions.

16:29 So the last case study I’ll present is called perfect Autoc Center. This is an office building in Shenzen. We were approached during design development about rationalizing every unique T fin wrapping the tower. So it’s, of course, like a rationalization problem: we got 302 fin types down to 10 fin types, and replace the unique members with rational members, like kind of a bread and butter rationalization task, as one does in design development.

16:52 So this is what the process looked like: so first we did some C clustering to get the edge lengths, and turn those clustered edge lengths into basically consistent building pieces, sorted those by depth and length, broke that down into surfaces, curved skeletons and way points, and then we just took those and assigned those back to their position on the building, and then exported it. So that’s a pretty simple rationalization task, but if you actually look at it, there’s not a lot that’s really project specific. All you have to do is basically do some data branching, sort some points, rebuild the surfaces, and calculate the planes.

17:32 So not every single rationalization is going to be the same on every project, but if we can get the atomic parts to basically be Rec combinant, we’re already 80% ahead of the game for the next time something similar to this comes in.

17:46 So if you look at the three projects that we presented, these processes are very different at their higher order functions, but we can really break that down into the same core methods, the usual suspects. So basically identifying and capturing these repeating elements helps our processes be more translatable from project to project, and it’s also a much more defined task to make a core method robust enough to catch all conditions and then recombine them, than it is to try to make the whole definition scalable to all conditions.

18:12 So inevitably, some variation on these higher order tasks is going to come up again on different projects, so then rather than building from scratch, we can use these kind of recombinant, like macronutrients, and just change the specifics. So we’re back on the 8020 prin: so having a simple foundational function base makes our computational methods more robust as information gets more complex, and allows us to do a lot more of like the fun part basically.

18:38 And the beauty of these atomic methods is that they don’t really change as the project grows in complexity, so unifying your planes or sorting your points around a source will be the same, whether you’re trying to figure out something schematically or at a high level of detail. So what we’re really getting at is a methodological foundation for architectural computational design work. So our core fun are accountable to our processes and distill down through iteration, so having an understanding of our core framework allowed this to become the backbone of almost every computational logic we create.

19:07 And also, this is what we found in architectural practice, so other industries may have different core functions, but the idea of laying a foundation of core reusable methods to build complexity around stays the same. Another thing is that, if your practi is developing a computational design department that’s like small, it’s NASA, you know, you want to do more with less. Whether you’re an AEC or any other application, distinguishing between your core functions and your project specific work will actually allow a smaller team to accomplish a lot more. So by decoupling what’s project specific from what’s repeatable, computational design teams can create more adaptable reusable processes that make teams efficient in the short term, and ultimately better able to handle the changing nature of the architectural practice in the long term. Thank you.