The Conceptual Design Process framework: from the raw idea to the digital model

PAOLO GALLI: You know, I'm Italian. I'm supposed to be in loud and noisy and whatever and make a lot of a gestures with the hand, but a microphone helps in these cases. By the way, there are a lot of slides so I'll try to be as quick as possible. We will go through these points. So an initial boring introduction. So we try to understand together-- we will try to tell you our point of view about what conceptual design is. Where is architecture? Interesting point, a strange question, actually.

The CDP Framework, conceptually same process, and what happened in White Architects and some ideas, some brainstorming about the future steps. OK, let's start. Some rules. You will be ours for the next 60 minutes. OK, if you don't want to switch off your mobile phone you can just mute them, but if you want to use them, you are allowed just to tell great is this session. Thank you for being here. Enjoy the travel of ideas. Let's get conceptual and let's start.

Oh, other questions. How boring. Why this presentation? Why are we here? I don't know if you've noticed, but here at AU, we saw a lot of great presentations about engineering services, advanced stuff and whatever. But here, we are here to discuss about conceptual design and architecture, so this presentation is because every project starts with a sketch, because we need to create a bridge and fill the gap between pencil and pixels. We are architects, or at least I suppose many of you are architects, and we are a creature of habit. The design is not just a set of drawings or a model or whatever.

The designer is a large lifecycle, so we need to deal with that. We must create and add value, because we are architects. We know we have a big responsibility on the future of other people. We need to add value. And last but not least, we want to have fun again. We want to have fun from being an architect. OK, second production.

FOUAD KHALIL: I'll just introduce myself. My name is Fouad Khalil, I was the technical lead on the White side for this project, and from I think 2012 to '17 I was Creative Director at White in Linkoping at the Linkoping office and also served as an IT Methodology leader. And I'm no longer with White. I'm currently at another firm, but I'm presenting from White. I just actually switched jobs a few weeks ago.

So my presentation will focus more on the technical implementation of the conceptual design solution. So where I think Paolo will frame the larger picture, what I'd like to do is give you a sense of what we did, what our kind of metrics were, what the process was, and the result. And that'll be the second half of the presentation.

PAOLO GALLI: And this is me. Paolo Galli, Italian. I think you've noticed that. I have a background as an architect. I joined Autodesk five years ago, almost six actually, but the past 12 years, I would say even 15 in some cases, implementing BIM, dealing with Revit and horsing around the BIM and Revit, all this stuff. What I'm doing. I'm belonging to the BIM Transformation Team [INAUDIBLE]. Well, I work mostly in Europe. My competencies are more related to BIM implementation but with the architecture flavor.

I had the opportunity to work on business development activities, shaping a solution, solution offering definition, creation or standard procedure, whatever whatever. OK, I don't want to bore you reading all the lines. I have a Master in architecture in Rome. I also studied in Spain and in Argentina. That's it I will be boring you for the next 20, 25 minutes. So that's it. What is the conceptual design process?

Oh, interesting question, because what is conceptual design? Just some questions. I don't know the answers. But just some questions I want to share with you. Modeling for fine things, optimizing, creating, evaluating scenarios, decision making, sketching, conceptual design. What is conceptual design? Is it massing? Revit massing, FormIt? Oh, I don't know if I can say it. SketchUp. Being that I'm an expert or at least I'm supposed to be, people usually ask me, Paolo, what do you think is the best tool to do conceptual design?

What is the best conceptual design tool? Woah, good question. SketchUp. No, well I mean, it's hard to tell, because I still haven't understood what conceptual design is. And so I can tell you what's my best-- or in my opinion for doing conceptual design-- you know, I'm an Autodesk man, so you can imagine what my answer is. I can also show you-- oh, this. Great tool, beautiful, absolutely beautiful.

I'm still an architect, so when I have a new design to approach, instead of opening the computer or taking the paper, the white paper-- big issue or the worst enemy of the architect, the white paper. I take my ukulele. I love ukulele. Only four strings, the right number of strings, I think. And the world would be a better place if everyone would play the ukulele. But wait, I start playing, and I imagine to be on the shore of Maui listening to the waves on the sand. And so this way, I leave my brain free to think.

Free to think, free not to think to the conceptual design, to the tool, to the project. I want my brain to be free. So the point is, conceptual design is not a tool. It's something more. And let's go through. I have some questions, again, some keywords I would say. Again, these are keywords just to help us to think about what conceptual design is. I found very useful for me, for myself at least, thinking about these words. So obviously, conceptual. Responsibility. I love our book from Renzo Piano, The Responsibilities of Architect.

We are designing the future of other people. Ideas. Intent, the design intent. Scenarios, defining vision, giving a vision. Out of the box. Thinking, not taking everything for granted. Iteration, reuse, structure verses flexible, interesting. What is architecture and where is architecture? Oh, this is my mistake. I wanted to write where. I wrote what. But where is architecture? Actually, just imagine the project lifecycle.

We have a large lifecycle for the project in which at the very beginning, we the architects are supposed to look for scenarios, responding and completion with the requirements, trying to satisfy what the requirements want to solve with the architecture. So we are there to find a shape, to find scenarios, to find a solution. But after a solution has been chosen, the degrees of freedom decrease, because obviously once we've chosen that specific shape of a specific scenario, well adding LOD-- I mean, level of definition or liberal of development-- to the project, we lose the possibility to make major changes.

This is just to say that maybe the most of the effort of the architect is at the very beginning in the concept phase, because it's there that you can give the footprint and guiding the project on a specific rail, a specific direction. This means that we have a big responsibility, because we are feeding technology requirements with use requirements with architectural requirements. All the downstream uses, all the other disciplines, we have a big responsibility. So this is my estimation based on my experience.

The degrees of freedom, so the amount of effort of an architect maybe is 80% on the concept, 15, 20 on the preliminary detail. Well, during the detail design, we can decide the material, finishing some small details, but we cannot change so much of the project. We cannot give a large footprint. This has been already given. And over zero, maybe. Obviously, for transformation, this life cycle begins again. What's happened? Conceptual design. Every project begins with a sketch.

Actually, I notice that there are a lot of sketches on the internet done by famous architects, and this means that maybe sketch art is still an important part of our job, at least at the very beginning. This is Michelangelo, this is Palladio, Rogers, Renzo Piano, [INAUDIBLE]. The worst enemy of the designer, of the architect, the white paper. Once you have your white paper in front of you or you have a ukulele, and this will help you, otherwise it will be very, very hard. And this obviously requires coffee, just to be clear, and it's a very important part. But the point is we are in 2017.

We should understand what is a sketch, what a sketch means during the BIM era. And I think this is a quite important question. Is this a sketch? Is this a sketch? A digital sketch? Now, I don't know. Is this a sketch? Starting with clay models, forgetting, using photogrammetry, digital models. Is this a sketch? I'm not giving you the answer. I don't know the answer. I'm still investigating it. But I want to share with you my experience and this process, the growth process, because again, I do believe that we have a strong responsibility as an architect.

The big misunderstanding. About one year ago, I think Fouad, we had the opportunity to start working with White architects in Sweden, and we were supposed to investigate our technology to see how, in which degree, we were able to help White architects to approach the conceptual design. And we started thinking about a typical set of activities based on a timeline, describing what that conceptual design process is. And what happened is that we understood that this was a big misunderstanding, because thanks to the interaction and discussion we had with White architects, we understood that the conceptual design is not a linear process.

A process is defined as the set, the sequence of rational activities with the aim of transforming some input in output. And this is something different, because we have a linear sequence or task in a standard production process, while for conceptual architects, conceptual design, we have a nonlinear iterative framework. Typically, a process wants inputs to be transformed to output, but while here we have transformation of requirements to scenarios. OK, scenario can be an output, it's just semantic. Just try to understand the deep meaning of that.

Clear roles and responsibilities on one hand and fluid and flexible set of roles and responsibilities for conceptual design. It's not always so clear once you have to find the idea, the design intent, identify what you are going on. It's very difficult giving specific stuck roads, fixed roads. This is an important point. The design development is based on an existing design. Here, the design doesn't exist yet. We need to find the design intent, and the design intent, the idea, is the main output. Little change is allowed, large change is expected.

High LOD, low, very low LOD. It's still BIM. We need to understand that the level of definition of an element is very low. This means that many changes are expected, and we need to act in consequence. OK, just an image. CDP substrate, substrate design process substrate. Other key words or sentences just to help you but help me, actually, to better understand this point. What we learned is that we need to change lenses often. It's like a camera. So we need to move from general to particular to general to particular. I mean, trying to see the project from different angles often, continuously.

Keywords-- communicate, speak, have arguments, fight. It's not a peaceful process, the conceptual design process. And often big friendship goes out during this process. But OK, we have a nonlinear process, again. Use non-standard approaches. For this reason it was very hard trying to understand how to use a process for describing something which is not a process. Mix digital and analogic methods. The Bucket and the Funnel, what is that? OK, bucket, funnel. We identified a couple of components, conceptual components. We have a funnel which is a filter which drives ideas in a specific direction, and we have below a bucket, which is a blind container.

Actually, my first impression with conceptual design is having a bucket in which I put ideas, I mix them together, I keep out and see what's happening. Oh, I like, I don't like. Maybe I need to mix them all something more. So some key words here, again, the funnel is often related to analysis, tool of the task with the aim of understanding or evaluating or reviewing. The bucket the something related to massing, sketching, brainstorming, mistakes and whatever. Try to think out of the box.

This is another keyword we learned, another sentence we learned. And do not take anything for granted. It's not just a production process. I suppose you know this is a pie chart. OK, great. What we did-- what we learned is that having a linear process is a big misunderstanding. We have more than a linear process. We have like a gear, a mechanism, in which we have an external gear, an external engine pushing the movement. It doesn't depend on us. External decisions, requirements or whatever.

And we have a set of internal decisions represented by another big mechanism which is a gear composed of three wheels, and this is the approach we developed together. These three wheels are representing-- in the center the output, and the three rings, the three wheels inside the gear represent a set of components, of solution components. The first one touching the outside gear is the analysis. Then, we have co-creation. I love co-creation, this word. That this is something White uses. This means collaborative creation, and it's great. It's a great word, I think, for representing what we are doing with conceptual design.

And then something related to the analysis. Again, the idea here is that each wheel is composed as an orange of segments. Each segment belongs to the specific wheel, and connecting these segments in a specific way can help us to shape a path for solving a specific conceptual design. These are the segments we went through with White. Let me go to the next slide, because I think this helps you to better understand what we did. Imagine that in this mechanism, we have an internal mechanism composed of other small gears. On the outside, we have all the main stuff, the main activities related to the analysis.

Before I told you this is not a process, it's a framework. But obviously, we need to bring some order, some standardization. So the idea is instead of standardizing the whole process, we standardize the pieces, the small pieces, the micro uses of our information models. Depending on the way we connect these pieces, we can shape a different path for solving different issues. Imagine we have an internal refurbishment of an existing building. We are not interested on context analysis, maybe, because I only have to organize the internal space.

So this segment won't be involved, won't be included. What are-- and this is a sample path, just to say. We can connect different segments, we can take the documentation and the structure and the tools for completion with the segment. These help me also to use the right set of people, to select the right team, because it's very clear. And next, what are the issues here? Is that the main components of the solution is the set of solution components, the segments, and the interface resolution when data moved from a segment to another.

And this interface obviously changes if data are moving in this direction or on the other. Some possible paths we defined for solving specific aspects of the design. OK, there's something very Autodesk, but I'm proud of this scheme. This has been developed by my former manager Brian Lopez, and it defines the BIM use. What's a BIM use? We are using the naming convention given by Penn State University. The BIN use is the use you do of an information model, the scope, the final scope of an information model. And for a BIM use, you always have some data, input and output, a process for transforming this data, and obviously a technology system, the software.

For this reason, we define each segment as a micro BIM use. Each segment-- so context creation, space analysis, volume studies, energy analysis, [INAUDIBLE] and whatever, graphical production-- we define all these segments, all these small pieces as micro-BIM uses. So for each of them, we define the scope, just to understand why we need that specific segment or not. What are the data? I, O, input and output involved, what's the process, and what are the involved tools? And the same for interfaces. We try to define how solve interfaces in order to better understand what could be the most seamless way for moving data from a segment to another in terms again of data process and in this case people, because different people with different roles or different skills have to speak in this case.

This is the conceptual architecture we defined for the regional solution. Obviously now, something is changed, because we don't have anymore ReMake. We have ReCap photo, now. But OK, the main aim remains. As you can see, the conceptual architecture is based on both local and cloud services in order to allow to use standardized software but also to design everywhere and give to people the possibility to access the models everywhere anytime. This is the standard organization we gave to the documentation, so all the set of documents have this very same organization. This means that if you need to understand a specific aspect of a single segment, you know that you will always have the documentation split and organized in the same way.

And these are the high level description of all the segments belonging to the tree wheels. Analysis-- and we think, we define that with White-- that the set of 11 segments we defined can help to approach pretty much all kinds of conceptual designs, architectural designs. So we have context creation, special-- oh, this is not creation. It should be analysis. My mistake. Area analysis, performance analysis. I mean, all helps you to understand the initial situation but also to evaluate an existing model, because remember the path. The path can go to the co-creation and can come back to be evaluated.

The same for co-creation. We have the Hands Back Process. The Hands Back is an interesting segment we created, and the meaning is give me the possibility to use again my hands. So give me the possibility to feel the bridge between pixels, a pencil and pixels. So help me to understand how to use the pencil, the clay or whatever for feeding the digital models. And for this, we involve the sketchbook, Revit, ReCap, and all the stuff allowing us and helping us to give a more human interface to the process.

Space planning-- the segment involved on the definition on how to create a floor plan distribution but for that later will give us more details. And OK, I don't think it's interesting commenting all the segments, because there are 11 segments and I know I am boring you. Visualization-- there's an interesting segment here, process of visualization. It's the segment helping me to create a process for capturing a design shape. And the set of properties of a specific design, it needs during its lifecycle just to demonstrate what was the path followed for achieving that result and to help also the people, the people team to learn for the next time on how a specific design has been developed in order to reuse that experience or correct some issues.

For each segment, we define the possible interfaces. So for the context analysis, for the space planning or whatever, we define what, where? The segments feeding with data or the possible segment feedings with data, the space planning or the specific segment, and the segments fed by the current segment, because remember the scheme, it's very, very important solving these interfaces, because interfaces are a crucial, critical part while shaping your solution, your project organization. That's it. Fouad? I'm sorry to have bored you, but I like speak, and when I give a public, it's terrible to me.

FOUAD KHALIL: Thanks, Paolo. OK, so just a little context here. It's little faint, but this was a co-collaborative process launched with Autodesk and White. So I should introduce White to you. White Arkitekter is an interdisciplinary practice for architecture, urban design, landscape architecture, and interior design. Embedded in the work of White is a commitment to sustainability in all its forms, underpinned by practice based research. As a collective of 900 employees organized in networks across 15 offices in Sweden, Denmark, Norway, and the United Kingdom, White works with clients and consultants to create inclusive, resilient architecture that inspires sustainable ways of life.

I think it's kind of one of the interesting features about White-- and it has to do with the Nordic context-- is that the work there is intensely collaborative and quite open. Teams tend to be very horizontal and multidisciplinary. We have a lot of specialists working at White, and one of the ways we try to tap into the expertise with the specialists is the workshopping process, which is really essential. And it's quite normal, actually, in the Nordics to workshop public sector, private sector, I mean really across all segments. And that was a key aspect of how we went about setting this up.

This is just some of the work I was involved with. This is the student center in Linkoping which is under construction now. This was not the candidate project we chose. After we had worked on the workshops, we chose a this project, which was a competition for a kind of a college and mixed use development in Linkoping This is a public space in front that resulted out of the competition effort. We used the competition to launch the technical solution for the conceptual design, so it's really important that we prototyped the conceptual design toolset while we were actually doing an actual project so that we could drill down the segments, get them to work, and also test case them in an actual project environment.

We didn't want to just stop this with an off the shelf solution that nobody was really going to be able to use. Obviously, this presented some challenges, but I think at the end we were quite pleased with the result. So just a little bit on the project. This is a couple of the boards that came out of this. This is a project for Kungsberg School, which is a school in Linkoping. It's actually more of a college and vocational school. It's a mixed use development as well, so it's two blocks, 80,000 square feet of education and totaling about 250,000 square feet or the equivalent in meters. I'm American now, so I've lost the metric.

It's got office, retail, involved a large urban planning component, and a significant architectural component. And this project, basically the production time on this was about, I'd say, less than two months using the tool set. And so it was a very, very kind of a Scrum-based, very, very fast development. And we were able to use the solution effectively to get there. So features of the solution that we wanted to implement-- we really needed to tightly track program area requirements through all phases of this conceptual design. So competition briefs in Sweden are actually binding, and it's very easy to get disqualified.

There's a big culture of architectural competitions in the Nordics, but the requirements tend to be quite strict, and you can be disqualified for something like going over on a science program area. So it's very, very important for us that we track program areas throughout and we maintain a very tight envelope around the program areas. We really wanted to be able to harmonize the graphic output. So for example, we needed the solution to track exactly a plan section, exploded acts on, tables, we needed-- the colors are a little faint, but something like color control where we're tracking the exact value of the color for our program areas and across all this kind of output was something that was really important. We really wanted to have one model to output all of the work.

That was really essential. So what we didn't want to have is a visualization model that was done by one team and a programming model that was done by another and another set of information that was running the bubble diagramming process. We needed actually all of that to be tightly woven. So everything you see on these two boards was output from the exact same model, and that was really a key feature. It basically meant that we were slow in the beginning and very fast at the end. The other thing that we were trying to do-- and this kind of goes back to the inclusive culture-- is that we didn't want this to be just a team of early adopters. It actually had to be implementable across multiple skill levels for our team.

So everything from a senior project manager who didn't have a lot of Revit experience or wasn't really into working with models but tended to work with things like program areas or Excel spreadsheets, to your production people who may be somewhat savvy, to your early adopter who's also working on the team. So it was important in the workshopping process to identify each kind of user case need and try to build a tool around that. So what we kind of ended up with here are three tracks, three parallel tracks that are going on during conceptual design in this case. And the track-- we had the BIM track, which is the generation of the building information.

We had the management and programming track, which basically is tracking these program areas and making sure that the functional requirements are met. And we had the exterior track, which is modeling the exterior scan, and the overall massing and then testing that against the program and the functional requirements. So these three things are being launched and developed at the same time. And then the tool set that we used involved Excel, FormIt, AutoCAD, Revit, 3D Studio, Dynamo, and the Creative Suite. And that's where really we were helped a lot by Autodesk and the expertise they brought helping us knit these pieces together.

That's really what kind of created this coherent solution. So what you see that's really key here that's a big part of this is in the management track, we represent that basically with an Excel spreadsheet. So if you can imagine you've got a program that's coming in from a client or it's being generated internally, that's just a simple spreadsheet that's being used to run the data for the project. And we actually-- since that's often the case, we had that Excel resource drive the data back and forth from something like the bubble diagram back to the Excel for validation to the initial massing study. Again, that gets pushed out back to the Excel file for check, and then that's used to develop more and more detailed outputs both for the design and then for the ultimate for visualization output or basically the graphics.

So we're using this as a storehouse of the data and making sure that's the control. This keeps everything consistent. Meanwhile, these things are developing along and they're basically being used to check against with the Excel file. So just to get into that, our first segment, really what we wanted to explore was early massing but basically bubble diagramming the functional spaces. So we have the massing and the exteriors is developing on a separate track, so we have the overall form and the urban design for the project.

We used a program called Gephi, which is an open source program for bubble diagram. It's very easy to use and it's free, and we used that to develop the bubble diagram. That is using data that's being brought in from the initial Excel file. And then we're using FormIt, this was our first foray into FormIt, to develop the overall massing. And the spaces are developed in the bubble diagram mode, and then the results being exported back to the Excel, as I said. So just a quick look at the FormIt. So this is really kind of where I started working.

So myself and a couple of colleagues or using FormIt to develop the initial sketches. This is one of the initial studies, and we really liked FormIt. I don't know, how many people here are familiar with the FormIt tool? Yeah, I thought it was really fun to use. I enjoyed using it. It's got its kind of clicks, you know, it's got its unique things, but in terms of interoperability and some of the functionality we needed to use very quickly, the FormIt tool was really successful. We really liked the geolocation, the Revit portability, we liked that we're able to bring in Sketchup, we really, really loved the gross area at a glance.

This was really invaluable, so being able to select and understand what your gross area is when you're in the initial modeling phase at a click, that helps a lot. And it keeps you from needing to use a CAD file to track your area separately, which we didn't want to do. And then the levels. So being able to assign levels and have those levels port into your Revit model, that was really great too. Again, at a glance, areas by level-- as the model developed and we're able to pull those, we know floor by floor what's going on, that was really great. If any FormIt developers are here, the ability to assign a department or a use and be able to kind of drill down on your square footages and get so much to this assigned area, so that would be even better.

So assigning a parameter to some of these volumes and then being able to subdivide your gross totals would be even awesomer. So that's going on. In the meantime, our team is using this Gephi program to get the spaces firmed up. And so what you're looking at here is the Gephi interface and the solution, so you can play with this tool pretty easily. Everybody on our team got oriented and was using it on their own. It's really not very hard to use, and we have documentation on how to bring in Excel and develop bubble diagrams in Gephi for anybody interested. But you see there at the corner is our-- I think we've got a shot of the Excel file.

It also has-- there's an Excel file, and then this is kind of the Gephi equivalent. So it has a tabular way to track square footages. And then this is all kind of linked to the table. So all of this is to scale and it's correct, and you can assign colors for your departments in the same way you would in a diagram. So once after that Gephi development gets going, we're exporting the result back to the Excel as a simple CSV. There's nothing fancy about that. But in the next stage, what we really wanted to do was import that information into Revit and start setting up block diagrams like basically stacking diagrams.

And we wanted to have the color controlled centrally, so we didn't want every team members setting their own colors, because that actually sounds really silly, but that ends up wasting a lot of time if you make the wrong mistakes. And we needed to track that in a schedule, so the schedule was preset in a template. So Autodesk helped us develop a template where all these resources were really primed and ready. All we had to do is get the data in. So this is the file we used to instantiate. This is basically taking the data-- this is the script file in Dynamo-- it takes the data from the Excel file and generates simple boxes that can be manipulated to create stacking diagram in 3D.

We also were following a standardized method for developing the scripts so that this could be shared across the entire firm and everybody would always know how to use the scripts, and that had to do with developing an annotation. You know, there's just a standard for annotation, a standard for user input, and then trying to describe the basic steps as groups, as colored coded groups. And what this allowed us to do during training was actually get new users under the hood and begin to orient them to Dynamo and what Dynamo can do without really intimidating them too much about worrying about the individual nodes. You can just kind of understand how the process is unfolding in the script without having initial knowledge, any real knowledge of Dynamo.

And then the second fill- and we kind of broke it down into scripts. So we didn't want one script doing all the work. We wanted to have bit-sized pieces. So the second one basically applies the color. It looks to the Excel file, actually, is where we set the colors, and then it colors by department according to the Excel file. So this is the result here. So you get this kind of array of area boxes that are stretchable. They're all color coded according to the colors that are set in the Excel file by the manager, the digital or the virtual manager. That's a little tab in the Excel file where you can set colors, and it just runs a little macro that says, these are the RGB values, now read these RGB values and apply those to all the areas with this parameter in the group.

And then your data is populating into the parameters of the boxes. So you can do things like get totals, track what the target area is versus the actual area once you begin stretching, that was really important. So that's kind of the first step. And then we have this schedule preloaded, and it's got a conditional format. So if your areas start to deviate, say, greater than 5% of what the target is, it starts flagging it red. And that's preloaded, so nobody has to mess with the setting that up. It's already in there. As soon as they create, they can get the read on where they are. Once they're finished with the stacking diagram, we take that data and export it back to the Excel, so we have a running track record at every stage of how is the area, how are we doing at this stage?

How are we doing on the next? And that's just a script that creates a new tab in the Excel file with the updated information, so that Excel file's always current, and it has a historical memory. So in this segment, we needed to start taking the stacking diagram and actually create assets or outputs for presentation. So this script was kind of amazing. For me it's an amazing script, because it actually automates-- we actually used furniture families to create those boxes, and the reason why is we wanted to be able to just use a family that we could just kind of hide or eliminate or put on a workset and close that wasn't like a generic model.

But we need to go to rooms and walls and annexed and actual building objects in the next stage. So this initial script will take the block diagram, and it will develop-- well, let's see here. I'm getting ahead of myself. But basically, we're creating floors, walls, and rooms, from the stacks, from the initial furniture families. The only problem we had was we couldn't actually add the interior wall. It only creates the exterior envelope with the building, but it will place the rooms centered on each program block. So once you start populating your interior rooms, your rooms kind of snap into position. They're all there.

So just kind of give you an idea before and after. So on the top, you have the program stack, and you see the-- that's kind of a plan output showing the furniture families. Once we run the script, there are floor slabs and exterior walls that are automatically put in, and then rooms are actually automatically placed. But they're all overlapping, so once you just add the interior, and you can do that by tracing over that with an interior wall, all of the rooms kind of start snapping into place. And again, color codes tracked, we have tags developed so we can see what the area of each room is.

A lot of really simple things, but when you aggregate them and you're using them at speed, it helps out a lot. And then once again, after we do this we still needed-- because we're adding corridors now, we're still making adjustments-- once we get to the end of that phase, we want the data exported back to the Excel for tracking. And we're doing the same thing. We have instead of a furniture schedule, we now have a room schedule with the same conditional formatting so we can see where we're over or under. And then this script here will take it back to the Excel file and create another tab that shows you where you are at this point.

And then finally, developing final assets for presentation. So the exterior model is pulled in to the final drawings. Final views are created for rendering mock up and production, and there's another script which takes the resulting areas and creates a final block diagram as a generic model. In this case, we really wanted our exploded axonometric diagram to really track, literally track exactly the areas. So it uses the rooms to create the blocks and not the initial furniture families, because those are now obsolete. So this is some of the output.

You can see that the floors are color coded, and they're again set by the Excel file. So we use just the same file to drive the color coding here. We create these block diagrams through the script, and it's also color coded, and we can do exploded axons or whatever. We're also driving the exterior renderings. This was actually using the FBX export or FBX link, which we found actually to be really effective. So my rendering colleague, he's looking-- I mean, I'm setting the view up for him, I've also got the materials assigned-- and he's just using the FBX to apply maps and develop the rendering straight from my model.

We're not doing a third model or rendering model at all. And then getting this tabulated is pretty straightforward. You've got the information in Excel. You can format that now from your Excel data, and it's all correct. It's literally what you've tracked in your Revit model, because you've just exported to Excel. So just maintaining that tight data integrity throughout the process all the way to the final boards. And that's basically the solution. So just a couple of notes. Again, the collaboration process at White's really essential, and we welcome collaborators. If you're interested in these resources, we have the educational resources and the scripts available, and we're happy to share with anybody.

I can't give them to you today, but you can contact my colleague Matthias Erickson, and we're more than happy to share the scripts and the supporting documentation with anybody. So just get in touch. We'd love to work with you, it's just kind of how we work at White. And that's all from my end. Yep?

AUDIENCE: I was going to write down the email really quickly.

FOUAD KHALIL: Oh, sure. Yeah. Absolutely. Yeah. I think we'll provide the PowerPoint, right Paolo?

PAOLO GALLI: I think so.

FOUAD KHALIL: Yeah, you'll be able to download the PowerPoint if you need it from--

PAOLO GALLI: We'll put the PowerPoint on the web page at AU.

FOUAD KHALIL: I believe we can do that. And also it's being recorded, so you can come back and play it again if you need to.

PAOLO GALLI: No, no. It's not finished.

FOUAD KHALIL: We still have a few more, and then we'll take questions also.

PAOLO GALLI: No, it's not finished. I had only a small issue with the PowerPoint. I'm sorry, just 10 minutes, 10 minutes. Oh, here is. What's next? I want to share with you some ideas about conceptual design. We are in the 2017. We are working with very complex and powerful elements, software, whatever. But actually, we are still working with the GI GO approach, garbage in, garbage out. I mean, everything depends on the quality of what I do. I'm asking to the computer to do what I want, but I am not using the computer to suggest me or to help me finding a solution.

So I want to share with you some ideas related to some scenarios of the future. I am not saying these will be, I am not saying I think this is the right way, it's just brainstorming. But I think it's important being that we are architects and we want to add value. And we want to understand how the future is being that our buildings have a long lifecycle. I think it's important having this kind of discussion. Generative design. What do we have now at the moment?

You know Project Fractal. We can create with Dynamo Studio some definitions defining geometry. We can define what are the inputs and give this dynamic definition to project Fractals, which can create the combination of values of these inputs for creating a number of scenarios based on its definition. It's a sort of generative design helping me to evaluate different scenarios based on the same shape. What could be in the future?

Do you remember the paths? The wheels, the connection I showed you before? Imagine that we have something keeping requirements, existing conditions, sketches, ideas-- I give it the set of inputs to an engine, a motor that mixes them up and gives me some configuration, some path configuration, helps me to configure a suitable path for addressing these design issues according to a number of criteria. Imagine something like that. Or imagine this one.

Have you ever used Sketchbook? No, but you know there's an interesting web based application, Google Draw I think it's called, which tries to understand the meaning of your sketch. Now, imagine that we want to drive a geometry based on its requirements. When I say a line, I'm saying that it's the set of points connecting two end points. So given these requirements, I can have the computer interpreting, understanding this stroke to this line and the same saying four points connected, parallel sides, right angles. I can have the computer understanding this, do this.

So it's possible having the computer based on requirements understanding some shapes of my design intent or my drawing intent, in this case. Just imagine in the future something helping me to sketch and to recognize the room. I do a sketch. I'm not saying the computer is designing on my side, I'm saying I do a sketch. I want the computer to use its calculation power to perform some hypothesis on understanding what is my intent. Imagine a building. Is it possible? Is this the route?

I don't know. I'm not saying this is now. I'm just brainstorming. Imagine we have some requirements. The height of the levels, the maximum volume of my building, because this is urban planning data. And I do some sketches. The system recognizes the sketches, the flavor of the sketches, and puts the height of my sketch with the height given by the requirements and starts creating a set number of possible scenarios for plan distribution, for shapes, for energy and general behavior. Is this possible? Now, no it's not. But actually, this is generated design.

This is machine learning. This is a sort of AI, artificial intelligence, using the computer for suggesting, for helping me choosing from a number of scenarios and improving it then. You remember different lenses. I was inspired by the picture I put at the very beginning, and I took this-- this is the reason why I disconnected my computer, because I needed to move this slide up. Imagine we have a special zoom. The zoom of every software we have allows us to move it this way. I mean, to make bigger or smaller on the screen a geometry.