What’s the Point?

A couple weeks back, I attended a meeting of the London Revit User Group where Paul Fletcher from ZBP and Through Architecture presented Beyond BIM: Cooperation for a sustainable future. Paul seemed to be a man of strong convictions who had no qualms creating some controversy when discussing where we’re heading with BIM and the tools we’re using to get there. I very much enjoyed his talk and especially liked his focus on the Information in BIM.

I agree with Paul that the way we can move forward as an industry is via Information. Information that can be shared and reused. Because what’s the point of having a piece of data in a model if no one knows it’s there, or if it can’t be reused throughout a project? There is no point, really.

So when you look at standards that require information to be provided in a particular format, you can only feel a warm, fuzzy feeling inside. But when a standard, claiming to be a Revit standard rather than a general BIM standard, requests to have that same information in a format that is not reusable, one’s enthusiasm quickly turns to frustration.

There’s no stopping anyone from publishing whatever they like, nor should there be. But we should critique any standard that claims to be a Revit standard and has parameter requirements like the following:

What’s wrong with the above picture? Substituting NUMBER by WATTAGE would allow this information to be truly reusable, such so that it can be made part of formulas or calculations by engineers working on a project. When set in Number units, they lose their electrical properties within Revit. As another example, take a look at the table below.

I substituted LENGTH by TEXT. It doesn’t make any sense, does it? Those parameters won’t be driving any geometry, nor directly driving any dimensions in a model. Calculating the Width that 10 objects occupy in a project when placed side by side is no longer possible with a simple addition of their respective Width parameters. Well, the same goes for electrical parameters.

Hopefully standards like these can be avoided more often than not, leaving us no worse for the wear. Or, better yet, they can be updated following feedback from users.

Big Picture Revit Families

We recently finished some retractable projection screen Revit families for Stewart Filmscreen, based in southern California. These are the kind of screens installed in the ceiling of a conference room or auditorium, where you might barely notice the screen is there until someone hits a button and it gracefully descends from a sleek minimalist enclosure. Since the screens are recessed products, the bulk of the work was in modeling all of the different canvas sizes and image areas available for each of the two models.

Like many manufacturers of high-end building products, Stewart Filmscreen provides a range of standard screen configurations, but also allows customers to specify their own custom configurations within certain limits. To cover these options in the family, we used a type catalog containing each of the standard configurations. The screen size is defined by entering the desired image diagonal and aspect ratio X and Y values.

To create a custom screen size, you would typically duplicate an existing type, name it accordingly and change those parameters to suit. If a custom screen size exceeds Stewart’s stated maximum dimensions (which in certain cases they can still manufacture), the family still works fine in Revit, but the screen’s canvas turns red – by means of a custom material parameter – to alert the user that he or she has crossed into uncertain territory. The custom highlighting is done with the use of a faux IsCustom parameter. In my opinion, it would be great to have the real IsCustom parameter as part of most, if not all, Revit categories. Currently it only exists in the Pipe Fittings category.

Finally, any image can be placed onto the screen for renderings or 3D views in fine LOD – a project screenshot, your company logo, an image of whatever might actually get projected there, etc.

The families were delivered in two versions, one with all the parameters required by the InfoComm BIM Guidelines (InfoComm being a professional organization for the AV industry) and one without any shared parameters (my personal recommendation for any manufacturer, and probably worth another post at some point). The Stealth Trapdoor family shown here, with all the different types, custom highlighting, 2D levels of detail — plan and elevations, with differing front and back — as well as 3D levels of detail, weighs in at only 436K. The maths involved for the flexing of the family geometry were pretty fun to work with too.

So now, when you decide your project requires a high-end, quality projection screen, you can count on Stewart Filmscreens not only to provide the actual goods, but also to show up beautifully in your Revit project, both graphically and in your schedules.

Family Feedback Mechanisms – Part 2

Wouldn’t it be nice if your manufacturer-specific fittings would highlight themselves if they are set outside of the product’s catalog specs? Wouldn’t it be even nicer if they were highlighted without stopping your workflow as you lay your pipe runs? Then your manufacturer-specific fittings could even be used as generic or custom fittings as well.

Well I’m happy to report that you can have your cake and eat it too. The above image shows a pipe fitting family (an elbow in this example) that, when used in a project, will get highlighted in red if the angle of the elbow is different than either 45 or 90 (the two angles provided by the manufacturer). Not only that, it will also show you a non-modal dialog warning as you draw. But wait, it gets better! There is no plugin, hack or workaround. This is a built-in feature in Revit. The below video shows this feature in action.

You can achieve this seamless highlighting by means of the IsCustom built-in parameter on the Pipe Fittings Revit family category. When in a project, changing this Yes/No parameter will display a modeless dialog warning like the one shown below. The parameter can be controlled via a formula that draws information from within the project. You can add the colored highlighting by means of additional geometry associated to the IsCustom parameter.

One of our customers has been enjoying a set of fittings created this way and his feedback couldn’t be better. Long pipe runs, where a mistake of a couple degrees on a fitting can end up causing coordination issues, are now easily reviewed and fixed. And if a custom fitting is actually needed, then this can be highlighted and reported.

We are working on a manufacturer-specific set of fittings that all have this feature built in. I’ll write more about it when we release these families and write a follow-up post with step by step instructions on how to create such a family. If you don’t want to wait for the follow-up post, I’ll be at Autodesk University this coming week and would welcome the opportunity to talk with anyone who is interested in implementing this feature in their Revit families.

The Revit Families Frontier

Earlier this week I was reading a blog post by Steve Stafford on the state of Revit content, specifically content available from Autodesk Seek. The post is framed as a critique of Seek contents’ usability within a Revit project – bloated file size, incorrect category assignments, overly detailed visual modeling, etc. – and it ends with a statement that we’re still living in “the wild west” when it comes to Revit families.

After several years in this business, I’d have to say that I agree with Steve’s general assessment. We’ve written before on this blog about the lack of clear and comprehensive standards for Revit families. Even among the standards that have been published, we have yet to see any significant adoption by Revit users or product manufacturers. For the most part, people seem to do whatever they think makes sense based on whatever experience and understanding they have of Revit.

So what is the role of content creators in this “wild west” of Revit families? You could argue that we should be playing the role of sheriff, riding into town on our trusty steeds and bringing law and order to the people. Yet even among content creators there isn’t broad agreement on what constitutes best practices for Revit families. You can see this in the comments on Steve Stafford’s post. One of the comments from a content creator talks about the need to include a schedule with manufacturer-specific content (which means including shared parameters in the families), whereas we have written before about how the best approach is for manufacturers not to include any shared parameters in their families. Another comment from a content creator talks about including model text within the family at the request of the designers for whom it was created, even though that text nearly doubles the family’s file size. While we think there are better approaches to including help text with Revit families (i.e. through a separate text file), we’ve been in the same situation of having a customer specifically request embedded text and having to comply. As a content creator, sometimes you have to abandon your own best practices in order to satisfy your customer.

Taking a step back, I would ask whether we should be surprised at this fuzzy state of affairs when it comes Revit families. After all, Revit is still in a relatively early phase of adoption throughout the AEC community; it is a completely new kind of platform relative to its predecessor; and “Revit families” itself is such a broad category (everything in Revit is a family!) with such broad applications that it would be another kind of mistake to think we can find a one-size-fits-all set of rules and standards for how a Revit family should be built.

To a large degree, I think that developing and applying coherent standards will always be a slow and iterative process, and we need to be patient with it. At the same time, I do believe content creators have an important role to play in facilitating and accelerating that process. As a kind of nexus between end users, manufacturers, and Autodesk itself, and with a wider range of experience with Revit families than any of those parties, content creators are in a unique position to foster dialogue and debate on standards. The best thing we can do is publish our views on the subject and encourage public discussion on specific points. For example, let’s return to the question of whether manufacturers should include share parameters in their Revit families. To us, there is no doubt that it’s an exercise in futility for manufacturers to include shared parameters in their families. In fact, we believe it does more harm than good. If someone thinks we’re wrong about that, then let’s hear the reasons why and see if we can reach some consensus about what standard would make sense for this issue.

With only a few days left until AU 2011 begins, I’m excited to attend sessions and engage in personal conversations where I can hear the perspectives of other Revit practitioners and content providers on the subject of Revit family standards. I’m looking forward to a week of lively discussions and hopefully to making some measure of progress in settling the Revit families frontier.

Family File Naming Standards

A few days ago I gave a talk at the BIM Show Live in London. The title of my talk was Considerations on Family Creation. It was an update to a talk I gave this past summer at the LRUG (London Revit User Group) about key areas to review and define when creating or managing a Revit family library.

This time I added the issue of how to name your Revit family files to the list of things to consider. I think what I had to say came as a surprise to some people in the audience, so I thought I would share my stance here as well, where I can go into more detail and get more feedback.

To date, all the issued standards or guidelines covering Revit families contain a recommended naming convention. Let’s take a look at the different approaches taken by some of the best known standards.

Autodesk RMCSG

<Functional Type>‐<Subtype>‐<Manufacturer>‐<Descriptor 1>‐<Descriptor 2>‐<2D if necessary>

ANZRS (Australia & New Zealand)

<Functional Type>_<Subtype>_<Manufacturer>_<Descriptor1>

Open Revit Standards

<Identifier>_<Category>_<Type>_<Manufacturer>_<Description>_<Host/Size>

Revit Foodservice Equipment Standards

QF_Manufacturer_Model

Each has an accompanying set of rules about the use of special characters, lists of names for the different fields, exceptions to the rules, etc. It is clear that no two standards are the same or have the same rules. What’s more, two people using the same standard might arrive at a different name depending on each person’s interpretation of what information should go in a given field, how to make an abbreviation, etc.

In my experience, none of these standards has taken hold, and most companies also have their own internal naming conventions, different from any published documentation, which they are hesitant to give up. So what is a Revit user or BIM manager or product manufacturer to do in this world of incomplete and conflicting naming standards?

I would say don’t worry about it. It’s actually not a major consideration, or doesn’t need to be. Pick one that you think makes sense and move on. Don’t stress about which standard is most relevant to your industry, or most likely to gain popularity, or even the most comprehensive.

Why do I want to remove naming conventions from the list of things to consider? Ask yourself what the point is of having a naming convention in the first place. Not surprisingly, the reasons given by the published standards all vary, but there are two reasons that all of them have in common: a naming standard allows for 1) identification and 2) finding (searching) of families, both inside and outside of Revit projects. In my experience, these are also the two needs that make people the most anxious about choosing the right naming standard to use.

Identifying and finding families are cumbersome tasks with current tools. This is why we turn to file naming, which is perhaps the most rudimentary tool but also the most accessible. But this is bound to change in the near future. Outside of Revit there are tools for managing and finding families that are more powerful and faster than any naming convention would ever allow anyone to do. And these tools have only started showing up. I’m certain that within a year there will be more options available than published naming standards.

Inside of Revit things could quickly change as well. I don’t have any specific knowledge of how or if Autodesk plans to sort out the challenges of finding families within the project browser (and if I did, I wouldn’t be able to tell you), but anyone can see that the current solution is sub-par. An improvement could come as soon as within a few months. Even if it took a few years for Autodesk to address this, it will be much sooner than any significant amount of people agreeing to a file naming standard.

In short, I’m sure naming standards won’t be an issue anymore. The amount of man hours that have been spent considering the best file naming convention for Revit families would have allowed us to build and finish the tower of Babel six times over by now. Personally, I use one standard, apply small changes to suit working conditions, and rely on other tools for making sure I can identify and find my families.

The Death of the Family Types

As most Revit users know, a family that has types can be created in one of two ways: you can create the types within the family (which I’ll call “built-in” here) or you can create the types in an external txt file called a type catalog. For quite some time now, I have been pondering over the use and future of built-in family types. The more families I do, the more built-in family types just don’t seem like the right way to go. They feel more like a shortcut.

Type catalogs, on the other hand, have been getting better, more practical for day-to-day use, and, thanks to an improvement in Revit 2012, easier to deal with than ever. Gone are the days when creating a type catalog was an exercise in self-mutilation. Now you can just open any family in Revit 2012, choose Export -> Family Types and your template type catalog txt file is ready, without any chance of spelling mistakes or incorrect data categories. Sweet!

So what about the built-in family types? What’s wrong with them? I did a little research on the evolution of types in Revit by posting a question in some LinkedIn forums to find out how built-in family types and type catalogs came to be. My feeling was that the built-in types were first and type catalogs came later as a more thought-out solution. Wesley Benn confirmed my suspicions when he wrote, “…family types showed up in version 2‚” while “…Catalog files (then known simply as the family type browser) showed up in version 4.0.” And from the version 4 release notes as posted by Wesley:

Family type browser:

Families now can have types defined in external text files. These files must have the same name as the families itself and reside at the same directory location. When the family is loaded, externally defined types are visible within the “Load Family” dialogue and only those types selected by the user are created in the project. For families with a large number of possible types such as structural shapes, this makes it simpler to manage the type lists in a project.

So there you have it: type catalogs were created as a solution for families with “a large number of possible types.” This points to the one small advantage to built-in family types, which is that they allow you to bring into a project a family and all its related types in one fell swoop. In that sense they are a sort of group, and that’s about it. Everything else about them is a drawback. Say you have a family with built-in types and you don’t want some of the types in your project. Tough luck. After you load it, you’ll have to hunt down the family in the project browser (not an easy task given the current user interface) and remove the unwanted types. If the unnecessary types are left in there, you are wasting space and increasing memory requirements (though I would have to test the latter more thoroughly to be able to make that claim with certainty – if anyone is up to the task and wants to report back, it will be appreciated). And what if you don’t have time to go hunting and instead just leave the extra types in the project? If you’re working on a team, someone less familiar with the types of that particular family might pick the wrong type, and you end up with the wrong information in the project.

It doesn’t end there either. The maximum recommended number of types built within a family is 5. That is, recommended by the Seek guidelines (though not necessarily what users do in practice). With 5 types, updating some parameters for one type and forgetting to update those same parameters for other types is a common mistake. It’s one of the reasons why I always leave the creation of new types until the very end of the family creation process. But even that won’t help if I’m editing an existing family with built-in types. The interface doesn’t make things easy either. If you don’t check for yourself, there is nothing in the family editor to tell you that a family has other types!

In contrast, type catalogs won’t automatically bring in a set of types with just a double click. Instead, when loading a family that has a type catalog, you are able to select only what you need, and even filter through the available family parameters shown in the type catalog. You can repeat the procedure to bring in other types later, when and if you need them. And editing the types or adding types to the family is something that can be done from Excel or a Google Spreadsheet. You don’t even have to know Revit to update a type catalog – think about all the manufacturers who have or will have Revit families and need to keep them updated as their product lines evolve year after year.

Type catalogs feel like the way parameters ought to be managed. It’s easier than ever to create them, and every piece of family management software that I’ve tried or seen works as if type catalogs are the norm, i.e. allowing you to load just the types you need. Yes, there is still room for improvement with type catalogs (worth another post), but built-in family types don’t seem to be going anywhere. Rather they appear to be slowly fading from use in Revit, and that’s fine by me. As far as I’m concerned, they are already dead.

Shared Parameter Standards Part 2 – What’s a Manufacturer to Do?

There are a number of standards offering a list of shared parameters for manufacturers to make use of when developing families for their products. But which standard should a manufacturer follow? I will argue that none should be followed, but that all should be taken into account.

As long as there are competing standards for defining the names and properties of shared parameters, choosing one standard over another is problematic for a manufacturer that wants to facilitate the use of their families as broadly as possible. I believe the solution to this problem is simple: manufacturers shouldn’t add any shared parameters to their families. Instead they should include family parameters for every piece of information most of their users within the AEC industry might want to use within a project.

While I began by saying that there are competing standards for shared parameters, the truth is that calling something a standard does not make it one. And so I will correct myself here and say that there is a lack of standards, competing or otherwise. For something to be a standard, there needs to be an uptake and use of said standard among its intended audience. I personally don’t see evidence of this in my day-to-day work.

Architectural and engineering firms have their own shared parameters that rarely will include any shared parameter from existing published lists, even though the same information might be covered. Whenever I start working on a manufacturer’s project, I usually start by reviewing existing content from similar manufacturers, searching for anything that could be construed as a standard way to put together the families, including shared parameters. Again, rarely do I come across shared parameters from published lists within the manufacturer content I review.

Any shared parameter that exists in a family but not in the scope of a project’s output, i.e. in a schedule, is of little benefit. And the little benefit that it has gets squashed by the current implementation of schedules within Revit. Although it might be the case that information provided by a shared parameter is pulled out of the project without touching any particular schedule, I will err on the side of that being a much less frequent practice, and add that even in that situation other scheduling done within the project will still be negatively affected by unnecessary shared parameters. Let’s take a look at a couple cases in point.

I recently finished a batch of Tyler Pipe families. These were mainly floor drains, and there are two types of information that you can apparently use for drainage calculations. On the one hand you can use fixture units for the drain, and on the other hand you can use the flow rate and free area. I would imagine that whichever option is used within a company comes down to the preference of their plumbing engineers. Having all three pieces of information as shared parameters only serves to muddy the waters for everyone. The parameter(s) not being used will always appear in the dialog boxes for creating schedules. And if the family has the connector set to use the flow rate parameter rather than the fixture units one, choosing the latter for your schedule will still require editing the family to change the association (in this case to change the Flow Configuration parameter in the connector).

Below is an image from another piping manufacturer. The family has 6 parameters added to those that were originally part of the template, and all 6 have been set as shared parameters. It’s hard to see the point of this, especially since these parameters don’t seem to hold any valuable information for the plumbing engineer.

If you try to schedule any information out of your project with that family inside, you will have to see those parameters. The two images below show the Schedule Properties dialog box when trying to create a Multi-Category schedule in a project. The first shows the dialog box for an empty project, and the second for a project that includes this piping manufacturer’s family. Just one manufacturer family added to our project, and we now have 6 extra parameters to sort through, spelling mistakes included.

If manufacturers refrain from setting any parameters within their families as shared, and yet those parameters are still included with the right information in them, then all it takes is a quick edit by those adding families to a project or company library to get all of the relevant data into their corresponding schedules. The only thing for the manufacturer to decide is the name of the family parameters. And here is where looking at current lists of published shared parameters comes in. The manufacturers should try to use common names from published lists whenever possible and appropriate. It facilitates the job of turning that parameter into a shared one by the architect or engineer, and it doesn’t require learning any manufacturer-specific nomenclature.

In short, I see no benefit to manufacturers defining shared parameters in their families, whether using published lists or their own criteria, but would encourage manufacturers to look at published lists for guidance on how to name their family parameters.

Shared Parameter Standards – Part 1

Revit adoption keeps on growing. There is no denying the benefits of having an integrated project model that holds all related information. But as more and more companies move from using Revit solely for coordination to using it as a project tool encompassing all disciplines, the level of information management required from the application continues to grow as well.

At the core of this information smorgasbord are shared parameters. Shared parameters live within families, projects, and schedules. Ideally your project template already has schedules built in for use as deliverables, and your families have the right shared parameters to fill in these schedules from the moment you lay down your first wall. At the same time, content is coming from many sources: different groups or individuals within a company, product manufacturers’ websites, and third party providers (such as Andekan). Standards for shared parameters are required if project schedules are not to be incomplete at best, and erroneous at worst.

Some companies, or individuals within companies, believe the answer is to develop and use internal standards exclusively. Yet those BIM managers who claim their company’s Revit content is all created internally are doing a disservice to their employer. The task is too resource intensive, and public or third party libraries of content will grow to thousands and thousands of families over time. Ignoring the benefits of readily available content from the outside simply doesn’t make sense.

On the other hand, an industry standard for shared parameters must take into account the different disciplines within the AEC sector, as well as the industry specifics of various product manufacturers. To date, Autodesk has set the tone with their Seek team releasing an initial standard that contains shared parameters – the Revit Model Content Style Guide. The standard is limited, however, and has some incongruencies.

For example, the Seek standard has three shared parameters for fan power – Return Fan Power, Supply Fan Power and Exhaust Fan Power. I just created a centrifugal fan family for a customer that was manufacturer-specific and could be used within any of those systems, i.e. return, supply and exhaust systems. To meet the Seek standard, I would have to add three shared parameters for fan power, each with the same value reflecting the same product data.

With generic content we have the same situation. While the default content in Revit MEP 2012 shows some content split per system, it also has content that is system agnostic, e.g. Centrifugal Fan – Inline – Direct Drive, Centrifugal Fan – Inline – Belt Drive. The Seek standard tries to codify, within the shared parameter name, the system where the parameter is being used, but having to enter three shared parameters that will hold the exact same information is a waste of time, prone to errors, and, if formulas are used to keep the parameters identical, can even affect performance within a project.

Then there is the issue of deciding the proper units for shared parameters. Seek’s standard defines Supply Fan Motor Speed as a NUMBER. This parameter will accept as a value any unitless real number, measuring Revolutions Per Minute (RPM). Recently, another standard called ANZRS was published to address content standards for Australia and New Zealand. That standard doesn’t have a shared parameter named Motor Speed or anything similar, but it does have RPM_ANZRS. RPM_ANZRS, however, is defined as an INTEGER. If we are going to be meticulous from an engineering standpoint, the choice of INTEGER as the DATACATEGORY for the parameter is wrong.

Ignoring for a moment the engineering side of the issue, Revit throws a spanner in here. Let’s say you download a manufacturer’s family that follows the Seek standard. You’ve just cut a couple hours time from the process of adding such an item to your library. Now you edit the family and try to substitute its Supply Fan Motor Speed parameter with the RPM_ANZRS parameter. Revit won’t let you.

This could be handled by Revit easily enough if the parameter weren’t to be used in any other formulas within the family, but even then there is a chance that the parameter could already be in use within project schedules or calculations. And while you could argue that Revit should more gracefully handle the substitution of one unitless parameter for another, that still wouldn’t help in certain cases, say where one standard sets a given parameter as a LENGTH while another sets it as TEXT.

These examples are just the tip of the iceberg when it comes to issues with standardizing shared parameters, and my critiques are by no means meant to condemn or discount the efforts being made by Autodesk and other groups, such as the ANZRS. These initiatives are essential and progress is being made. I myself will be participating in the AEC Standards Committee a couple weeks from now, where Revit family standards and shared parameters will be discussed.

My aim here is to dig into the complexities involved in this endeavor, and to encourage an active and open discussion about the usability and long-term implications of proposed standards. Without this kind of consistent public examination and feedback, I believe we run the risk of getting ahead of ourselves and adopting standards that could prove more of a burden than a boon for Revit users. I plan to continue writing on the subject of standards in the weeks and months ahead, and in my next post I’ll look at Revit’s interface for shared parameters and how it has affected naming conventions to the detriment of long-term usability.

Using an Offset Parameter to Avoid Overlapping Plan Symbols

I’ve been wanting to write about a technique I used recently while working on some families that allows for the symbols nested in them to be moved around independently of the modeled family. I learned about the process from R. Robert Bell, who explains the problem-solution as follows:

There are times in a model where elements are placed in the same location on a wall at different elevations. Obviously this presents an issue with the BIM. The 3D model of each element needs to remain on the wall but then the plan symbols will be interfering with each other on the sheet.

In Revit it is possible to create a family that can move a plan symbol independently of the modeled parts of the family. This requires the use of a nested annotation family. This permits a length parameter to be changed to offset the plan symbol from the wall. Note that the length used must be in the annotation’s units rather than the view’s units, e.g. 3/16” rather than 18” on a 1/8” = 1’-0” view.

The elements that make up the symbol are grouped to allow a dimension to move them all together. The parameter created for the offset is set as:

[...] instance-based, grouped under Constraints, named, “Plan Symbol Offset”, discipline as Common, type as Length.

Below is a video demonstrating a quick version of the process. I recommend using this technique as a standard for any family that has plan symbols like the ones shown here, at least up until a change in Revit renders it unnecessary.

First Look at a New Standard for Food Service Equipment

Last week I found out about a standards project for foodservice equipment Revit families. Having just completed a couple food service equipment families for a customer, I thought it would be good to dig into the standard and see if I could apply it in the future. I checked out their Foodservice Industry Revit Task Force and began reading their published standard for foodservice equipment families. The standard looks like a great first step and one I hope other industry groups will follow. It builds on top of Autodesk’s Revit Model Content Style Guide available through Seek, which is a good place to start. As I reflected on the food service families I’d just delivered, however, I found a few areas that I think miss the mark when it comes to manufacturer-sponsored content. I thought I’d share those here as I think they could apply to many other industries as well.

1. Revit Architecture vs. Revit MEP

“Food Service Equipment Industry content can be created successfully in Revit Architecture or Revit MEP. In general, since some content might include System Family Types for architectural objects like Walls, it is recommended that you use Revit Architecture unless the equipment you are creating has specific needs only available in Revit MEP.”

To my knowledge, there is nothing in the Revit Architecture family editor that can’t be done in the Revit MEP family editor. Connectors are one thing that you can only do in the MEP family editor.^corr And while there are plenty of families in the Foodservice Industry that don’t need connectors, I think it makes more sense to use a broadest case standard here. Given the audience at which the standard is aimed, namely manufacturers – who have multiple products to model for their customers – and content creators – who need to model various kinds of products for different manufacturers or projects – there is bound to be a need for connectors. In fact, both of the food service families I just delivered had electrical connectors required by the customer.  So if this standard must recommend any version of the software, it should be Revit MEP.

2. Modeling Levels of Detail

“It is possible to include all three levels of detail in a single Component Family. An alternative approach is to include the Coarse and Medium detail levels in one Family for use in design development and construction document drawing sets and create a separate high detail Family for use in rendering and visualization.”

The key assumption here is that good visual detail will make a family heavy, and so you’ll gain performance by isolating that geometry in its own family. This is a misconception that leads to unnecessary work. Not to mention that it would force you to break a project model whenever you need to do a rendering. Families can be made small and perform well while still looking really nice at a fine level of detail and covering 80%, if not more, of your rendering needs. I know because that’s what we sell here at Andekan!

But more importantly, by keeping all levels of detail in the same family, you save yourself time and effort. Again, the customer who ordered the Zumex and Imbera families required the coarse geometry to match the medium geometry, which isn’t necessarily a common scenario. But if all levels of detail are already in the same family, making this happen is a matter of clicking a few checkboxes rather than moving geometry between files and keeping track of versions. Plus Revit keeps improving when it comes to performance, as do computers in general, so the outlier cases where performance actually requires separate geometry will disappear over time.

3. Coarse View Geometry

Here we’re looking at a family in coarse view and being told to use extrusions to create the 2D geometry. Instead we should be using masking regions, which require less of the application and will improve the family’s performance in this view. Extrusions in coarse views are a shortcut for the content creator, but, like any thing in software, the user doesn’t care if the programmer (or modeler in this case) has to spend an extra half-hour on the family, if that means the product is easier to use and more effective. In general, the parts of the standards document covering levels of detail could be made clearer by breaking them into 3D levels of detail and 2D levels of detail.

4. Who’s Using the Standard?

“The type and size of the project that a family is intended for use in is a critical point to consider when deciding what representations should be included in the family and what level of detail each representation should have.”

The above text appears under the “Design and Performance Considerations” section header. This section seems taken from a tutorial about the family editor intended for the general user, and it doesn’t quite fit when you take into account who this standard is meant to serve: foodservice equipment manufacturers. The above guideline makes sense from the architect’s or engineer’s point of view, because they are most concerned with their particular project requirements. For a manufacturer, however, this would mean having to rebuild families for every customer that wants to use them.

If a manufacturer sees enough consistency in their customers’ use of Revit over time — say 90% of customers only need 2D linework — perhaps then it would make sense to incorporate some of those shared project criteria into their families, but that’s not a situation that I believe should be suggested as a guideline for all manufacturers. I would suggest instead that families include all representations and views that might reasonably be required by anyone working on a project that includes their family. Again, there’s no reason this can’t be done while keeping families light and smoothly functioning. If the standard is also meant to cover the needs of architects and engineers building their own families, then having separate sections for each audience would be best.

So those are a few of the things that have stood out to me so far. There were many good things that caught my eye as well, and I encourage you to check out the project even if you don’t work with foodservice equipment families. Developing family standards is critical for Revit’s potential. Industry-level collaboration and iterative definition are definite requirements for success, and those seem to be happening with the Foodservice Industry Revit Task Force. In fact I saw today that they updated their shared parameters file and naming convention standards! So I’ll be joining in the discussion there and continue to share any key updates through our blog.

1. UPDATE 05/16/2011: Under Revit Architecture vs. Revit MEP I wrongly stated that Revit Architecture can’t create connectors. I seldom open the Revit Architecture family editor, preferring to work in the Revit MEP one, and wrongly assumed connectors were still only an option under Revit MEP. Even so, adding shared parameters with units set for MEP services, e.g. volts, still can’t be done in Revit Architecture without a substantial workaround.↩