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.

The Revit.ini File In UserDataCache Gets Overwritten

There have been quite a few reports about Revit 2015's Revit.ini file in UserDataCache getting overwritten with a bad 0-byte sized file. I know this because some of our installations are experiencing this issue and I've had to research what is going on. To no avail.

The symptoms are easy to spot, the cause, not so much. The most visible symptom is that you launch Revit 2015 and Revit quickly displays a dialog box that the path you have specified for the default family template files is invalid. You ask yourself, "How? It was ok yesterday (or earlier the same day)." When you start looking at your file locations under Options you will note that your template locations are probably wiped out and Places has been reset to the out of the box (OOTB) defaults.

As you start poking around, trying to figure out what is going on, you will eventually discover that the Revit.ini file in the UserDataCache folder is 0-bytes in size (it is empty) and that the encoding is ANSI and not Unicode as Revit requires. You can determine the encoding of a text-based file in Notepad by starting a SaveAs and looking at the lower part of the Save As dialog box. For those of you that wonder where the UserDataCache folder is located, simply type the following into Windows Explorer's address bar:
%AllUsersProfile%\Autodesk\RVT 2015

While you now know what's wrong, you still have no idea why it happened. And that's where the research on the Internet gets frustrating.

Some claim it is due to a security rights issue. That can't be correct for several reasons:

1. The file was good for days/weeks/months.
2. The file was overwritten, so you had to have write rights for that to happen.
3. If you check effective permissions on the file you will see that even normal users have full rights.

The next claim is that it is related to modifying a deployment. This seemed like the most like reason to me. After all, I wasn't seeing this issue on some of my early deployments but I was on more recent deployments. However, it was a red herring. The issue eventually occurred on my own laptop (thankfully! see below) and that laptop did not get deployed using normal deployments because I'm, well, special.

Another idea was that it was related to running Autodesk uninstalls on the workstation. This is not the case for most of my workstations experiencing the issue since they were new installs.

This left me scratching my head for over a month and a half. Until it finally happened on my own laptop. I was now able to remove the user from the equation. I knew that Revit 2015 was last ok a few days ago and this was the first time running Revit 2015 since it last worked. So I was able to dive into Windows Event Viewer and try to piece together what happened.

I had the timestamp of the bad Revit.ini file which gave me a target for looking in the event logs. And sure enough, there was something curious in the event logs at that time.

The Revit.ini file timestamp coincided with 4 events in the log. The entry I found really interesting was the one I have selected in the image below... Revit was reconfigured. Why was Revit reconfigured? And I remembered from that day that Revit had indeed displayed a dialog box in the afternoon that it was installing something. Of course, Revit didn't tell me what feature was getting installed. But the event log does!

Note the 4 log entries just before when Revit reconfigured itself. There are a couple of warnings there. I've selected one of the warnings. See what feature is having the issue? Autodesk's own Revit Extensions (REX)!

Subsequent examinations of my other workstations exhibiting this issue revealed that within the timeframe of a user reporting the Revit.ini issue that there was always corresponding warnings about REX in the event log. In all cases but my own laptop, there were multiple pairs of warnings and all those workstations have experienced multiple cases of the Revit.ini file being overwritten with a blank file with the wrong encoding.

Note that the missing component GUID in my screenshot, {56B6EA8C-235B-4FCF-9BC8-54FC0720AFB8}, cannot be located in my registry so I will continue to randomly experience this issue until I uninstall REX. The product GUID is Revit's own GUID and is ok.

My recommendation is to not deploy Autodesk's Revit Extensions until the issue is resolved by Autodesk. The reason for this recommendation is because if you have deployed Revit with REX deployed too, you will need to uninstall REX and then uninstall/reinstall Revit without REX in the deployment in order to correct the issue. It is best to not deploy REX unless you absolutely need it.

Cut Plane in Family Templates

This came as news to me, but there is a cut plane in Autodesk® Revit® family templates that can affect visibility while in the family editor. Here is the situation where I discovered this:

I am a fan of creating reference planes in families to drive the geometry. But I also usually adjust the length of the planes to extend only a short distance past the relevant dimension. I cannot recall this being an issue until today while working on a new family using the Generic Model template.

This family is for an IT cabinet with a top-mounted exhaust duct connection. The cabinet is over 7' 6" tall and the hard connection for the duct sits on top of the cabinet. So I drew my duct connection reference planes in the Ref. Level view. As you can see, I shortened them up so they only extend a short distance past each other.

I then switched to the Front view and shortened up the reference planes there too.

When I switched back to the Ref. Level view, the reference planes and their dimensions were gone! I knew that I had not deleted them and nothing was temporarily hidden. When I switched to the Ref. Level ceiling plan view the reference planes and their dimensions were showing.

I immediately thought, "Hmm, seems like a view range issue," but, of course, there are no view properties in the Properties Palette while nothing is selected in the family editor, unlike the normal editor. The Properties Palette displays the properties of the family when nothing is selected. Was I stuck? Would I have to extend the reference planes down below 4' 0"? (Which did work, by the way.)

 

Happily, I did find that the Properties Palette will display the view properties when you select the view in the Project Browser while in the family editor. I adjusted the clip plane to 7' 4" and, poof!, the reference planes and their dimensions reappeared in the Ref. Level plan view.

 

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.

Scope Boxes Visibility

I'm a big fan of Autodesk® Revit® scope boxes. I'm also a big fan of Quality Control (QC) views. And therein lies a bit of a rub.

I advocate that a model should have a group of views where each view is dedicated to doing a QC on a specific feature. For example, set up a view that is dedicated to making sure that the grids in the model are in the Shared Levels and Grids workset. The only elements the view displays are the grids that are not in the correct workset. If the view is blank, then the model passes that particular QC item.

I create a QC view to do the same thing for scope boxes. I place those in Shared Levels and Grids too because other firms that link in our model don't need to see our scope boxes, right? So why not put them in the workset that everyone turns off already to get rid of the levels and grids in the linked model?

Now here is the tricky part:

I usually turn off all model categories and all annotation categories except the desired category. However, when I did that, no scope boxes were visible! They were there. I could hover over one with my cursor and select it. But I could not see them. I double-checked visibility settings. I made sure that the scope boxes themselves were set to be visible in that view. No joy.

I then turned on the model categories and, to my surprise, the scope boxes immediately became visible. I thought that the display must somehow be tied to the Generic Models or Lines category but when I isolated to just those categories the scope boxes still disappeared. So I laboriously went thru all the categories, turning them off in small batches, to try to isolate the relevant category.

And it turned out to be something else entirely. As usual. It seems that scope boxes won't be visible unless there are model elements also visible. You see (groan), there were no elements in Generic Models or Lines and that's why the scope boxes disappeared. When I turned on the Electrical Equipment category, or any other single model category that had elements, the scope boxes became visible.

This is a bit unsatisfying because I can't make the QC view blank when everything is ok with the scope boxes. I did change the color and half-tone the Electrical Equipment category, but I'm worried someone will try to "fix" those elements too. Time will tell!

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.

Filter a Revit Schedule for Whole Values

I saw an interesting question asked in the BIM + Revit MEP LinkedIn group the other day. The question was if it was possible to use wildcards in a schedule's filters (nope). But the real question was: would it be possible to filter a schedule so that it only displays values that are not whole numbers (integers).

It would be wonderful if I could provide an example using Autodesk® Revit® MEP's Elevation parameter, but alas, that built-in parameter is still not available for tagging or schedules.

However, here is the approach I used with a shared parameter used to report elevation. I am using three calculated values. I could get by with just one, but I like the idea of having one value to convert the elevation to a real number and one value to calculate the whole number, for QC purposes, and the third value to provide the actual filtering.

 

Here are the fields that I used:

1. Sparling Mounting Height: Shared parameter, Length, that reports the elevation of the element. How I wish I could use Elevation here!
2. Elevation As Number (can be hidden): Calculated value, Number, using this formula: (Sparling Mounting Height / 0' 1")
3. Whole Value (can be hidden): Calculated value, Number, using this formula: round(Elevation As Number)
4. Is Whole (can be hidden): Calculated value, Yes/No, using this formula: Elevation As Number = Whole Value 

Note that the Round function does not work with lengths so it is neccessary to normalize the value from Sparling Mounting Height: (Sparling Mounting Height / 0' 1")

Update: Bruce Johnson pointed out that I could normalize using inches rather than feet and Revit converts the value correctly.

Because lengths are stored in Revit as decimal feet, the normalized value needs to be converted to inches before it is rounded: (Sparling Mounting Height / 1') * 12)

I round the calculated value of the elevation, in inches, normalized to a number to be used to test if the original value was a whole number.

Finally, we do the actual test to provide a Yes/No result that can be used to filter the schedule.

I also wish that I could resize the Calculated Value dialog so that it would be easier to document my schedules. However, I have no fix for that, other than adding it to the AUGI wishlist.

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.

Revit Element IDs, Really?

Autodesk® Revit® has a useful function under the Manage tab to list the element IDs of your current selection. It does a nice job of handling multiple selections and allows you to copy-and-paste the IDs.

That's the good news.

The half-baked part? Look what the corresponding dialog to select by element ID says to use to separate multiple object IDs.

Yes, that's right, this dialog says it wants semi-colons (;) and not the commas (,) given by the Element IDs of Selection dialog.

Happily, there is a solution! Just ignore the lying text and use commas anyway. The dialog honors both semi-colons and commas for multiple IDs. See! I did provide a solution!

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.