Model mapping - Revit Tutorial

- [Tutor] Model maps, also known as linking diagrams, are communication tools that help explain the linking structure of multiple CAD models. If your project's going to have multiple Revit models linked together, it should probably have a model map. This map can be a helpful diagram that helped explain your project structure to a larger team. Not only that, creating a model map can be a really useful brainstorming tool for the project team to think through how they want to organize their model early on in the project. So there's a lot of tools out there for creating these maps. It's basically a flow diagram. You could use tools like Visio, Miro, even a PDF editor, word editor will do. So having a well organized model structure is the first step to creating an effective well organized model. And in this lesson I'm going to cover how you might want to think about a model map and a few considerations when thinking how to divide up your model into different elements. So first, let's look at this really simple example. In this model map, we are describing different file types linked into a Revit file. Now, if I was working on a real world project that was this simple, I probably wouldn't have to create a model map. But the purpose of this diagram is to just get us in the mindset of what a model map is. In this next really simple example, we have a model map that explains how two rivet models linked together. So in this model map, we have two Revit models, one that's holding core and shell elements, and one that's holding interior elements. And this is a really common structure we might want to use on larger building files. Once again, if I had a model that was this simple, I probably wouldn't create a model map, but this is usually one section of a larger model map in real world projects. And here is a slightly more complex model map. In this example, we have two buildings that are linked into a site model, ARCH B and ARCH A. And you can also see that ARCH A is actually composed of two models, an interior model and an exterior model that are all linked into a site model. So hopefully now you can start to see how describing your model structure in this way can be really helpful in describing your model organization. Now let's get into some more real world examples. This usually is the complexity level that I'd start to create a model map for. In this example, we're looking at a hotel and conference room center set up. And the main thing that's housing all of our model is our site model in the center. And that site model is holding a lobby model, a hotel model, and a conference room center. And you can see that the different models have different structures depending on their level of complexity. The lobby model, because it's holding less elements and is less complex, is only composed of one model. And we might want to consider down the road potentially splitting it, but for now, at the beginning of the project, it's just one model. Our other hotel conference room centers though, are composed of three models that are all linked together into a combined file. Let's look at another example. In this model map, we're looking at a stadium project. So here we have a main stadium model that is basically a shell model holding all of our other elements. So the models that are listed along the bottom are describing existing conditions that are going to be pulled into the model. And along the top, we have consultant models that could be potentially pulled into the main model along with the new construction of the project. And finally, I wanted to show you this example of just model structure. So here, this wouldn't be considered so much a model map as a list of different models within your project, but it's still a useful way to think about how your models are organizing elements. So in this list we have the model names along with a little bit of detail of what their purpose is. So this could be a really useful tool in onboarding a new employee to a project to help them understand what models are holding what elements. It's also really helpful to make these distinctions so that you have well organized elements in discrete model packages. So let's talk about some considerations when creating your own model map. The first thing I want you to think about is the project delivery schedule. So if you're starting off a project that potentially has future development in it, you want to think about if your current model that you're creating could potentially house future contract needs, or if you might want to create a separate model for that future contract. You could also think about the delivery schedule of different design sets. The next thing I want you to think about is your team size. So a good rule of thumb is to have no more than five to six team members working in a live Revit model at once. After that point, things like synchronization can get a little difficult for projects. So a good way to think about your teams is how they're going to be working on the project. So a simple example of this is you might have an exterior team working on the facade and an interior team working on the interiors of a project. You could also have teams that are organized in different sections of the building that are really discreet and maybe not interacting with each other. In that scenario, you might have a different Revit model per those sections of the building or those sections of the site. The last thing I want you to think about is the model size. So usually we don't want our Revit models to become larger than 500 megabytes, and once you get past that point, you might want to consider splitting your model. So taking into account model size can be really helpful when thinking about efficiency for the entire team. So hopefully at this point, I've made a strong case on why you might want to create a model map for your own project. Thinking about these model maps is especially helpful earlier on in the project and can help tremendously with efficient team communication and model organization.