Revit Room Separation Lines Messing With MEP Spaces

I came across this post by Steve Stafford while researching a few things related to the Autodesk® Revit® Space element. The post described an issue where the architect wanted to divide a large room into smaller areas for very legitimate reasons. The architect used room separation lines to do this division. The problem was that the MEP engineer still needed a single space element for the very legitimate reason of MEP calculations.

Two competing legitimate reasons. What to do?

Let the Ideas Flow!

• Put the room separation lines in a workset and close that workset? 
• Nope, that doesn't work.
• Do some kind of level offset to get the space element "above" the room separation lines? 
• I wouldn't want to manage that model, would you?
• Use phases for the room separation lines and the sub-rooms? Since rooms are only visible in the phase they are created, that would work. 
• Oh wait, how would the architect actually produce the documentation of the sub-rooms then? I'm going to say this is a no-go too.
• Have the architect add space separators instead of room separators? 
• No, that just breaks the MEP's spaces too.
• Aaron Maller probably has the best answer of all: use design options for the room separation lines and sub-rooms. Since MEP folks hate design options, this is doable. 
• The architect would need to produce the documentation from the non-primary design option. What I like about this approach is that it doesn't require any hacks. It is using basic Revit features. But it could be complicated from a documentation perspective, e.g. room schedules.

There is one other approach that works if Aaron's superior design options approach won't work. For example, there are already design options in those areas that make it difficult to use Aaron's approach.

Use an Overlaid Linked Model

The other possibility is to place the room separation lines in a separate model! The architect can then link in that separate model as an overlay and mark it as room bounding. The architect is then then place the sub-rooms in their original model. The image below is pointing to the room separation lines that are in the overlaid linked model. The room elements are in the host model.

The MEP engineer, when they link in the architectural model, will only "see" one bound room when they place the space object. This is because the room separation lines in the architect's overlaid linked model are not loaded in the MEP model.

A few things to note with the linked room separation line model approach: 

• The room element used/reported by the space element depends on the location of the space's reference crosshairs. The examples below are the same space with only the reference crosshairs in different locations. (The space tag is reporting the room number/name.) Note that the reported room number is different even though the space boundary is the same.

• A room schedule of the rooms of the architect's linked model will show all 3 rooms. But a space schedule will only report one of the three rooms. This may make it difficult to match the number of rooms to spaces and room/space areas.

Aaron's approach would show only the room from the primary design option which does make such matching easier.

Ultimately, you have two choices. I would recommend Aaron's approach unless you foresee conflicting issues with design options. If Aaron's approach cannot work, at least you now have a good alternative.

Autodesk, the Autodesk logo, AutoCAD, Navisworks, and Revit are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries.

Maintain Annotation Orientation on Revit Lighting Fixtures and Electrical Equipment

For reasons that are still unknown to me, Revit does not allow, to date, the use of the setting "Maintain Annotation Orientation" on two family categories: lighting fixtures and electrical equipment.



This is particularly painful for the electrical discipline because so much of the documentation on plans is symbolic. Perhaps the thought process was that since light fixtures and electrical equipment is usually more than 6 inches in size that the use of nested annotation symbols wasn't necessary.

Or maybe the programmers just didn't catch that those two family categories acted differently and haven't heard the howls of complaint from the industry?

The Usual Approaches

Regardless of the reasons, it has left the MEP industry in a state where workarounds are needed in order to properly annotate plans. I'm talking about true annotation symbols and not just using symbolic lines in the model family. Symbolic lines won't scale automatically based on the scale of the view. For example, you cannot do what is shown below on that single instance of the family just using symbolic lines.



In order to show that wall mounted light sconce symbol on plans you have the following workarounds:

1. Just place annotation families and not model families
2. Forget using the lighting fixture category and use lighting devices instead
3. Use a shared intermediate nested face-based family to orient the nested annotation family as described by Jose Fandos

Opinions on option 1: Why are you drafting in Revit? You might as well do the project in AutoCAD. Oh, and try to circuit those annotation families...

Opinions on option 2: Seems like a simple solution, until you consider the "I" in BIM. Good luck getting your lighting fixture schedule to work correctly. Or getting renderings using the photometrics for those wall sconces. Or isolating the lighting fixtures on the project.

Opinions on option 3: This approach works. You will have to filter out the shared intermediate family to avoid seeing it in your schedules which is easy enough. However, I've also seen plenty of cases where the intermediate family is considered by Revit to be not hosted to a face and therefore showing in the Reconcile Hosting dialog. I've found that this approach confuses my designers when hosting goes wrong.



Another issue is that the intermediate family instance in the host family is not visible in the family editor so family maintenance by someone other than the family author can be tricky.

Yet Another Approach

I recently read a post by Brian Mackey about creating a vertical face-based family template. The approach is that you create a family template started from a wall-based family template and convert it to face-based using Batch Copy/Monitor. The reason that Brian did this was so that the orientation of the hosting face in the family editor look like a wall. After I read the post I wondered what would happen if I placed a nested annotation family in a family created by that new template.

I was pleased to see that nested annotation families are visible! And without the need to use a shared intermediate family. "And there was much rejoicing."

Now, before you go crazy and start using this approach, I do need to caution you that when you use the process described by Brian, your resulting families will lose the use of the Default Elevation parameter. You will still be able to use the Elevation parameter to change the elevation of the element, but you cannot assign a default elevation. Sadly, the Default Elevation parameter is listed in the element's instance properties so this could potentially confuse your designers.



You will have to decide if the loss of the assignment of a default elevation is worth the direct use of a nested annotation family in your lighting fixtures and electrical equipment.

Conclusion

The majority of my wall-based lighting fixture and electrical equipment families that need annotation symbols currently use Jose's approach. However, the reconcile hosting issue is severe enough that I will be going back through those families and converting them to a template based on Brian's approach, despite the default elevation issue.

I will finally have direct nested annotation families in my lighting fixtures and electrical equipment even without the Maintain Annotation Orientation parameter.

Autodesk, the Autodesk logo, AutoCAD, Navisworks, and Revit are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries.