See you at AU this year?

Autodesk University 2012 is upon us! In a little less than a week, Las Vegas will bring together some of the best Revit experts out there today. And as always, it will be a great opportunity to meet and talk with some of them, attend sessions on everything and anything to do with Revit, and generally get a chance to meet new people in the BIM space. Some of those within the #UKBIMCrew will also be attending (always a fun bunch!), and I am happy to report that Chris, David and I will all be attending this year. We will arrive a bit earlier, from the 23rd of November, to get rid of the jetlag before the sessions we have lined up begin.

As Gary said last year, a conference is ultimately about being there with the other attendees, and we look forward to having the chance to meet some of our clients, partners, and friends in person later this month. If you’re attending AU and would like to meet up or just say a quick hello, drop us a comment on this blog post, send an email to contact@andekan.com, @ us on Twitter, or just look out for these guys:

Symbols for Lighting Fixtures Showing in Plan

Back in 2010 I was asked to create a face-based lighting fixture that, when placed on a wall, would display a symbol in plan view. “No problem,” I thought, and happily set out to work on it. Little did I know that it couldn’t be done. Had I “known,” I might not have even tried. But as it turns out, it was possible after all.

The Issue

If you have a face-based lighting fixture family with a nested annotation, you will see the annotation in a project’s plan view when you place the lighting fixture in a ceiling, but not if you place it onto a wall.

It seems to be something that people would like to be able to do, yet, apparently, cannot in Revit. A quick search in Google will show that this is an old wish.

The issue lies within the chosen Revit family category. In certain family categories, a face-based family will display the option Maintain Annotation Orientation.

When checked, this option allows the nested annotation to rotate so that it shows both ways – when the family is placed vertically or horizontally, e.g. on a wall or in a ceiling. Lighting Devices, Fire Alarm Devices and Electrical Fixtures are examples of family categories that have the Maintain Annotation Orientation option. In other family categories, like Generic Models, Lighting Fixtures or Specialty Equipment, that same option isn’t available. In the latter categories, a nested annotation will display in a project’s plan view only if the family is placed on a horizontal plane, like a ceiling.

The images below show the two annotations nested within two families. The first family is set as a Lighting Device and has the option Maintain Annotation Orientation checked. The annotation then displays without a problem in plan view when the family is placed onto a wall. The second family is set as a Lighting Fixture. As such, there is no annotation orientation option.

The result is that when placed onto a wall, the annotation fails to display in plan view. The annotation will still display in plan view if we place the Lighting Fixture on a ceiling, but that’s not what we are after here.

While you could, for example, create a detail item to serve as the annotation when the family is placed on a wall, you would lose the automatic scaling afforded by a symbol created as a generic annotation.

Alternatively, you could change the Revit category in order to display the Maintain Annotation Orientation option. You could switch from Lighting Fixtures to Lighting Devices, for example, but we then lose access to other category specific features that we might require.

The Solution

The method described next works around the limitation of not having the Maintain Annotation Orientation in some Revit family categories. It allows the exit sign family shown above – faced-based light fixture – to display a symbol when viewed in plan.

In order to see the symbol in plan view, the nested annotation needs to be placed in a plane perpendicular to the plan view when the host family (Lighting Fixture) is placed in a project. And to do that, we need the nested annotation to be placed within the Lighting Fixture family as shown on the right in the image below. Unfortunately, Revit only allows for placing the nested symbol as shown on the left.

We will route around this limitation by first inserting the annotation family into another face-based family, and using this intermediary face-based family to place the annotation the way we want into the final Lighting Fixture.

The only key requirement for the intermediary family (aside from being face-based), is that it needs to be set as shared for the symbol to display in the project. With that done, now the family does what we want when placed in a project. Also note that, when placing the intermediary family into the Lighting Fixture family, you can’t see the annotation. But fear not, the force – sorry, the reference planes of the intermediary family will be there with you.

From here you can develop on top of this method to have a family that displays one symbol when hosted on a wall and another one when hosted on a ceiling (e.g. a camera), choose to allow your symbols to be tagged, and so on.

RTC and the best Revit conference you could attend

I’m back from a two-week trip to the US where I attended and presented at RTC (Revit Technology Conference) in Stone Mountain, GA. It was the second North American RTC conference, with last year’s taking place near Los Angeles. Since this was my first RTC conference I didn’t know what to expect. I was pretty much convinced to attend after hearing how good it was from people who attended last year. Then at AU 2011, Steve Stafford prodded me to submit a talk about content creation and I was all set.

I have attended most AU conferences since 2006 along with a number of other smaller conferences, and without a doubt this has been the best so far. What made it so good? Let’s see, where do I start? Focus, people, location, quality, organization, level of expertise of the speakers, duration of the conference, attention to detail, and so on. They were all interrelated.

The conference had a focus on Revit and as such it stands on its own. That didn’t mean that related third-party software and workflows weren’t part of the conference, but it meant that we were all there with a knowledge and an eagerness to talk, learn and share Revit.

The number of attendees was, in my opinion, in an ideal range (360+ people, I heard). That made it very easy to talk to almost anyone you wanted to, and to meet them a number of times throughout the conference without worrying too much about it. At AU for example, with thousands of people, you might meet someone once, and unless you have their phone number, perhaps not see them again before the event is over.

Initially I thought the location to be an odd choice. It wasn’t a known place like Las Vegas, where there are a million things to do after (and for some people during) the presentations, classes and labs. But I stand corrected. The location at Stone Mountain facilitated communication, casual encounters and enough things to do that you couldn’t finish them. The resort was a 4 star hotel, with free internet access everywhere (attention to detail) and helpful conference staff that you could meet at will, making it easy to answer questions for speakers and attendees. And the staff did an amazing job. I did a private presentation of something we’ve been working on at Andekan for some prospective clients and asked the conference staff if a room could be arranged. “When do you need it?” Sweet!

Staying with the little details for a second, during the first lunch I asked one of the waiters if they had any gluten-free food available (I have a gluten allergy). Jim Balding, from The ANT Group, one of the sponsors and organizers, happened to be right behind me. I’d never met him before. Within a moment I had the phone number of one person from the hotel staff to guarantee that I would be served gluten-free food throughout. I didn’t even have to use the number. Whenever I appeared near a food table, I would be recognized by the staff and brought a gluten-free option. Fantastic!

The quality of the attendees was also first rate. People you might only know from blogs about Revit were there, many not only attending but presenting as well. People like Marcello Sgambelluri, Jeffrey Pinheiro, Paul Aubin, David Light, Jay B Zallan, Troy Gates, Simon Whitbread and more. Autodesk also was well represented at the conference with Harlan Brumm, Scott Davis, Matt Jezyk and Armundo Darling in attendance.

The level of knowledge imparted at RTC was also much higher than at other conferences. This is in part due to it being a Revit-only conference, but I believe that, more importantly, the organization behind RTC makes an effort for it to be so. Wesley Benn, the chairman and founder of the conference, got all the speakers together on the last day to share ideas, suggestions and complaints from the speakers with the aim of using the feedback to make the conference even better next time. I heard that he also takes the feedback from attendees pretty seriously(!). And like anything, it can be improved. On one of the nights I had the chance to speak to R. Robert Bell, who also is a member of the conference committee. We talked about the high level of the talks and how the “Advanced” label had been slightly washed out by other conferences. I suggested adding a “Hardcore” level of classes. We threw ideas around: “perhaps one such class per day”, “extremely focused”, “sharing and learning among all those involved, including the speaker”. But the labelling Bob came up with gave the clearest picture: if you don’t think you could teach this class yourself, maybe it isn’t for you.

There was more to RTC than I could dare write – parties and conversations in and around the swimming pool until the late hours of the night (for some it was the morning), a boat trip to a BBQ which included beach volleyball, hearing about Jay Zallan and Troy Gates’ brilliant idea (you’ll hear more about it soon), meeting friends and their families, as well as some customers who I hadn’t met face to face yet, and more.

And for those in this side of the pond, the news are that next year the first RTC Europe will take place in Delft, Holland, in late September 2013. Don’t miss it!

On a final note, I attended the class by Don Bokmiller called “Add Some Spark: Creating Electrical Families”. In it Don commented on the drawback of wall mounted (face based) lighting fixtures not having an annotation-based plan symbol. When the Q&A time for the class came about, I raised my hand and mentioned that there was a workaround. I thought I had done this a couple years ago at the request of a customer. I was told to prove it there and then, but I couldn’t. I had forgotten how I did it. So much so that I started to doubt it could be done. I’m glad to say that after checking this in detail, I have actually done it a number of times, most recently for a project for Arup. See images below. This little nugget was mentioned by R. Robert Bell on the last day’s closing presentation where he told the audience that an explanation would soon be posted online. My next post will be a full explanation of how to go about it.

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.

A Primer on Materials in Revit 2013

We’ve recently been working on a project involving the creation of custom materials for system families. This gave us a good chance to test out the latest interface and features for materials in the newly released Revit 2013. There are a few significant additions in terms of functionality, most of which have been covered in good detail already by Daniel Stine over on AECbytes, and in broader terms by others such as David Light.

The handful of posts I’ve seen discussing materials in Revit 2013 have focused mainly on two changes from prior versions: 1) the addition of thermal properties for energy calculations/analysis (and to a lesser extent the increased structural properties, now called physical instead), and 2) the introduction of an “assets” data model for managing appearance, thermal, and physical properties. I would agree with the articles I’ve read that these changes should be seen as a welcomed expansion and streamlining of materials functionality in Revit.

A sample material from Revit 2013 with its list of assets and the thermal asset properties displayed.

To the prior two changes I would add a third significant improvement, which is that you can now store libraries of complete materials outside of projects. In prior versions, although they were called material libraries, you could only store appearance properties outside of projects. Now you can take a whole material from inside your project (called “In Document” materials), including all of its different property sets (now called “Assets”), and add it to any number of external libraries that you create. You can also add materials from one library to another. Libraries that you create are stored as standalone .adsklib files, just like the “materials” libraries (read “appearance properties”) of prior versions, so they can be ported and shared between installations with ease.

The menu for managing libraries in the material browser.

On the other hand, several posts I read also complained about the new interface for materials being a challenge. They generally highlighted that there are too many dialog windows to deal with. In my limited experience, I’d say that’s true, but only because there are other quirks to the interface that make the dialogs a bit difficult to parse. I thought I’d offer an overview of the interface and highlight some of the behaviors I found most challenging in the hope that it’s helpful to others trying to get their arms around materials in 2013.

Material Browser
This is the first dialog window that appears when you click the Materials button on the Manage tab of the ribbon menu. The top half of the Material Browser shows you all of the materials you currently have in your project or family (called “In Document” materials). The bottom half has two panes. The left pane shows a list of external libraries you have available for bringing materials in and out of your project/family. The right pane shows the list of materials available in whichever library is currently selected. At the very bottom of the Material Browser window are three buttons. From left to right, the first button lets you open/create/edit libraries, the second lets you create a new material from scratch, and the third, on the far right, will open the Material Editor.

The Material Browser is the first window you'll see when clicking the Materials button on the ribbon in Revit 2013. Note that the first time you click the Materials button, Revit will automatically open the Material Editor window as well.

Material Editor
This is the second-level dialog window that will appear if you click the button in the bottom right of the Material Browser, or if you click the edit button (i.e. pencil icon) on any “In Document” material (note that you can only edit materials that are in your project or family, more on this later). In the Material Editor, you can change a material’s identity information or modify the properties of any of its assets. From here you can also launch the Asset Browser, which is where you can replace a material’s existing assets with totally different ones (as opposed to simply modifying the existing ones). The Material Editor also has a spherical icon that you can click to duplicate the selected material or create an entirely new one.

See the first image at the top of the post for an example of the Material Editor window.

Asset Browser
This is a third-level dialog (and to be fair, that’s as deep as the dialogs go) that you access from the Material Editor. You can launch the Asset Browser either by clicking the window icon at the bottom of the Material Editor or by clicking the swap button on a material’s existing asset in the Material Editor. In the Asset Browser, you can swap assets in and out of the currently selected material, as well as move assets between your project/family and any external libraries you have available.

The asset browser window in Revit 2013, with the two buttons to access the browser highlighted in red.

Libraries
These are groups of materials and/or assets that exist outside of any particular project or family. They are saved as standalone .adsklib files, and it’s important to note that a single library can contain both materials and assets. This makes perfect sense: if materials are made up of different assets, then a “materials” library must somehow contain appearance, physical, and thermal assets as well. It wouldn’t make much sense if Revit forced users to hold a material’s identity info and graphics properties in one library file and all its related assets in another (technically graphics are also an asset, but those properties are specific to each material and can’t be moved between materials or libraries). So if your library contains a material, then by definition it will contain at least one appearance asset as well (physical and thermal are optional in a project). But if you want to take just an individual asset and place it in a library, you can do that as well without bringing along the container material or that material’s other assets.

With that framework in mind, here are some of the detailed behaviors that might trip you up when working with the new materials and assets interface in Revit 2013:

1. When you open or create a new library from within the materials browser, that library doesn’t automatically show up within the asset browser. You have to manually add your libraries in the asset browser as well.

Adding a library in the material browser does not automatically add it in the asset browser. Note how ‘Custom Library 2′ already appears in the material browser but still has to be added in the asset browser.

2. The name of a library within the interface is not inherently connected to the name of the .adsklib file that stores the library. Revit automatically gives them the same name when you first create the library, but after that you can “rename” the library to anything you want within the interface, and the .adsklib file’s name won’t be changed to match the new name. You can even name the library of an .adsklib file one thing in the material browser, and something else in the asset browser. If you ever have a doubt about which .adsklib file a library is pointing to, you can always hover your mouse over the library name and see a tooltip with the .adsklib file name and location.

The .adsklib file "Madonna’s Library" has been named "Material Girl Library" in the material browser and "Material Boy Library" in the asset browser. Both libraries point to the same file shown in the tooltip.

3. Within a project, Revit won’t let you remove a material’s appearance asset (you can only modify it or replace it with another appearance asset). But Revit will let you delete appearance assets in a library (even if they are used by materials in that library). Revit will also let you take an appearance-less material from a library and add it into a project. So while you can’t delete an appearance asset from inside the project, Revit gives you a workaround via libraries to achieve the same result.

4. Changing an asset’s properties within one material will change that asset’s properties in any other material that uses the asset. This makes sense if you understand that assets are meant to be shared between materials (which does follow how property sets worked in prior versions, so it’s not exactly a new concept). But for new users this could be a painful discovery to make, and there is no way to tell which assets are shared and which aren’t. Tread carefully when modifying your assets!

5. You can only edit materials and assets that are inside of a project. In a library, you are limited to viewing the names of materials and assets, and to performing basic functions like Rename or Delete. If you want to edit a material or asset that’s in one of your libraries, you have to: 1) bring it into a project, 2) make your edits, then 3) add it back into the library to overwrite the original version, and finally 4) remove the copy that’s inside the project (if you don’t want it there).

Materials or assets in a library cannot be viewed or edited (except for renaming or deleting).

6. You can’t open the asset browser unless you open a project material in the material editor. Once you have the asset browser open, you can close the material editor and keep the asset browser open, though in modal form only.

7. Revit 2013 comes with two default material libraries –Autodesk Materials and AEC Materials– but it’s not clear what the difference is between the two. Some materials are in one and not in the other. Some materials are in both but just spelled differently. Overall there is a great deal of overlap between the libraries. Also, the default asset library called “Autodesk Physical Assets” has some appearance and thermal assets in it as well.

The Fabric sections of the Autodesk Materials library and the AEC Materials library. Note the list of materials and how they are spelled differently in each library.

The updated data model for materials in Revit 2013 adds key functionality and gives you lots of flexibility for managing materials in your projects, but it does require some time and experimentation to get comfortable with the interface. I hope this post provides some useful guidance for those looking to make the transition.

Nested Families and the Case of Disappearing Connectors

When a family with connectors is nested into another family, the connectors get ‘lost’ in the host family. They have to be recreated in the host to appear in a project. This is the case even if you are nesting a shared family. This behaviour is akin to a project being linked into another one, where the connectors from the linked project won’t be available to the host project.

To give an example, let’s imagine there is a host family classified as specialty equipment. Within the specialty equipment family we have a sink that we created as its own family, set as a shared plumbing fixture, and then nested into the host family. The sink of course has plumbing connectors, but these won’t show up in our project because they are within a nested family. The first thing that comes to mind is to add a new set of connectors to the host family and use those instead, as shown in the image below.

This solves the immediate connector problem, but can create other problems depending on how you use schedules and systems in Revit. As a shared plumbing fixture family, the sink will appear in the project’s plumbing fixture schedule, and through the schedule you can update the FU (fixture units) values within the sink’s connectors, as shown in the image below.

Unfortunately the sink’s connectors aren’t actually active in the project; only the connectors in the specialty equipment host family are. When you select the specialty equipment family, you see the FU values for the connectors that you recreated in the specialty equipment family, not the ones of the nested plumbing fixture. And if you want to create a system, you will be connecting to the connectors in the specialty equipment family as well. At the very least there is strong potential for confusion and a disconnect (pun intended) between schedules and systems.

Another way to solve the problem would be to nest the specialty equipment family within the plumbing fixture. The issues with this approach are too many to cover here so I’ll leave that as an exercise for those interested.

A third approach could be to create a multi-category schedule and then have shared parameters that, for example, drive the diameters of the connectors in both the host and nested families. This schedule could list the plumbing fixture and specialty equipment families so you could manually make their diameter values match. There’s just one hitch. A plumbing fixture has built-in parameters for CWFU, HWFU, WFU (Chilled Water Fixture Units, Hot Water Fixture Units and Waste Fixture Units respectively). These parameters won’t appear on a multi-category schedule, and there is no way you can turn them into shared parameters (a trick I previously wrote about doesn’t work in this case).

As with almost anything, there is a workaround for this third approach that involves creating new shared parameters, but it isn’t worth discussing as it’s more work than it’s worth.

Then there is the right approach, which I nearly forgot about thinking of all the potential workarounds with nesting. Currently the right approach is to not nest families with connectors at all, but instead to create a group. The whole thing still comes up small (for delivery or storage purposes) and gives you the best results (when you bring the group into a project you will get two families, classified independently – file size increase being irrelevant as the extra weight will be shed on loading the group into a project). It’s also what Revit wants, currently.

Sink: 288K
Casework: 584K
Specialty equipment (all as one family and no nesting): 636K
Specialty equipment (nested sink): 716K
Group (casework and sink): 972K

When I say “currently” above, I mean from the point of view of systems within Revit and how they are best approached. The ability to nest families has to-date ignored the needs of families with connectors, or MEP families in general. The same issue applies at the project level. Allowing connectors to be seen when nested would have been great in so many of our family creation projects I don’t even want to count them. The fix would likely come hand in hand with connectors showing through linked files. The latter would solve workflow issues encountered in large projects on the mechanical side, where for performance reasons you might need to split up the project. In short, I would say the best future solution to lost connectors in nested families would be to never lose them in the first place. But for that, we’ll need a new version of Revit.

System Parameters Vegas Style – Type or Instance?

Since both Gary and I are here in Las Vegas at Autodesk University, I thought a post with a little bit of “now you see it, now you don’t” magic would be appropriate.

In an Electrical Equipment family there is a system parameter for Voltage. As a system parameter it cannot be modified in any way—when the parameter is selected, the “Modify…” button is greyed out. It’s set as a type parameter, but let’s say I need it to be an instance parameter in a particular situation. You can tell type and instance parameters apart in a Family Types dialog box by looking for the “(default)” text that follows all instance parameters.

This is where the magic comes in. Pay attention to the trick or you might miss it. Now you see it as a type…

And now you don’t!

There are many things you can do in Revit that are not standard. Last night I was talking with Steve Stafford here at AU and discussing with him how some of these non-standard ways to achieve a result are too much of a hack to rely on (e.g. having connectors appear and disappear at will — oh yes, you can do that!). Then there are others, like the one being shown here, that I feel more comfortable using when creating families. They are workarounds more than hacks, and as such I give them a longer shelf life.

I was doing some consulting in Kuwait a little over a year ago when I was asked about doing just this kind of workaround in a family, where the best workflow would be achieved by having the Voltage parameter as an instance rather than a type. I managed to pull it off as I was complaining to Gary Ross (then at Autodesk) about this particular limitation. I found it more of a user interface limitation rather than an intended feature of Revit.

So how do you do this trick? Luckily you don’t have to be a magician. Open your Revit Electrical Equipment family, with your Voltage parameter set to type. Make sure you initialize the parameter with some value if none is there. Change the family’s category to something else, where Voltage is not a system parameter, for example Electrical Devices. Now your Voltage parameter is no longer a system parameter, so you can change it from being a type parameter to a system parameter. Once this is done, set the family category back to Electrical Equipment and you are done!

There are a few more things regarding this workaround that I’ll write about in a follow up post. In the meantime, I hope you find this little trick to be of use, and if you are at AU and would like to have a chat or meet for a drink, drop me a line.

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.