Fabricating with Families: A Decade of Lessons

JIM GLEESON: Hey, everybody. Welcome to "Fabricating with Families-- A Decade of Lessons," brought to you by Jim Gleeson, here, of Victaulic. The main points-- today's topics or agenda that I'd like to cover is a quick introduction and background of myself, my company, my department, what we do, and why we do it.

Moving forward, we're going to talk about why families are our primary way of creating fabrication deliverables. There are other options out there, and why we landed on families is an important topic to talk about. How we have come to understand our users through software-- not just our internal users here, but also our customers as well that are utilizing any of our pieces of content, our families, our templates, things like that that we share out within the industry.

After talking about how to understand the software-- at least how we've come to understand our users through software-- I'm going to talk about some of our considerations and the directives that we use when we are creating Revit families to make the jobs easier for our end users, both internal and external. And then, Revit can only do so much. So there is a point where we'll be leveraging software to support fabrication and prefabrication solutions. So we'll spend a little bit of time talking about that.

Now, before I get deep into the presentation, I did want to note a comment that was made by the Autodesk organizers was that previous Autodesk University sessions have been kind of general. And as a longtime AU attendee myself, I can agree with that. So this year, we've decided to switch things up and really get more specific.

So instead of trying to cover many different industries and all these different applications, what we wanted to do was talk specifically to our processes, how we've evolved into where we are today, and hopefully through that, you'll be able to take different lessons for all the different industries that you're in, whether or not you are contractors or engineers or manufacturers or CAD managers, BIM houses. Those are all industries or areas that we touch on through our workflows as well.

First topic-- quick introduction and background-- myself and the company. So who am I? My name is Jim Gleeson. I'm the software technologist and administrator for the global VDC here at Victaulic. I'm one of our Autodesk experts. So going beyond Revit, I'm also the guy that generally gets the phone calls when Navisworks isn't working or somebody is having trouble getting access to ACC or there's an issue within AutoCAD. I am going to be that person that's usually contacted first internally.

I also deal with a lot of our customer tours and presentations regarding our content as well as the software that we've created. I started off as a draftsman in multiple different industries. I was in furniture design and did a little electrical and architectural well before I landed in the piping world of Victaulic here.

In addition to me, I do want to give a special shout out to Ralph Schoch, who is my colleague and mentor. Pretty much everything I know about Revit, I through Ralph, who is also known as Revit Ralph. He also has a session at Autodesk this year. It's happening at the same time as my talk, but I would highly recommend looking him up and taking a look at his sessions. He's going to be talking about some similar workflows, but he also gets into different levels of detail there.

So who I work for-- I work for Victaulic. Victaulic is the industry leader in the mechanical joint solutions. We pioneered grooved mechanical couplings to make it easy to put together-- well, not just easy, but easy, fast, and with quality to put together piping systems. We are based in Easton, Pennsylvania. And a couple images there in the bottom corner-- you can see a picture of our foundry where we cast the elbows, T's, couplings, and pretty much everything else that we produce is all produced by our production facilities.

And beyond fittings, we also produce accessories like valves and strainers and full modular solutions as well. So our company has continued to grow through innovation. Size-wise, we're a pretty sizable company. Our patent was first filed for the mechanical coupling back in 1919. But since then, we have grown to a global company. We support some 51 countries that we sell in. We have seven foundries located in all different geographic locations. And today, we now have over 4,000 patents on all the different technologies and innovations that we've created within our products.

But beyond the company itself-- I don't work for the manufacturing side or sales or distribution. I work for the VDC, or Virtual Design and Construction department-- our group that helps out with the design of these piping systems. Our group has over 130 people globally, and our main focuses are around estimation. We today use Revit as our main estimating tool, because of the efficiencies that we've been able to build in with our content and with our workflows so we can have accurate and quick estimates that we can work with customers.

If the contractor that we're working with is awarded that project, then we can easily take that model right into BIM coordination. We may not have all the information at the time of the estimate, but we make it easy within our content to update the valves and elbows and whatever other pieces that we're utilizing inside of our models into something that is accurate within a coordination space, so we know that it's going to fit, but it's also going to be accurate at a fabricatable level.

We're going to be calling out accurate dimensions of for fabrication spool drawings and other software that may be potentially consuming the data that we're creating inside of Revit. All of that is fueled by our content and software team. That is the team that I specifically work with within Virtual Design and Construction. Our team is kind of twofold. We do have a content side of it where we are creating Revit families as well as content for many other piping platforms. And then also on the software side, we create add ins and software and application to help facilitate the use of all of this data.

And one of our last focuses here is around reality capture-- making sure that we're getting the accurate conditions of the site if those conditions exist to make sure that everything we're doing is accurate, buildable, fabricated. Specific to my side on the software, primarily, every day, I'm focusing around Victaulic tools for Revit. It's the add-in that we made at first for our VDC to make ourselves more efficient within Revit. But it's also the platform that we use to help distribute our content out into the world.

One of the newer things that we've created is Victaulic Spool Tracker. It's only been out for the past couple of years. And it is a extension of Victaulic tools for Revit, where all the data that we have been managing inside of the Revit atmosphere or ecosystem, we can export that out to a mobile app that can be used to track productivity of that data after it's left the Revit system, regardless of where you may want to track that data.

It could be in a shop. It could be in shipping. It could be on on-site installation. It could be to track issues. We really try to make it easy to interact with those pieces of software.

But moving beyond what we do and who we are, why do we primarily use Revit families? And first, it's a little bit of a history lesson here-- so how we got started utilizing Revit. Back in 2009, we started working with Autodesk to create Revit families of Victaulic products. Back then, Autodesk was-- they had this initiative to create a large library of content. It was called Autodesk Seek. And we worked with them to create a library of all of our parts and pieces.

As a manufacturer, we like to have our content, our products represented in every software that we can get our hands on. So that's pretty standard work for us in our content team. But we also saw that Revit had some interesting things going for it, even back at the time in 2009. But already then, we had been pretty comfortable in producing the deliverables that we were. We were working in AutoCAD MEP, and didn't see any reason at the time to shift from working in AutoCAD MEP to Revit.

But over the years, that changed. By 2014 was when we decided to make our transition out of AutoCAD MEP and into Revit. It was targeted by our VDC team based off of some of the native functionalities that it could already bring to the table-- the ability to easily revise models and have that data update automatically through tags, the ability to work share within a model-- we can have multiple people inside in a project at a time, inside the same floor working alongside of each other. It was a game changer for us.

The idea of connectivity and making it so we didn't need to double check by hand dimensions on cut lengths and things like that-- we knew that as long as we had accurate content, we could produce accurate deliverables that could be updated very quickly within BIM coordination atmospheres.

So when we decided to make our transition to Revit, we took that original library that we created with Autodesk, owned it entirely, learned from it, and updated it so our content was a little more responsive. But then we also fleshed it out to represent our entire library of products now. Pretty much everything that we make is available for download and it's available as a Revit family.

Because of these initiatives, because of these updates, we have been able to create thousands of Revit piping projects utilizing this content, these softwares, these workflows. And not just thousands since 2014-- we create thousands of models every year. And that's from estimating out through BIM coordination and fabrication.

So first, we have to address the elephant in the room-- fab parts. That's usually the first thing that people talk about when you mention fabricating within Revit, especially around MEP systems, being pipe, duct, or electrical. Fab parts were the first group to come in, and it was also the standardized content. So how can we justify using families over fab parts when fab parts for so long were the industry, and some would argue are still the industry standard?

So first, let's talk about fab parts and families a little bit, and then I can explain why we chose to go the way that we did. So what are fab parts? Fabrication parts or ITMs or items are pieces of content that are managed by an external database. And fab parts have been incorporated into Revit back in 2016. So if you recall back on that date, we made our target around 2014. So fabrication parts weren't even available in Revit when we decided to start transitioning our workflow into it.

Believe it or not, at the beginning, we thought that families might have just been a short-term solution until fabrication parts were going to make their way into Revit. But we went a different way, as I'll show. There are definite pros and cons with fabrication parts versus families. Some of the pros are that there's lower training requirements, because the parts themselves are defined into services.

Everything is predetermined for the users of those services. They're limited in what fittings or valves or different parts that they can use inside of a system. And that offloads some of that responsibility back onto the CAD managers themselves. They're the ones that need to set up these services with all those parts and pieces for their users. And then for the users, it's simplified. There's only a certain amount of things that they're allowed to use that are already set up within that system.

In the United States, every major MEP manufacturer has ITM content. It was the industry standard or is the industry standard. It's been around for quite some time, since the late '80s, I believe. So the content is there. And it's Revit content. Revit families certainly weren't available early on inside of the software.

Most of the standards, or most of the parameters within fabrication parts are standardized. They were determined within fabrication parts. So as a result, it simplifies or combines a lot of the data parameters that we find issues with in Revit families. And a pro, but sometimes also seen as a con, is how the fabrication parts are managed. It's typically through or it is through an outside managing software-- Fabrication E-S-T, or EST, or Autodesk has produced now a web platform called the Fabrication Database Manager-- FDM for short.

These are ways that database managers can create all those pre-definitions for users. So that's great on one hand, but on the other hand, it limits what those users can work with. Creating a service is time consuming, and they don't necessarily update very easily. So that is something to be concerned about.

In the creation of a service and then continually reusing that service, that's generally the way that things go. But updating services partway into a project, especially if you've gotten deeper on into fabrication spooling, can really start to cause some problems a little later on.

Another issue is that a lot of the ITM data that is used to create these parts is not available to the front end of Revit, not in the Properties palette. So it is available on the back end. There are some tools out there that you can snoop into the databases and pull that data forward. But because fabrication parts weren't originally made for Revit, there isn't a linkage there for all the data that you may want to be showing inside of your drawings or your models.

Fabrication parts are created with these predetermined geometries called patterns. So patterns are great in the way that it can help standardize those parameters, like I mentioned before. But it also limits what can be created, specifically around more modular solutions as manufacturers, including ourselves, have been creating full solutions for PRV stations or pump drops or entire pump skins. There's no single pattern for very large modular collections of components that we would otherwise treat as a part. So there's a certain area where it becomes much more difficult in fabrication parts to manage.

And another consideration around fab parts is the ratio of CAD managers to projects. This certainly differs based off of the scope of work, like how varied are the products and materials that are getting used in projects-- the different systems that are being used. So depending on how varied it goes, how many projects you have, it can limit how much work can be taken on.

Families, on the other hand of fab parts, are native Revit content. I mean, fabrication parts are native to the software now. They've been fully integrated. But families were created specifically for Revit. These are the parts made for Revit. And instead of being managed through an external database, they can be grabbed and dropped as needed. And all of these parts are built directly through the Revit Family Editor.

And there's some different pros and cons here. So one pro, but it can also be seen as a double-edged sword, is Revit users have the freedom to download and use any parts that they need. They can go on any manufacturer's website, download that part, and pull it right into their project and use it. Now on the negative side, they can do that for parts that they shouldn't be using or don't need as well. So that is a difference between fabrication parts and families.

So families do not have predetermined patterns or geometry to be utilized. So you can build literally anything out of families. Because there is no database predetermining everything that can and can't be used, a smaller support staff is really required to oversee large and diverse projects. When you're equipping the Revit users to use whatever they need to use to get those projects done, it doesn't require a CAD manager to continually go back and update all of those services that then need to get reloaded into the project for a user to use it. User can just go find what they need, pull it in, and use it.

As a result, there is also a shorter project start up time. A template can be created with all the generic stuff that's needed-- generic to a point, everything dimensionally accurate. But then, the more qualitative data that may need to get applied to a project later on, like stainless steel nuts and bolts or specific types of gaskets or coatings and linings and different things like that-- all that stuff can be added on later in a project. I don't necessarily need to go update a service in a database to reload that into my project. I can now use those specific parts and pieces when dimensionally, a lot of that stuff is identical.

Some of the cons are, there's really no rules within Revit to validate connection types. That's definitely a big advantage that fabrication to parts has, where you are defining what's the connection type and whether or not it is male or female. And in doing so, it prevents users from connecting the wrong thing to the wrong thing.

We've created some software solutions to help validate our connection types, but it is not something native within Revit. I can connect a coupling to a flange. I can connect a coupling to a piece of duct. And in reality, Revit doesn't care. But in reality, we do. So that's a consideration that we need to consider.

There is much higher product training required with Revit families, because users can use anything. And we have found that that can limit somebody from working with subcontractors. In a fabrication parts workflow, when you are dictating what parts can be used for your users, you may also be creating those configurations and services for a subcontractor and predetermining everything that that subcontractor can use. They don't need to have in-depth product knowledge of those parts and pieces. So a consideration there.

And the last one that I want to note here as a con is the parameters are not defined by a standard the same way that fabrication parts are. So any manufacturer can create a parameter called description that can only be used by certain tags. And Revit having the ability to use shared parameters and requiring shared parameters to call out different values-- things can start to definitely get disjointed across different manufacturers and families.

Oftentimes, I'm asked to talk about families versus fab parts. And really, I'm not here to tell you which one to use. I'm just telling you the directions that we've gone. And oftentimes, when I'm making these comparisons, I like to compare families and fab parts to trucks and trains.

Fabrication parts-- I think very much like a train. When you know your starting point and you know your ending point and that stuff is predetermined, it's really fast and very simple for your conductor to push the lever forward, have all the tools that they need available, and get to that endpoint very quickly.

Families I consider to be more like trucks-- very flexible in the way that if I need to go from point A to point B and I already know everything ahead of time, fab parts are probably going to be the quicker way to go. But we have rarely encountered any projects where we know that endpoint all the way down there. So the families enable us to relocate and move to any endpoint.

And just like a driver can change direction and go where they need to go, they can also change direction and go where they shouldn't go. But it's really taking the control from the fabrication manager and giving that control to the end users. And that's why that higher training requirement is on the end users. But at the same time, it does then bring in the flexibility and enabling them to do what they need to do to get the project done.

Today, primarily, we use families. We do it because we are often using modular products which we have available as families and are not very easily created or manageable within fabrication parts. The family editor enables us to make everything dimensionally accurate where patterns do have some limitations. You can see I have some images on the side here of a real life scenario that came up because a customer that we were working with was using fabrication parts. And you noticed that the handwheel where that stem comes out is offset of the operator within our valves in reality. And we've seen that to be the case with many different manufacturers.

Well, within fab parts, you are limited to what you can adjust. So I can't have a handwheel or a stem go off of an operator like that. I could adjust the operator, which is what I sometimes see used, or oversize the handwheel. So there are ways to compensate for it. But it's still not really dimensionally accurate, and that's what we're going for deeply with our Revit families. So I show that part as an ITM, but also as an RFA. An RFA we can customize and build really whatever we need.

The flexibility of Revit and not predefining all of these systems enables us to estimate with various levels of detail early on in the project and then be able to add more quality data to those projects as we move forward without changing and reloading specs and configurations. We can just apply that data as needed later on inside of the project.

The quantity and variety of the models that we create here is vast. And we would need a much larger support staff creating and managing services for all of our users, all of our projects. And if we would have gone down the fab parts route early on, that may have been the situation where we would have wound it up today. But it's just not what we did.

Today, with a smaller support staff, we are able to support all of our projects through all the flexibility, through the large quantity of them required as well. And for us, we're able to guarantee our model accuracy by making sure that we have good, accurate content through our training programs to make sure that everybody we have here and everybody that we work with knows our products and knows how they're used. And we've also created some software solutions to help out with those things as well.

Moving on. So we have come to understand our users by understanding the software. And it's really helped us bridge a gap as a manufacturer directly out with installers and BIM managers and modelers. So what we do whenever we're looking at any software is we first want to understand how is that software intended to be used? And once we have a good understanding, we then know how to apply our solutions withinside of that ecosystem.

There are some software solutions out there in other companies that burn everything down and want to redefine how everything should be done. We are not one of those companies. We like to look at the software, see where it works, where it doesn't work. And when we see where it doesn't work, we then look at solutions to overcome those.

So for us, the first thing we looked at within Revit was looking at the routing preferences. Revit does have the innate ability to draw piping, and it has the ability to put in elbows and Ts and end caps and things like that. So first thing, we look at the routing preferences, and then we'd also look at all of those part types that can be utilized by the routing preferences, which helps us define what categories we're using and what we can and cannot do within the content as well.

We're also keen to observe when and where those part types are used natively in Revit, because they may give some different functionality as we're actively using it inside of the project. The categories that we thought we should use, turns out we really don't want to use because of the way that they actually behave inside of the software.

Victaulic-- as I mentioned, mechanical couplings are a big deal for us. There is a category called mechanical couplings within Revit families. And we almost never use it, because it doesn't behave the way that we would expect a mechanical coupling to use. And I have some examples here to show you.

For us, it was important to recognize that flanges within routing preferences are automatically placed when pipe connects to fittings and pipe connects to accessories. For us, we use couplings which would connect to fittings and accessories. So we knew that by just swapping out a coupling and calling that coupling a flange was going to natively work inside of the software in most of our cases here.

We also noticed that unions are placed when using the split element tool. So we would look at utilizing or classifying the coupling as a union to split. But then we also noticed that when a flange is specified at that size for routing preference, instead of putting in a union, it'll put in two flanges, which actually doesn't really work for groove systems as well as for welded systems. So I'm going to show a little bit of how that can be overcome.

As an outsider within Revit, it could be overcome pretty easily. If there's anybody at Autodesk listening, please reach out to me. I know from a software side, we could fix this and make it really awesome. But here's a good example-- native pipe type routing showing threaded, flanged, grooved, and welded. Here, I'm just drawing pipe. I'm drawing it as threaded. I'm drawing it as flanged. Created some routing preferences, utilizing different pieces of content that are already out there.

Something like split element-- when I split element on a piece of threaded piping, it's just going to put in that union. When I do it on flange piping, it puts in flange. But then I'm going to get different scenarios when I'm talking about grooved or welded systems. Because I may specify a weld or a coupling as a flange, it's going to put in two of them. So then I would need to select one of those and swap it out with a different type of family to overcome Revit's desire to have two flanges in that location.

That family that we'll swap it out with is what we call a non-connector. It is a family that has no dimensional intent. It also has no description on it as well. It gets ignored by most tools. It just helps keep Revit happy. So here is selecting a coupling, selecting a weld, swapping it out with a non-connector. Everything is dimensionally accurate.

Placing an accessory-- works great with threaded, works great with flange. Works good with Victaulic products as well with the couplings. But typically on a welded system, nobody is putting welds against a valve. So what can be done is by selecting those welds and replacing them with a flange family, we now have welds that are fittings and flanges at accessories.

The flange part type that we're utilizing so heavily was added to Revit in the early 2010s. I'm not sure exactly when it was, but it really is what made us change our mind about moving into using native Revit for these parts and pieces. You can see that just for routing in most systems, it gets us pretty close.

A common workflow that I've seen out in the industry, out in YouTube, is, well, these connecting elements, these flanges can also be kind of unpredictable. Like, oh, I want flanges on all of my valves. So why don't I nest flanges on all of my valves? Or why don't I nest all of the couplings onto the elbows? And the problem is that we're not always needing those at those locations.

Sometimes I'm moving back and forth between slip-on flanges and welded flanges. Or I'm moving between a carbon steel system and a plastic system and need transition couplings or different styles of flanges. When you nest those parts and pieces onto the fittings or onto the accessories, you start limiting what you can use on those parts and pieces.

And initially, when flanges were not available, what I first described is what we did. It was what was recommended by Autodesk-- to nest those couplings on the elbows. But once flanges became available, we decided to jump on that train, because now, it's enabling our coordinators, our users, to just put in natively what it needs 90% of the time. And then on that 10%, swap it out with the different flange style that is needed.

So another consideration that we make around Revit content is how are our users interacting with this content? Modeling is one thing, but also needing to use it for designs or for creating piping layouts is important. Dimensioning is a big deal. So for any manufacturers out there that are currently managing Revit libraries, please take note of how reference planes are being used inside of your projects.

Reference planes can be classified as different styles of references, and as long as those reference planes or lines are being classified as weak or strong, it enables users on the front end of Revit to dimension to those individual work points so they can dimension to the work points of elbows or to the end of a fitting or the middle of a valve, which is used often in piping layouts and sections and details and things like that.

Now, a requirement that was requested of us and is a common question when people use our content is what are those little cheese wedge things that you can see on our elbows? And those are work point geometries. Now, we can use reference planes to make it so it's easy to snap onto those dimensions. But sometimes people have trouble with it. And another requirement that was asked of us is if we could make it possible to dimension in 3D inside of Revit.

And the simplest way that we know how to do that is to make a work point a three-dimensional object that we can then host a work plane to and then dimension off of that work plane. So you can see down in this image, you can host the work plane to that little cheese wedge and then dimension on it to create 3D dimensions on the [INAUDIBLE] pretty quickly as needed.

Dimensioning in 3D is something that is still pretty manual, so it's not something that we highly recommend, but the option is there. And then also for visual accuracy, all of those cheese wedges or work plane geometries can be hidden by the visibility and graphics viewer. Those have their own subcategories to them. So they can be used when dimensioning and then hidden when exporting out for projects.

Another consideration to make around Revit content is, what is the level of visual detail that is being used? Typically, most of our content is being used either in the coarse view or the fine view. Coarse or single line view is being used a lot by design engineers who don't want to be too specific about the products that they're using but are still looking for really efficient modeling workflows.

So we've made it so they can utilize our pipe types, which click-wise is not very different from the standard generic Revit piping. Still be able to have accurate models for exporting or making some deliverables look good to owners, but as far as design-wise, can still produce single-line geometry. So really, all families should be seen in both coarse and fine view. Really, any of those visual detail levels should be considered in creating the content.

Another thing to consider as far as users interacting with your content is starting off with the right Revit template for those families. Considering-- does this element need to be used in a system? Does it need to stick to something like a floor or ceiling or a wall? As a result, there's different templates that can be started off with that basically make it a requirement that that element needs to be stuck to something or can be utilized inside of Revit systems. So it's important to consider those.

Now also at the same time, I want to illustrate one of the points that gives my coordinators nightmares at times when modeling with piping systems. And it's a term that is well known around face-based equipment. Quite often, for my piping coordinators, when they hear face-based equipment, they start getting nervous. And it's because of a situation right here that I'm about to show you.

Quite often times, we see mechanical equipment that would be stuck to a floor is face-based. So here, I have a pump family that when it was first put in, was hosted onto a housekeeping pad or a mechanical equipment pad. And what that does is once it's hosted, it can start to be influenced by the elements that it's put on.

Here, I can move around a housekeeping pad. But you see that that piece of equipment is stuck to it. So if I go to move a housekeeping pad even just a little bit or I want to size it over to include multiple pieces of equipment, it's including those fittings. Or in this case, I have some inertia bases that I now realize need to get utilized. And I want to host my pump to it.

The first inclination that most Revit users have when they encounter this scenario is they want to click on the piece of equipment and hit the Pick New button, because when they hit Pick New, then they can select a different piece of geometry to host it-- in this case, the top of the inertia base.

But what happens when they go Pick New is it allows them to pick anywhere on that element. And when I'm talking about a connected system like this, the system does not operate very well. So if you are a manufacturer and you have created face-based equipment specific to what I'm looking at here, and you get these questions from your users on how to better re-associate these things, the easy solution is to select that piece of equipment that is currently hosted to a floor, a housekeeping pad, a something.

And instead of collecting Pick New, there is a button on there-- one you can select instead of Pick New. It's a work plan. And what you can select is-- you edit the work plane and then you hit Pick a New Plane, and it will just jump those elements right out.

Now, I would highly recommend that if you are building any of these pieces of equipment or something that would otherwise get stuck to the floor, to not build it as a face-based piece of equipment. If the level moves, the floor is going to move, and all those parts and pieces are going to move with it appropriately. So there really isn't much of an advantage to hosting it directly onto an element like that.

Instead, if you even use the Revit mechanical equipment template, that's not a face-based piece of equipment. It's something that somebody can easily just put on whatever level, and they can adjust that offset as necessary. So if the housekeeping pad changes in thickness or they now need to use an inertia based or there's dunnage steel underneath a cooling tower that is changing, it's not all connected, and it's not going to mess with systems. They can just change the offset on that item and move it up and be fine.

So after understanding how the software is utilizing these parts and pieces, how our users are interacting with these parts and pieces, now we can take all of that into how do we want to go about building Revit families? So this is a collection of considerations and tips that we use when we're creating Revit families.

The first thing if you are creating anything for systems like pipe duct or electrical is, first, don't reinvent the wheel. Understand what's already there. We first started by working with Autodesk to build up our library, and the generic Autodesk family library that is available in Revit has great starting points for you.

There are some things that are essential to making everything work-- some requirements like where the origin of the family is located. The IDs of connectors need to line up-- so if somebody does change the pipe type, that everything is going to move and swap out appropriately. I showed earlier how we can swap out our flanges or couplings or welds based off of what we need. In order to do that without breaking the model, the considerations on where the connectors are, their IDs and the origins are of utmost importance.

Another thing to is although families don't have a standard, so to speak, on parameters, Autodesk has already created them for us to a point with this generic family library. It is the same family library that we started off with when we modified to create our products, and it's the same one that we've noticed many other manufacturers do as well. So it's a great template to start working off of. And modifying an existing family is much easier than rebuilding it from scratch.

Now, at the same time, you're only going to learn so much about Revit families from modifying. And really to get a full understanding of how to create Revit families or work with Revit families is to create some yourself. So if you are brand new into Revit families, highly recommend creating a few from scratch.

Now, I wouldn't necessarily jump right into creating system families like elbows and tees and valves, but I would start with simpler, boxier types of families. And there's lots of resources out today. I don't think there's ever been a better time to start building with Revit families than the amount of information that's out there. Regarding templates and Boolean logic, I would definitely recommend learning some basic Revit formulas. They can be absolute lifesavers for you. And I have a bunch within the handouts for this session.

Another thing to consider is the level of detail that you want to build into your families, because our products versus how we show it in Revit is drastically different. I brought in some actual pictures here. I brought in some actual pictures here of our products. And you can see that there is a difference between how they look in reality versus how they look in Revit. And I certainly could add that level of detail into them. I could put the name Victaulic around the elbows, and I could show nuts and bolts on all of our couplings.

The problem is that the more geometry and the more data that you put into these Revit families, the bigger those files get. And on massive projects like we will encounter, the more data that Revit has to chew on, it can eventually hinder performance. So what we have found is the simpler we can keep our geometry, the better the performance is going to be for our users.

So that's why we don't show nuts and bolts. And even on our flanges, we're not showing bolt holes for flanges. The flanges are going to get delivered with bolt holes, and there will be nuts and bolts and things like that we can associate as nested components. But it really doesn't add value within a model to show those things, at least not for a coordination space.

But it is still important to notice a difference too. The couplings that I'm showing here-- I have a rigid coupling versus a flexible coupling. There is a visual indicator looking at it in reality. And in our models, if I tried to show that level of detail, it could be easily missed by a installer or a prefabricater. So instead, we do a little material swap and show our flexible couplings with black ears versus our rigid couplings with the standard Victaulic orange ears.

Now, although we do recommend limiting the detail, what you should never limit are the overall dimensions that are affecting the constructability. All of our overall dimensions of all of our products are going to be accurate. And anything that affects constructability, like in the image, I show this 3/16ths of an inch-- that is the coupling gap of pipe separation required between the elbow and the pipe.

So based off of the size, it's going to flex and change that pipe separation required. On threaded fittings, I'm absolutely going to be showing and utilizing thread engagements inside of those parts so I have accurate cut lengths when I need to produce these things out later for fabrication.

Now also, at the same time, while simplicity is recommended, it's really required more for the items that are getting used the most. If you have some smaller use parts and pieces that could benefit from higher levels of detail, go ahead for it, because it's really just being used a handful of times within a project, not being used tens of thousands of times like our couplings are.

So creating Revit families-- there's a couple of different ways to go about creating and driving these parameters within these families. The longest way or the most established way of doing so-- the way that was originally defined by Autodesk-- is around accessories, at least, creating type driven, loadable families.

So what these are are families where you can select a type, which is a pre-configuration of that specific part. And within that pre-configuration is predefined all of the dimensions and the different values that a user may need inside of a project. If you go and download most valves from the generic Autodesk library today, you're going to find that those are type driven families. This was the established way for doing it for a very long time.

The workflow typically for other manufacturers and the way that they've used type driven families is you have a family file, an RFA, and a text file that goes alongside of it. And when you load that family into Revit, what pops up is a list of all the types and all the different configurations that are available within that part. A user selects the configurations that they need, and then that is what gets loaded into the Revit project.

This works very well for contractors that are looking for a specific part, a specific size, a specific configuration. So they're great when all the parts and pieces are defined. We have seen that type driven families are usually shied away from from earlier on in the process, from people like design engineers that are really looking for more efficient modeling techniques inside of Revit and don't want to get so specific with everything that early on in a project, because this workflow also makes things difficult if all of the configurations that were chosen were not all the configurations needed.

Now, if something new is noticed, like there was some line sizes changed or we need a different configuration, you need to go locate that family in that text file again, load it back in, select the new configurations, and find those families, and then swap them out.