Description
Key Learnings
- Learn how to overcome the difficulties of delivering construction drawings for buildings with complex geometric forms
- Learn how to integrate Rhinoceros 3D and Revit using Grasshopper and Dynamo
- Learn how to coordinate and deliver designs digitally using cloud-based collaboration and virtual reality
- Understand the challenges and workflows for architects delivering 3D models for fabrication
Speaker
- Brendan MullinsBrendan Mullins is an architect and visualization expert with Stantec Architecture. He has integrated virtual reality into the design process of prestigious projects such as the Lucas Museum of Narrative Art, the San Ysidro Land Port of Entry, and the UCSF Precision Cancer Medical Center. His knowledge of design, construction, advanced visualization, and the user process has allowed him to integrate advanced real-time visualization techniques into fast moving project schedules in order to realize better designs and user satisfaction. Brendan is currently living in Los Angeles and working as an architect on the Lucas Museum of Narrative Art.
BRENDAN MULLINS: All right, everybody. Thank you for coming today. I'm going to be presenting some of the innovative workflows we've done on the Lucas Museum of Narrative Art in Los Angeles. I hope you're all feeling all right this morning after the party last night.
My name is Brendan Mullins. I'm an architect working out of Stantec's Los Angeles office. Originally, I worked out of the San Francisco office. I'm a licensed architect in California. My day to day, these days, is construction administration on the project. But I also acted has bin manager on this job, and I help roll out virtual reality across the firm.
Some of my past project experiences at Stantec include the Cleveland Clinic Cancer Building and the San Ysidro Land Port of Entry. Both of these projects were influential on some of the thought processes we had on this project. The Cleveland Clinic was one of the earlier jobs that we were loading fabrication models into our Revit project during CA for some middle review.
And it was influential on the Lucas Museum now. And on San Ysidro Land Port of Entry, we were doing similar things. Both of these jobs, we were also integrating virtual reality into the user process, which has changed a lot of the ways we work at Stantec and it's something we are also doing on the Lucas Museum.
Some of our learning objectives today-- coordinate and deliver on cloud based collaboration, virtual reality. We're going to be talking a lot about the lack of paper on this job and the way we treat models. Integrating Rhino 3D and Revit. As you're going to see, this building does not have many straight lines and the model's really everything to us. And Revit can't do everything. We have to rely on other softwares, like Rhino.
Overcoming the difficulties of delivering construction drawings-- putting this thing on paper was a challenge just to think about, let alone actually get it done. So we've really had to rethink what a construction set looks like. And understanding the challenges for going to fabrication-- we're in construction administration now. We're pouring concrete. I think we're just at the tip of the iceberg here about really what we're expecting to see in construction. But the relationship of our models to fabrication has been tighter than I've ever seen on any job.
So let's introduce the project. This project has had a long history among different cities. I originally got involved during the pursuit in San Francisco. We won the job to put it on Treasure Island. One thing led to another. The job did not end up being in San Francisco. So I had to leave my hometown. And I moved to Los Angeles to continue working on it. Many Stantec employees from past pursuits came to Los Angeles. And we came together to get the project done.
This is the Lucas Museum of Narrative Art, is funded privately by George Lucas. It's going to house an extensive collection of art. It's designed by Ma Yansong in Beijing from MAD Architects. As you can see, it's a very innovative design. It's very provocative. And it should end up being very beautiful. The site is located next to USC campus in Los Angeles. You can see the USC Colosseum there, where the Trojans play. I like this shot because it gives you a sense of scale of just how massive this project is in relationship to its surroundings.
The site actually takes up this entire park. Underneath there is extensive parking. This was originally surface parking, that's all moved underground, and now the museum sits on top, giving a lot of green space back to the public. You can see the street that's running from the bottom right up to the top left, actually passes underneath the building. So this building's actually forming a bridge over the street, that the public will be able to walk under it, and really get a good feel for it.
The organic architecture integrates very well with the green scape around it. As you can see, the transition lines are blended. And I think that's one of the more important design aspects of this project. It's about a four block long park given back to the city. And the question about what is narrative art, George Lucas has an extensive art collection that's going to go into this museum.
I think you can expect to see everything from classical pieces to Norman Rockwell. And it's all about storytelling. I think we can expect to see everything from classics up to the newer stuff, of course storyboarding, telling stories through movies. The museum also has an extensive entertainment aspect with feeders. There's an education component too, for the underserved children that live in that area around USC.
And I'm going to start now with a few buzzwords that, of course, we hear all the time at AU and in our profession lives. Collaboration and visualization-- sometimes I think these words get beaten over the head, but they really were important to this job. Silos on projects are always one of the more negative aspects.
Really working as a team on this job, both amongst our engineers and designers, and now going into construction, has been fundamental to keeping up with this deadline. Just because this building is more complex doesn't necessarily mean we get any more time to get it done. So we've really had to make sure we're working fluidly and cooperating amongst trades and design partners.
And then visualization-- I'm going to say this many times, but looking at a floor plan of this building, you just can't get it. And our architectural set is over 400 pages. To understand it on paper just simply takes too long. So seeing this thing and visualizing it is everything. On a day to day basis, we look at our docs to mark them up, and of course, because we have to deliver them. But really our day to day is looking at a model, looking at things in perspective. Our whole day is in perspective.
Some of the tools that we've used on this job-- so I've broken into a few categories. We have collaboration, it's in A 360 job in the cloud, Bluebeam Studio. We live and die by Bluebeam on a daily basis, always. Autodesk Glue, we're going to be talking about a lot, essentially, as a lightweight Navisworks, if any of you have used it. It's really great for taking this massive model and taking it down to a place that we can look at it fluidly.
Modeling-- it's C4R project. Rhino 3D is where we really worked with those models that we're going to be passing on for construction, for fabrication, where you can get a high level of accuracy for the organic forms. And then Maya is really the birthplace that's coming from that, and where these things are born, they're born in Maya. Computation-- Dynamo, Grasshopper, Excel. Visualization-- we're using an Enscape and Insight VR for real time visualization and collaboration of VR.
The thing I want to push about this slide is probably everyone in this room knows every one of these softwares. There's nothing really unique up here. And I'm going to be talking a bit about it, but throughout this project, you'll see that even though we're doing something extremely complex and innovative, we don't necessarily need to buy new software to do it. So, all of this stuff can be done with the tools we have. And I think it's really just about how you repurpose them.
So you can imagine that all those tools are the stone in this picture. Just the way we wield them is the 3D printed handles. So how do we take what we have and ignore its limitations, and then build upon it, and get something new, and push these workflows. So technological innovation from within. What our principal, Mike Siegel, likes to say-- they're tools built by practitioners for practitioners.
There was never a time on this job when we could just say we can't do this. Because we would have said it every day. So it was always about, OK-- here's what we have, how can we blend these two tools together? Or how can we make them work faster? How can we automate processes that we don't usually automate? How can we stay on track with very tight deadlines and get this complex thing out the door?
So this model is massive. It's 28 C4R models. Many of them are over a gigabyte. I think it's one of the largest models you probably see in C4R. And Revit, though surprisingly, is behaving very well with this amount of data, it's not fluid enough to really collaborate.
And so on previous projects, I've kind of felt that leadership maybe won't see the model and won't interact with the model unless they're sitting down with drafting staff to convey a design, or they're requesting to see it. What we've tried to do on this job, because the model really is the only way to get it, is to democratize BIM. And a lot of that has been based around the cloud and around Glue.
This job's a little different, where senior leadership, senior designers, PMs, they look at the model every day in Glue. And that allows them to spin around and get the design. We're automatically pushing our Revit model to Glue daily.
So there's this lightweight form of the model that anyone can see from any machine any day of the week, and it's very easy to use. All you really need to do, especially is a senior designer, you need to draw over the model, and you need to able to cut sections, and you need will do this very quickly and fluidly.
So keeping this thing in the cloud, in a lightweight format, allows younger staff and immediate staff to stay in Revit where they are. But if they will need to go to markups, or senior leadership needs to interact with it, we have this lightweight version at any given moment that can be pulled up on iPads or smaller machines. And just to go further, like I said, there would just have been no way to do this without 3D.
So 3D PDFs were a thing that seemed to have come and gone. You've probably heard of them. They don't really get used that much, at least I don't see them around. But we've started using-- again on this job particularly-- so that we can easily mark these things up and pass markups back and forth easily. So in this case, something as seemingly simple as what are the extents of the roof just can't be explained very simply anymore when the shape of the roof is like this.
So in the bottom right, we use a 3D PDF with each of those blue dots being a markup. Every time you click on it, you're spinning towards a blue beam markup up top. And so that way we can put a lot of data in a very lightweight PDF and pass it around.
And this really drives home the paperless project. At the request of the client, this project does not have a printing budget. And we only essentially print anything to go to permit. Otherwise, at least on the design side, we don't print anything.
So we have Wacom tablets around the office, touch screens, drawing tablets, and everything is done collaboratively over the model in the cloud, paperless. But you can't always ignore the pen and paper. So those Wacoms become very important. Using Glue or Navisworks in a lightweight format, we can very quickly spin this model and then immediately start drawing on it. And keeping the process fluid, it's all just a been about lowering barriers.
And it's always surprised me that architects, designers, walk around with touch screens in their pocket, yet we don't really see touch-- I don't usually see touchscreens used as much in the industry as I would have thought they would be, considering the power they have.
So this job has forced us to think different ways, just because there was no other way to do it. But now having gone to this place, I really could never do it another way. And this is just one example where I can't imagine doing another job without drawing on the model all the time. And luckily, this job just forced me to think that way.
And like I said, this set's huge. And even as you saw in some of the 3D model shots, it helps you get the building, but the building's so complicated that even the model is confusing. You cut that section through that thing and it can be overwhelming. So how do we convey ideas to the client and the owner in a way that's seamless? And for us, really the only way was virtual reality and real time rendering.
We've used virtual reality with nurses. I've used it with border patrol, on the San Ysidro job. We've used it for a lot of purposes. This way was pretty much just to convey ideas. And the amazing thing, especially with this, Google Cardboard, is it's so lightweight. In this case, we did 363 movies that we could put on private YouTube channels.
We could hand a viewer that's $20, branded to the client, then go on a YouTube link, and essentially take a narrated tour through the project. It's rendered right out of our construction model. There's really no work done since we've model to such high levels of accuracy. And we render it out, put it on Google Cardboard. Now the client can see that design just from their cell phone and just pull it right out of their pocket.
But then, you can't ignore the other powerful virtual reality tools we have as well. So when we were asked to put the client into the project, or show the board of directors what this design looked like, we knew we had to do something special, considering the client. And we wanted to really keep pushing the buck for what VR should be and can be.
So, in this case, we had six VR machines with six Oculus Rifts. And in this case, using Inside VR, I could sit on the end. I'd be in VR. And I'm the tour guide. And then we can put five board members in these VR headsets. And I can take them on a tour, just narrated verbally, but it could be through the microphone of the Oculus, and take the client through the project.
VR has so many sociological factors in it. I've learned over time, learning how to deal with clients in VR, controlling them, keeping the story on track, is a lot more difficult than you may think. Many of you have probably experienced it.
So tools like this have a button where I can pull everyone back to me with the click of a button. Things like that are very important. I've got to keep this story on track. I have somebody going Superman style over the Colosseum, I got to take it back to me.
So being able to control the client and tell the story, whether it's through that rendered Google Cardboard way or through this, where I have some control of the participants, was very important for keeping things on track when you could go anywhere in a million square foot building. I can also mark things up, highlight things, point at things.
So we'll talk a little bit now about design and delivery and how we bended these tools to make them do what we needed. So it seems that every task that would have seemed standard just was no longer standard when the building was shaped this way. It's like we got to do roof drainage. It's always such a standard design activity on a project. But when your roof is shaped like that on the bottom right, and planned, all of a sudden, roof slopes are the most complicated assignment you could imagine. So how do we do that?
This project was really about mindset for delivery. It was like, we almost did a digital audit, we used to call it. We would get an assignment like this, intermediate junior staff would sit down, the Grasshopper guys, architects, and [INAUDIBLE] architects, sometimes senior leadership.
We'd sit down and we go-- first of all, are we going to have to do this again? And if the answer is yes, then we have to think how long is it going to take. If those numbers started adding up to big numbers, we just said, let's put the manpower in now and let's automate this design process. Let's not even make the mistake of attempting it once manually.
It was about sitting down and considering how we're going to deliver things, thinking about the future, thinking about deadlines, that we could keep on track. So in this case, this roof's going to keep changing, the design's going to keep getting fussed through DD. Let's just teach the computer the code. In this case, let's teach the computer what the California building code tells us about roof drainage.
So every time that shape changes, this Grasshopper script in this case will automatically adjust all of the slopes to the drains that we've specified and give us something that's code compliant. And then we can import this over to Revit. And check the slopes, tag it, everything would end up perfect. So teaching the computer to do tasks like this was extremely important for rapid analysis, rapid design, stay on track.
We could also use our computation tools for analysis. Thinking about the future, OK, we have hundreds of panels, not two of them are the same. And which ones won't fit on a flatbed truck and which ones will? We know that we're going to have to do this assignment many times as well. This design's going to keep changing.
So how do we teach a computer to alert us if we're going over? So we teach the computer once to do the measurements for us. We can put in some rules. And then we can understand, is this thing constructable at this early phase? Are these things going to fit on a truck?
And every time we need to do this analysis now, we put in a day of work on the front end, this assignment now is the click of a button down the line. And it just keeps us on track with our deadlines. Like I said, we are moving just as fast as any job. So we had to make sure that we saved time where we could. Areas like this take a little work on the front end, but they always pay off in the long run.
And now, how do you draw it? I mean, it's a pretty wild shape. Early on, we understood that we were going to have to rethink how this thing gets delivered. Especially we started getting into design development, we said we can't just give floor plans in sections. It's just not going to work that way anymore. So here's an example of the lobby. As you can see, very few straight lines, very complex interactions between glass elevator shafts, complex curved ceilings, curved wood walls. How do we get this thing on paper? And what are the models going to do for us?
We started understanding early that no longer were the models just an additional resource to be delivered to the contractor and to the builders. The concept of delivering models to build from, I think scares architects frequently, something we're always allergic to. And we started understanding early that there's just not going to be another way to pass along this information. But you can see, we've gotten close to putting it on paper, I believe.
So where does it start? It starts with Mad Architects in Maya. As some of you may know, Maya's really an animation tool for organic geometry, rigging animation and characters. It's not typically used in architecture and design. And this was where it was starting. Maya doesn't play well Revit. It's not going to play well in fabrication. It doesn't have the accuracy levels we need.
So they would hand us this. In this case, you can see conflicts with these massive structural members. These coming from Lira, our structural design engineer. And we could then pass Revit back, and they could push and pull. They could get a form that we thought could fit, had the tolerances, constructability.
And they passed Maya back to us. When we got the Maya models, we then take them to Rhino for final finessing. We then got to make sure these models match up with our details. We got to make sure they're smooth enough to be acceptable to the fabricators. And then we got to add some specificity to them.
So in this case, we've taken a chunk of that lobby and we need to start naming things. So this project is definitely unique, in that we had a computational design consultant hired to the project. And most teams, of course, aren't going to have that luxury. Proving Ground, a great firm, was integral in getting us early understanding of how we're going to rapidly bring Rhino into Revit, how we're really going to interact with Rhino. But our team over time evolved. We learned a lot.
You see this script. You have Proving Ground in the pink up there. It's very similar to their conveyor tool that you guys can look up, that'll bring Rhino to Revit. And then on the back end, we've done a lot in order to take this Rhino service, label all the panels. We then label the corner points and every edge point, 5 foot on center. Now we can start to understand this thing. We can we know where the XYZ points are, we know the panel names. There's some specificity added to this.
Now, we got to figure out how do we make Rhino and Revit work together. Easier said than done. There was another thing where we kind of had to have a digital audit. And we had to sit down and say there's a lot of ways we could put this thing on paper. We can simply put screenshots. Some people voting, hey, let's just put screenshots over from Rhino. It's easy enough to export. Grasshopper could be spitting out documentation for us if we taught it to. But Revit has a soft spot in my heart. I knew that was not the right way to do it.
We had to let Revit do what Revit is good at. So we then built a Dynamo script. So essentially, we get the Grasshopper script built. In one click, it's going to spit all those panels out and all those numbers. Dynamo, with a click, is then going to bring it over for us into Revit. But to take it a step further, we had Dynamo build shared parameters and make them into all of the panels that were coming in, so that we could actually make true Revit elements that could be scheduled and tagged.
That way, when we cartoon a sheet like this, and we say, OK, we've labeled these panels, we've broken down how the points interact on them, we show their measurements, again we're going to have to import these things dozens and dozens of times, particularly in DB, where I'm programming these things like every other week as we coordinate. Steel members change, things change.
So the advantage of doing this was we could tag everything, we could cartoon this sheet. Every time we just import this, all these tags update, all the schedules update. We've reduced the amount of clicks, the amount of time for importing and setting up sheets, that once we do all this leg work on the front end, things are automatic moving forward, or close to automatic, a few clicks in each software. And this could save hundreds of hours in the long run. It was all about thinking ahead, anticipating the amount of changes we knew were going to come, and making sure that we could spit documents out at any given time quickly.
We then have to relate this information to some level of constructability. And what is the relationship between a detail and a model? One more thing we have to start thinking about. Now, we've decided we're going to hand over 3D models. They're becoming record documentation. And now how are we going to make a detail relate to something that is just on a USB drive, just sitting on A 360? How do details relate?
So this is a pretty basic example where the details begin calling out Geometry Work Point refer to 3D Database, the 3D Database being a library of models. And on the sheets prior, we could explain what is that target relating to on this particular piece. In this case, it's relating to the center line of a reveal. So we had to think of how we can start relating the models and the details, which was just another way in which we had to rethink this thing.
Like I said, you can almost go overboard with the amount of data you can become scheduling. You figure out how to do this, so you say, oh, well, now I can schedule everything. In this case, all those Rhino points, those XYZ points, we're able to get in Revit and schedule them, and have them update every time we import. We did this early on, particularly because we said-- we hadn't really worked out the execution plan. At this point, we didn't actually know if we were going to hand 3D models over and say, this is a record document, this is a contract document.
And so we decided, well, if we had to put a model on paper, what would a model on paper even look like? So we decided to do this early on. Whether or not this gets used during fabrication, we don't know. It could surely be used on the site for checking accuracy or checking our design. But it was like once we put in the front end, it was amazing what the possibilities were. And we could pull any of the data we want once we had done the work. So this is really a representation of what does a model on paper look like.
And like I said, everything is paperless. So no longer are we giving PDF-- I mean, giving paper documents. Our paper documents are incomplete. If you just print a set, you can't really just build from the set, because now 3D models are integrated into it.
So really, the record deliverable becomes entirely digital to the contractor. Like I said, of course, for permitting was the one exception to this, where we have to get a permit. We have to stamp docs and take them to the city. But apart from that, every time we delivered anything, we delivered the models and the documents side by side. And now, together, they are the record contract, which was much different from previous jobs many of us had worked on.
And now we are in construction. They broke ground last year, I believe it was. We're pouring foundations. We're putting the first decks up in the parking garage. So it's well underway. And now, the question is we've done all this cool stuff in design, how can we think about what we can do in construction? The same guys that are putting those Rhino scripts, Grasshopper scripts, doing all that innovative stuff, now we're answering some middles and doing CA all day.
So we still have this mindset of, OK, what can we do with this. And we're still of figuring out how we can push the buck forward and make sure this thing works. And surely, the contractors are very much pushing it forward, the contractor being Hathaway Dinwiddie. So preparing for construction-- one thing I've been playing with recently that I tend to really like are 360 cameras. And I think they have a lot of-- for our field reports, we've been using these extensively.
So when we walk the site, we can record a 360 movie of the walk, instead of just shooting DSLR shots. And this has kind of dual purpose. First of all, it's honestly easier to put in a field report. You can simply point to a part of the video. And then down the line, we've now archived site walks. I mean, surely CA is going to be extremely complex on this job. There's going to be problems. We're going to have to fix them.
So the more record we have of what happened or what's behind that wall, all the better, so we can fix problems in the future. So these 360 movies allow us to not only look at maybe the problem or the issue we're trying to solve, but you can look at all the context around it. And then anytime in the future, should you want to, you can go in virtual reality and be on that site walk. Multiple people could watch this video at the same time and say that's what we saw that day, think back to that time.
This is such a low budget thing that anybody can implement right now. These GoPro cameras are less than a grand, with all the accessories, decked out, everything you would possibly need. So again, a tool that all of us have access to already. And it's just about a mindset of how we start rethinking things. There's a field report-- is that just how it's supposed to be done, or is there some other way to do this.
And then just the complexities of the shapes of this building. I think the owner, and the contractor, everybody knew that we're going to have to record construction in different ways now. So in this case, we're going to have this tank driving around the site every Friday night. And we're going to have laser scan models of the as built weekly. And some people could be terrified of that concept. Some people to be excited. Ultimately, I'm very excited about this.
I think integrating laser scans and Revit is not necessarily a perfect process yet. But I think it's going to be extremely valuable. And when you looked at all those Rhino models we had, back earlier in this presentation, and you can think there's a conflict, there's something placed in the wrong spot and we just can't move it for scheduling purposes, that being able to have an as built that's always accessible to us, comparing that in a Rhino, maybe changing that Rhino surface to now match an as built, is going to be, I think fundamental.
We haven't seen those problems yet, but it's that same thing, like digital audits, like let's look to the future. Let's anticipate these problems that we could have and let's be ready to solve them. So even before that comes, we're working on how can we make these laser scans interact with our Rhino or our Revit properly so we can adjust things in CA, just seeing that stuff coming down the line. And we're blessed to have access to this baked into the job already.
And before I go into questions, again I just wanted to reiterate that all those softwares you saw, that's all stuff you have access to now. And if I've learned anything on this job, it's really innovation and pushing delivery forward. It's just a mindset. A lot of it is just sociology. And I personally can never work on another job differently now. It would always it would always be like. Every job I go forward, I'm going to be drawing on tablets. I'm going to be integrating Grasshopper and Dynamo into anything I can find.
And so the question is, how can you take these complex problems and lessons you've learned and move them over to things more practical? And I think that's really the thing I want people to take away from this. In my hand out, it's really my write up of that idea. Then recently, I just started thinking, what are the things we do on normal jobs that take so much time away, things we repeat all the time, which is tons of stuff.
And even on Lucas, the things we didn't automate that in hindsight, man-- like I always think of those stair course. Something I just been jamming on this week, where I'm going-- we take so much time of a junior staff member to rebuild cores all the time. Think about some of the machine learning we've seen at these keynotes talks, metal bending and changing to fit a given set of rules.
Who's to say that a stair core can be the click of a button? To me, it seems possible. And it's something that we can start exploring. Life safety on this job-- permitting this thing was a beast say the least. But the amount of time we just spent doing calculations, life safety calcs, all this stuff that, in hindsight, if we just put the labor in ahead of time, we could have automated mostly all that stuff and gotten it to spit out permit answers, permit charge, life safety analysis.
And those are the kind of things where, let's take a lesson that we've learned from designing this crazy roof drainage surface, let's try to pull it back and say, how can we roll this out to a job that maybe has all straight lines? Doesn't need this level of innovation on a computational level, but how can we still integrate it into the project? So that's a lot about what I hope to see moving forward. And I'd very much like to take questions now, any conversation questions you guys may have.
AUDIENCE: Aside from your [INAUDIBLE] model that you're working with, what kind of hardware [INAUDIBLE]? Were you bringing stuff already? Or did you experience [INAUDIBLE]?
BRENDAN MULLINS: Sure, so the question was about hardware and how did we handle these models with the hardware we were given. Stantec, truthfully, the machines, the CAD machines we were given were pretty awesome to begin with. But there is no doubt we pushed the buck on what these things were capable of. 64 gigs of RAM on my CAD machine was maxing out regularly in CDs and DDs.
So just one level, where 64 gigs is usually the most you would need on a job, all of a sudden, I have 59 gigs used and my machine's slowing down. So right there off the bat, the amount of RAM that needs to be cached in order to open models of this size.
But I will say that I've been very pleasantly surprised at A 360. The Revit server days when you had to raise your hand to ask to sync your model back in, it's now like we were syncing everybody at the same time of the biggest model we could possibly generate. And it was going fine. So I think the cloud has alleviated a lot of those problems, just because the amount of horsepower behind the cloud.
This project was also unique with virtual reality. I didn't go into it that much here, but I sit next to someone at Lira, structural engineers, and they're having meetings in VR from New York to LA regularly. And on our team too, we have Oculus Rifts on the desks of mostly all the junior and the immediate staff. Most projects won't have that, but it's also a difference then on hardware.
So in that case, we've taken all the CAD cards out. Now everybody's running some video game GTX machine on their CAD machines, which I seem to hear conflicting things about whether CAD can run on video game cards, but we run this model exclusively on video game cards. And it behaves like a champ.
And then, with that, one click button, we're all in VR and a multiplayer space. And with the multiplayer, we can be in there within 20 minutes or less. If you just want to get in there and be in VR, and your design, your Revit model, with Enscape or something, we're talking about this model going into VR in less than two minutes.
So we click a button, we put our headsets on. You change a design option in Revit, it's changing in your headset, just all fluid. So a lot of RAM and video game cards will get the job done for us. Yeah--
AUDIENCE: [INAUDIBLE]
BRENDAN MULLINS: Yeah.
AUDIENCE: How did that allow for the design [INAUDIBLE]?
BRENDAN MULLINS: Sure. So the question was if we're building in these Grasshopper scripts, and the computer is controlling the roof drainage, how do the designers come back and change it? I don't know if anybody was at the keynote speech for manufacturing yesterday, but I thought it was very interesting, the way they would have the computer generate all of these amazing structural systems, that looked like a spider web. But then the designer would come in after the fact, make them a little larger than they might need to be, because it looks better.
And they might pay a little bit more, it might weight a little bit more, but it looks better. I think it's kind of the similar thing, where we get the computer to spit out the rules, code compliant drainage, but that's not to say we can't come back and tweak it. I mean, the advantage of a lot of what we did was-- the import process, to Revit, meant that things were Revit elements. Like we could tag slopes in Revit. And you can also look at slopes in Rhino.
So we could have it spit something out for us, all the tags update instantly. And then we could, if we want to tweak something, we can make those tweaks and see all that analysis change in real time. We could put a heat map over it to make sure everything's 2% or more. We could set rules to make visual analysis, so that if we want to change things, we can see that change in real time too.
Computation is, I think some people would say maybe it can replace designers and architects. I'm not really sure that's ever going to be the case. Maybe, but I think it's really just about how you wield it. And making sure that you don't let it replace your creativity, but it can definitely empower you. Question, yeah--
AUDIENCE: [INAUDIBLE]
BRENDAN MULLINS: Yeah, so I think the question is really about can this stuff be reused. Yeah, we've thought a lot about that, where we have teams asking our team, other teams at Stantec, going like, can we use these scripts for anything, what can we do. I think part of it is the organization of the scripts.
The same way a large company spends millions of dollars on like Revit family databases, I could see that one day you would do the same with scripts, especially Dynamo scripts. And that's why, what I've been saying, I'm kind of excited about the less exciting things, like stairs, and life safety. Because I just feel like it's a low hanging fruit to save a lot of money and time.
And I don't know how many projects are going out to figure out which one of their 900 unique panels doesn't fit on a flatbed truck. It's kind of a unique issue that we have to solve. So I don't know if we're going to get to reuse any of this stuff. The roof drainage one, we made. Because I actually think that roof drainage is another low hanging fruit. Every job has to do it. It's burning time that could be spent on other things and we can just simply automate it.
So when this is all said and done, I would hope that we do clean up some of those scripts. And I know I will roll them out to another job. Whether or not we can pass them just over a fence and they can run with it, I don't know. But I would hope that one day we do have those kind of libraries for this stuff. Another question, yeah--
AUDIENCE: The computational consultants, who paid for that? And a follow-up question, do you find that there are a lot of people trained because of that consultant?
BRENDAN MULLINS: That a lot of our team got trained? Yeah, so the question was, I guess, what was the contractual relationship of the consultant? And then what was its implication for the team's knowledge? The consultant, Proving Ground, came on before my time, which was when the job was in Chicago. Back then, I don't think C4R was as good as it is now. And I think the team didn't maybe have the knowledge base to figure out how to optimize this kind of stuff coming into Revit.
So that model, from what I've heard, was like the devil. And it was crashing all the time. It was extremely slow. They were importing stuff straight from Rhino. Or they were using pick faces, and like pick facing this massive Rhino model. And it just wasn't working for anybody. And they were having huge meltdowns during deadline time, models not even opening. It was just unwieldy. So they brought Proving Ground in because of the headaches they were having.
And Proving Ground already has a lot of these tools. I think bringing them on, they could do BIM [INAUDIBLE]. They could do the normal stuff that helps us keep moving quickly . But also, the advantage was just that we can take the tools that they have and tweak them for this very unique purpose. They were helping us. It was doing-- it was like decimating the surfaces and making them lightweight, and then doing the pick face, and doing all that for us automated.
And so it was really nice for them to give us this building block that we could then figure out the fabrication needs and build all those other tools on top of it. And like I said, they did teach us a lot over time. Originally, it was like let's all just install Proving Ground. And we clicked the button, and look, they've solved part of our issues. But over time, we had learned so much and our computation designers had started figuring out their script and how it was working.
We started ripping-- taking-- peeling back some of the layers of what they had done, and then building things on top of it. And that was that massive script, where Proving Ground's up in the top right, just that one tool we got from them. And then we've totally tweaked it out. So I think we were very lucky to have them on board to answer some of those questions.
AUDIENCE: Could you do another project like this [INAUDIBLE]?
BRENDAN MULLINS: I don't know about that one. I mean, I have to think about that one. Proving Ground was no doubt instrumental in helping us. It's like I said, maybe if I had all the exact same team that we had on this job, I think we could go do it.
But if you were to take half the team out, or three quarters of the team, and go try to do a job, and put new staff on it, it really helped to have that. But I'm not sure that the next job's going to have budget for a computational design consultant. It's kind of a unique consultant.
We ended up hiring them, for the contractual part of the questions. They were working directly with us. There were folks like Lira, the structural designer, they were so advanced they didn't need a computational design consultant. They had like an entire in-house-- they have essentially that equivalent just in-house already. Stantec just didn't have the infrastructure to have an entire computational department come in and back us up yet. But that's coming for sure at Stantec. Yeah--
AUDIENCE: [INAUDIBLE]
BRENDAN MULLINS: Sorry, I couldn't hear. Could you repeat that, please?
AUDIENCE: [INAUDIBLE] how they have to rise to the challenge in fabrication and construction.
BRENDAN MULLINS: Yeah, so the question is, what challenges do we think we're going to have in construction, and how are the builders going to have to meet that challenge? I mean, honestly, everyone on this job is very sophisticated. You're not going to win this project unless you're a very advanced contractor, subcontractor.
The amount of modeling we expect from everybody is at a very high level of degree. You essentially can't even deliver this job at any level, unless you have a pretty amazing modeling department, amazing understanding of computation.
So the people on this job, all of them, are advanced to begin with. So we have a lot of trust in all the people around us. We're learning all the time from folks. Like I said, with folks like Lira, early in design we were constantly going back and forth learning things from them. They're learning stuff from us. Instead of having a weekly coordination meeting, we might just have a weekly meeting on how do we get this thing on paper, or how do we make a script for this and call our consultants for help. We have to have that kind of relationship.
So we're all learning from each other. I think a lot of this project really has been mentality. And so, I think with the right mentality, it doesn't matter what the challenge is that comes. I think we're going to be able to adopt to it. As long as we have the right relationships and everybody understands that whatever the solution is, it's not going to be a normal solution.
If you go in with that correct mentality, I think we can just pretty much solve anything. And having these powerful tools, and as built every Friday, things like that, I think are going to make those problems easier to solve. But, yeah, I think with the right consultants, everybody's pretty advanced. I think we're ready for the challenge. Another question, yeah--
AUDIENCE: The size [INAUDIBLE]. Did you have any problems with publishing schedule and having to [INAUDIBLE] synchronizing and publishing to the cloud?
BRENDAN MULLINS: Yeah, so the question is do we have problems publishing and transmitting these models? I didn't even go into some of the other things we've automated, but we spent a lot of time getting rid of menial tasks like that. Like, printing this architectural set takes like two days or something, just to PDF the thing out of Revit, because of how much geometry is in it.
The model behaves surprisingly well. But just to print the thing takes forever. To publish it to Glue, where somebody keeps clicking like update link over and over, just burned like three hours of this person's time updating link, or the print set freezing Revit for two days on some machine. So those were other things that are less glorious that weren't presented that we also ended up automating.
So like the Glue process started being so instrumental to how we coordinated the model. We're doing it-- we start doing it once a week. And we're doing it two times a week. Then all of a sudden, somebody's got to Glue this thing every day of the week, multiple times a day. We didn't have time for that. So we ended up either buying an add-in or finding something that would automate that process.
So now we just click a button and some cloud server somewhere out in the ethos just Glues all of our stuff for us, very quickly, like on Amazon Cloud Service, very quick stuff. Same thing with publishing, we could automate publishing. It's like I said, I've continued to be surprised at C4R handling this. These models, like 26, 28 models, many of them over a gig, two gigs. I think at one point the facade was this four gigabyte gargantuan Revit model. The clouds were able to handle it.
We had some corruption problems once that probably wasn't even the fault of the model. It was probably some Revit thing. But everything, the cloud's been able to handle it. And hindsight's always 2020. I think we could apply broken models down even more.
Now I might have had 35 models, just so we had more lightweight models to work with. But yeah, we actually handled it well. But we were using the power of the cloud to do some of this heavy lifting for us on a regular basis.
AUDIENCE: [INAUDIBLE]
BRENDAN MULLINS: Yeah.
AUDIENCE: Did you ever think about [INAUDIBLE], and the fact that this was the traditional 2D [INAUDIBLE]? How did that impact your deliverable schedule?
BRENDAN MULLINS: Well, deadlines-- we're not allowed to change. So we're given a set of deadlines that we have to meet. We start with that rule. I think, it's like I said, a lot of this was mentality. It's like as long as we were given an assignment or encountered an issue during documentation, and realized we were going to have to do a bunch of times, and putting in that work then, instead of ever even manually attempting it. We started getting in a mentality where we'd get this complex issue.
We wouldn't even try to muscle it through once. We would just say let's just automate this thing from the get-go. Let's not waste any time exploring what it would take to muscle it out in a modeling sense. Let's just teach the computer to do it off the bat. And yeah, once you get these things automated, it saves so much time. It'd be nice to benchmark, to compare things.
I always think about VR too, like I wish I could-- I wish I had more time to benchmark the length of a user process with a medical team with VR and without VR. The same thing kind of goes for that. I wish I had the research and the horsepower behind me to benchmark how much time did we save. But we're pretty confident that it only helped us meet deadlines. Does that answer your question?
AUDIENCE: But you need to push it back at first deliverable date [INAUDIBLE].
BRENDAN MULLINS: No, our team's been really good about meeting deadlines. We've been able to put things out on time. One of the advantages the team had was this job was supposed to be in Chicago at one point. Some lessons were learned the hard way for some team members, I think, even before my time on the job. Where I don't think they were missing deadlines, but they were encountering huge obstacles.
So the team had already been kind of primed to see those kind of issues come down the line. But I'd say every time, automating things kept us on track instead of ever hurting us. Of course, you need proficient people to do this stuff. I mean, we had some really sharp shooters, especially some of these young guys coming out of school. I remember doing computational design in school.
And you go into a job like a cancer building, and I'm like I don't know where I'm going to put Grasshopper on this cancer building, I just don't see it yet. But the one thing I hope people can take away is that I think you can see it, it's just a mentality thing. Where you say, well, of course, I can push this job out, it's all straight lines, just the normal way. But as long as you do it from the get-go, I think it'll save you time. It's just doing it early. Yeah.
AUDIENCE: [INAUDIBLE]
BRENDAN MULLINS: Yeah, one of my roles, and especially recently, has been getting this thing permitted. It's been very difficult. I mean, the amount of code we've learned, we've all become a lot more proficient at code from his job than any other job. Because everything is blurring the line. Especially when the facade-- no straight angles on the facade, that alone-- and an egressing under a bridge. All these things are just unique challenges that you rarely see on jobs.
We've had a really close relationship with Los Angeles. They've been fundamental in helping us. Having a relationship with those plan checkers, them helping us understand where we need to go and what codes take precedent. LA is a tricky place to get a permit to begin with.
And it was a lot of work. I mean, I have to say, one of the biggest challenges, probably, was permitting, to get this thing code compliant. We spent a lot of hours doing it. We had to stay very organized. A lot of Google Docs, a lot of very long lists, laundry lists of things that need changed.
And no doubt, it affects design at times. And that's why those setbacks-- all the time you save with that automation then is for the important things. Permitting is an important thing that we got to save time for. It took a lot of time. So saving the time for that, so we can put all our muscle into getting it code compliant, so we can meet permit deadlines was crucial. I can say that it wasn't easy. Yeah.
AUDIENCE: [INAUDIBLE]
BRENDAN MULLINS: The question is I think you're looking for a little more detail on the process of getting through permit and how it worked with the city. I don't want to go too far into the details, but Burnham is a code expediter. So we had a code expediter to help us. That code expediter is going to be all the way through CA. This isn't just a design bid build, of course. We have a lot of design assists and design build contractors.
So even with a full building permit, there's a lot coming down the line with LA. So we have Burnham. And we have very close-- we work with LA. We sit with plan checkers all the time, honestly. We work with them a lot to help them. Because it's in everybody's best interest. LA wants a safe building. And they want an iconic building that works and functions. And we want the same thing. So everybody's under the same understanding.
But yeah, permitting took a lot of man hours, a lot of time with the city. A lot of time with our code expediters. Yeah, hopefully that helps.
AUDIENCE: [INAUDIBLE]
BRENDAN MULLINS: Person, like how many people?
AUDIENCE: How about with time?
BRENDAN MULLINS: How much time, yeah, that's a really hard question-- I mean, a lot for some things. For instance, like the documentation thing. That's a huge part of this job. So we were willing to spend a lot of time on that aspect of it.
I mean, I don't know if I could really quantify the amount hours that were spent making that thing automatically tag and go into Rhino with shared parameters. But it was a couple people in a couple-- in a week or two weeks, of just beating at this thing. Tons of overtime and everything else associated with architecture.
But I think it depended on the task. The amount of time it would have taken to manually import everything or re-paste images on a 400 set. Even a week and a half of labor on that is worth it in the long, run because of how many times we're going to have to repeat it, and just how tight the deadlines are. So certain tasks got a lot of time and a lot of horsepower behind them from the young guns.
Not all jobs will have that luxury. The same thing, we don't have a choice, really, so we had to put the horsepower there to get that done, because there was no other way to do it. But, yeah, a lot of time. Another question--
AUDIENCE: How did you handle conversations with [INAUDIBLE] not an official deliverable, but trying to convey that expectation [INAUDIBLE].
BRENDAN MULLINS: Yeah. I mean, knowing who our client is, they're pretty advanced to begin with. I don't think there was any trouble convincing the client that 3D models are important for delivery. I mean, with the city, of course, there's plenty of people who go in for a plan check over the counter with paper docs. Things weren't always like that with us. We bring laptops.
We have to have a computer next to us all the time to convey an idea. Of course, we can go through the set and explain it. And of course, for final permit check and stuff, that has to be done. But we had to have the model next to us for all these conversations. We're not going to present this project to anybody without-- I'm not, without a computer in front of me.
Ideally, I would have done the same here, just despite whatever inevitable technological challenge I would have. But spinning that model, and having a quick visualization of it was always critical, from everything-- from clients, to plan check, relationship with contractors. I mean, every meeting we ever have has the Blue Beam and the model. That's like our base tools to do anything on the project. Screenshots, drawing, back and forth constantly, there's no other way to do it. And I feel lucky that it's forced that mentality, where I would never consider it another way.
AUDIENCE: [INAUDIBLE]. How did you communicate things like the [INAUDIBLE] for example. [INAUDIBLE].
BRENDAN MULLINS: We didn't have much turnover, truthfully. There was a little turnover. Luckily, the real-- some of the really solid gurus that did that stuff are still in our office. They're not necessarily on the CA team anymore. Of course, staff gets cut down, certain people move on to other jobs, but they still sit across from me. So we can always bring them on. I honestly-- it would have been terrifying if we had some mass exodus of certain people.
Because was that redundancy taught to everybody? No. I mean, you saw that one script, it's like three miles long. Is somebody just going to come in and start using it tomorrow? I don't think so. I think we are lucky not to have that issue. But I think it goes back to another question about libraries of scripts and things.
In the future if, I were to successfully automate stair cores or something, it would be nice to have a how-to, a very simple how-to and a very simple script, so that this stuff could be rolled forward. But yeah, we were lucky not to have much turnover. So that problem really came around. All right, well that does time. Thanks everybody. Appreciate it.