Underlay Visibility Issue in Linked Models

NOTE: This is a re-post from the HOK BIM Solutions blog. Sorry it’s a bit late, playing catch-up!

It appears that this problem has been around since Revit 2011 but I have not personally come across it until a few weeks ago. We frequently separate Furniture and Furniture Systems into their own models on certain projects to improve on model performance and general working efficiency. Recently one team member noticed that underlay behavior differed when these element categories were in a linked model vs. in the host. This issue could potentially affect other categories but we have not attempted to confirm.

When laying out lighting in a Reflected Ceiling Plan view, designers need to reference Furniture and Furniture Systems by overlaying them. When this geometry is in the host model (in the same model as the ceiling), the user simply sets the Underlay option in the view’s property and carries on with their work as shown below:

If furniture and furniture systems are brought into a view through a linked model, things get unnecessarily complicated and the Underlay option no longer works:

If link visibility is set to By Linked view and the source view has the Underlay option enabled, the underlay elements still do not show. The current workaround is to:

a) lower the cut plane temporarily so it crosses the geometry in the linked model;

b) set up a source Reflected Ceiling Plan view in the host model with a low cut plane (ex: at the floor level and only enable Furniture and Furniture Systems). Now set the visibility of the linked model to By Linked view and use this source view.

I think we can all agree that this is something that needs to be addressed sooner rather than later (confirmed to still be a problem in Revit 2015 Update Release 4).

Underlay Visibility Issue in Linked Models

Upgrading Models and update to Revit Make Local

It is that time of the year when users start transitioning projects to the newer version of Revit. The first service pack was released this week and most now feel comfortable making the transition.

I am always amazed at how many out there still use the Revit Make Local utility I created years ago, which was last updated in April 2010. I’ve received numerous comments and emails over the last years requesting an update. I have even had a few come to me last week at RTC in Vancouver to thank me and asked nicely when I was going to update it to work with Revit 2014! So I finally cracked down under the pressure and spent some time brushing up on AutoHotkey again (I need to build some scripts at work anyway) and made the necessary changes. You can download the latest Revit Make Local V5.1 and try it out. Please note that I have only tested in 2013 and 2014 OneBox, but it should work on stand-alone and past versions as well. It is becoming a royal nightmare to support all versions of Revit because there are so many variations between them (varying journal file and executable paths, different journal contents, the arrival of OneBox, and now also the obsolete Programs folder in 2014!). So this might truly be the last update, but if it does require more work in the future and I decide to indulge, I will drop parts of the script that support older versions to simplify things.

This brings me to the real intent of this post. Why do users still like this utility instead of the built-in local file functionality? Because besides the fact that local files do not go into their dedicated folders, there is absolutely no safeguard from accidental upgrading. It is astonishing to me that we still don’t have anything built-in to address this issue. The current upgrade dialog is only displayed after upgrading starts and does not present us with the opportunity to cancel, not even the “X” button at the top-right corner.

There are possible hacks to find which Revit version and flavor was last used to save the file (this avoids the use of a naming convention as required for the Revit Make Local utility), but there is nothing visible to the user in the operating system that displays the file version. You have to open the file in Revit to find out.

Revit is typically very verbose. It issues plenty of warnings and dialog boxes to keep users informed and usually even demands their input. However when it matters most, it doesn’t even pause and ask for user feedback. We really need to be consulted when an older file is about to be upgraded so we can take a decision and not just inform us after the fact!

The upgrade process is a massive painful exercise when you have a ton of linked files, especially if you forget to close the appropriate linked file worksets (I just close all of them when upgrading). I think we need a dialog like this that provides the following options:

Note: The above mock-up was created with Pencil.

What do you think? If you agree, I encourage you to send feedback to Autodesk directly and reference this post.

Upgrading Models and update to Revit Make Local

Positioning of Linked Models – Part 1

NOTE: This is a re-post from the HOK BIM Solutions blog

Much has been said about this topic and it continues to be a source of confusion for users of all levels.

When linking models, unless Shared Coordinates have been properly set up between them all, you cannot position them using this method. It seems to be a common myth that linking models by shared coordinates will “just work” and they will land where expected. Think about it: if you never told Revit how various models relate to each other (distance and rotation), how is the software supposed to just know?

First off, let’s get the terminology straight and lay out some facts.

Fact #1

Every CAD software uses Cartesian Coordinates to locate objects in digital space. You start with a fixed Origin (0,0,0) and three Axes (X,Y & Z). In traditional 2D CAD packages, the Origin and Axes are exposed to the user through visual means, whilst in Revit they are not as “in your face”, but make no mistake: they are still there! This fixed system is essential to position elements in space such as points, lines, planes, surfaces and solids.

To find the fixed Origin in a Revit project, you can either use the older, harder way (link a CAD file that contains some linework drawn at 0,0,0 with Auto – Origin to Origin) or the easier, newer way: Use an unclipped Project Base Point and pick Move to Startup Location in the right-click context menu.

Just in case you forgot how to turn this on, see the image on the left (V/G dialog; make sure at least Architecture is selected in the filter list).

NOTE: In AutoCad, the fixed Origin and Axes are called the World Coordinate System. In Revit we refer to them as the Project Internal Coordinate System.

Fact #2

When you link with the Auto – Origin to Origin option, the Project Internal Coordinate System of the linked models will be aligned to that of the host model. So if at project startup reference models were linked haphazardly (ex: with Auto – Center to Center or arbitrarily shifted around after linking), you are guaranteed to end up with incorrectly positioned models. To circumvent this problem, we can set up Shared Coordinates in each model, share them through “acquiring” or “publishing” tools, and then link with this option. Note that a successful outcome doesn’t happen auto-magically on its own!

Fact #3

In most CAD software, you will find the concept of a User Coordinate System (UCS), which is another Cartesian Coordinate System similar to the World Coordinate System (WCS). A user can define any number of named UCSs and these are positioned in space relative to the WCS. Now you can probably understand why the WCS is fixed since you must have an anchor point in 3D space for relative positioning to work.

When we talk about Shared Coordinates in Revit, we are talking about their equivalent counterpart in 2D CAD: User Coordinate systems. We can define multiple named systems in the Site tab of the Location Weather and Site dialog. Named Shared Coordinate systems (Sites) are located relative to the Project Internal Coordinate System. In Plan views, Project North is defined by the Y-axis of the Project Internal Coordinate System, while True North is defined by the Y-axis of the Shared Coordinate System (the named “Site” per the dialog below):

When you link with the Auto – By Shared Coordinates option, the Shared Coordinate system of the linked models (for the current named “Site”) will be aligned to the Shared Coordinate system of the current named “Site” in the host model, given that Shared Coordinates have been properly set up between models. If you try to link models that have yet to be synchronized (by publishing or acquiring Shared Coordinates), Revit will not allow you to use this option:

Revit has always strived to describe functionality using terms that are familiar to the building industry, but I think that the ones used while manipulating coordinate systems do not work well for most common model linking scenarios. Since terminology is so different from that used in generic CAD programs, it makes things harder to visualize and understand sometimes, especially for users that started in 2D CAD. The main problem with named UCSs in Revit being called “Sites” is that if a consultant is linking parts of a building to parts of the same or another building, they probably do not think of “Sites” for this exercise!

The primary reason for the current implementation is to give us the ability to place multiple instances of the same building around a site (ex: the same home floor plan peppered around a housing development). For most typical project workflows, we just need one “site” definition for the purpose of locating links in 3D space and usually don’t even bother changing the stock site name “Internal” to something else.

In Part 2 of this post, we will look in more detail at some of the most common linking scenarios and discuss strategies to set up Shared Coordinates and linking Best Practices.

Positioning of Linked Models – Part 1

Opening Linked Models for Editing

NOTE: This is a re-post from the HOK BIM Solutions blog

One of Revit’s annoyances is the inability to open a linked model for editing and keeping it loaded in the host project, all at the same time. This leads users to believe they need additional sessions of Revit in order to refer to the fully aggregated model and edit the link/s at the same. Doing so causes various problems, such as reducing available RAM consumed by the additional sessions (0.35 to 0.4GB/session observed) and the potential to run out of network licenses for other users.

Revit’s UI gives us the option to open a link but at the same time, forces us to unload it. Somehow Revit seems incapable of having the same file in memory (based on filename) both as a link and opened independently in the same session. To make matters worse, most of our linked models are workshared, so opening a link in the way shown above is highly discouraged as you would be directly opening the central file. Revit does have safeguards for situations like this and does not let you directly do a Sync with Central if another user has synced since you opened the central file. Regardless, the current workflow of dealing with linked models is highly problematic and not sufficiently well-developed by the Factory.

Luckily we can work around the current limitations when the linked files needed for editing are workshared. We can in fact achieve this in the same session without unloading or requiring the user to open a separate Revit session by following these simple steps:

1. Make sure to not use the right-click option shown above (obviously!)

2. Navigate to the original linked central file and open through Revit’s Open dialog in the same session. If it is a valid Central File, Revit will automatically create a Local File by appending your username to it and happily open it for editing.

3. Alternatively, use the Revit Launcher (an HOK custom tool) to create a Local File for the linked model in question and open as usual.

NOTE: If the link to be edited is not workshared, you are out of luck and need to open it in a separate session if it is important to you to keep it loaded in the aggregated model.

Commentary

There is no doubt that this functionality needs to be polished further. The current implementation might be a reflection of various technical reasons/limitations, but should not be a reason to leave things in their current state. Here are some thoughts:

• Revit should be capable of opening non-workshared links directly and leave them loaded in the aggregated (host) model.
• If the link is workshared, Revit should recognize this and serve a UI that offers the same options when selecting a workshared file in the Open dialog so we can 1) open a detached copy, 2) create and open a local file so we can make changes and sync them with central (default), and 3) offer the option to open the central file directly.
• Give users the ability to edit a link in-context (in-place), whether it is workshared or not. This is not necessary functionality, but would be very nice to have.

Opening Linked Models for Editing

Securing Linked Files

These days I start blog posts by researching my own past writings and select others, to see if everything has been covered about the topic at hand. I guess it’s the sign of the times: BIM in our daily work is no longer solely concerned about Revit and there is so much information to manage and deal with. Since we are unable to upgrade our neurological hardware & software, I have to do this, else I risk excessive repetition! This will be a follow-up to Securing Links Through Worksets (see comments as well).

Steve Stafford also wrote about this topic indirectly at the start of the month. Since we use Shared Coordinates from time to time, securing linked files against accidental movement is very important, although deletion tends to be the worst since views/templates are so heavily modified (not using <By Host View> everywhere). Accidental deletion will undoubtedly result in wasted work and frustration, so anything one can do to avoid it is always welcome.

As stated in my original post, worksets are not an option when Monitoring is required. Since we’re using this on pretty much every project, I no longer suggest this technique. Luckily, there’s a simpler, more robust Option (unintended pun). This technique was mentioned in a comment in the above post, but I never got around to write about it until now.

Design Options are the best answer I have been able to find. The checkbox on the status bar shown below is at the heart of it all:

Revit automatically checks this option whenever you click the Modify button (or after completely escaping a command). This is great, because you’re not at the mercy of every user remembering to switch it on. With this enabled, anything displayed in your view that is contained in a Design Option is not selectable. So it’s there but you cannot pick it, hence it cannot be accidentally moved or deleted. The great thing though is that if you want to use copy/monitor, this technique will not interfere and the elements in the linked file (now also on a design option) are still picked by the tool and require no special treatment.

Implementation is easy: Create an Option Set (I like to call it Model Management) and a single option named Revit Links.

Now copy over your links to this Option…

…and since there’s only one Option in the Set, it will always be visible, but not selectable unless you uncheck the Exclude Options checkbox.

So far I have not run into any adverse issues, so if you try this and find negative side effects, please comment!

Securing Linked Files

Room bounding in Linked Files

Yeah I know, what a terribly exciting subject after a writing drought! So to get the wheels turning once again, here’s some useful information that might be old news to some but was new(s) to me.
When linking Revit files, we can control pretty much everything: visibility/graphics of model elements, annotation, worksets, design options…you name it. All seems to work in perfect harmony, until you check this little option in the Type Properties of the linked file…

…drop in rooms that are bound by the linked file (wait for it)…

…then change the Design Option to something other than the primary, and you get *sad trombone*…

I think this explains it all. If you have design options that will alter how your rooms are bound, you cannot use the Room Bounding type property of the link. Instead, disable it and use room separation lines in the host model to show the desired options. Yes, this needs fixed (add it to the ever bloating pile, Joe!).

Room bounding in Linked Files

Securing links through worksets

In my projects, I typically create a workset for my consultant linked models and check that workset out permanently to prevent accidental deletion/movement of links (ex: to user "RevitCOP"). The username just needs to be a unique one to prevent anyone from accidentally making an undesired edit.

I have never been a fan of Copy/Monitor functionality but recently I started using it and am running into a problem. When I try to stop monitoring elements or go through coordination monitor to make changes, I'm told that “RevitCOP” has the workset for the links checked out and has to relinquish it before I can make changes. Why is this necessary? All I want to do is move my grids & rename them to match the link (through coordination review). Because of this, I have to open my file under the RevitCOP in order to do copy/monitor & review operations, which seems totally unnecessary. Or I have to quit "securing" my linked files altogether, which I’m really not ready to concede.

During a copy/monitor and when going through warnings, all you're doing is to change the elements in the host file (unless you reject changes, in which case nothing is physically changed), but nothing is being done to the linked project. So why is Revit being so inflexible about a permission that is (intuitively) not required?

I sincerely think that the current logic of having to own the element/workset in order to perform copy/monitor and coordination review is something that really needs to be looked at closely by the Factory. Probably Revit is writing some kind of tracking information to it, but since the only mechanism of securing links is through forcibly checking out worksets, this is causing undesirable consequences and related frustrations (and we don’t want that, right?)

While we’re on the subject of Coordination Review, it would be really nice if we didn’t have to use the steering wheel in order to pan, and simply use the middle scroll button as we do in regular view navigation!

Securing links through worksets

Subcategories in project files: What for?

As a Revit beginner, I wondered what was the reason we could add subcategories in a project file. Once I got more familiar with families and started playing around with in-place families, I realized why we could add them. Yet, I never ceased to wonder if there was another use for them and I finally found one recently.

Let’s say you link in an MEP model and it contains custom families with elements assigned to custom subcategories. If you look at your Object Styles in the host project, you’ll realize that those custom sub-categories do not show up (I believe they should, don’t you think?). So if your link is set to By host view, you cannot change the visual characteristics of certain family parts. This forces most users to change the link to Custom and make edits to the link. Personally, I prefer to do this as a last resort. So how do you control a TV that you don’t have a remote control for? (assume it has no buttons either!)

Adding a subcategory in the host project with the exact same name, actually establishes the missing connection to subcategories in linked projects. It’s like finding the remote for that TV. So there you have it, another use for adding subcategories to projects.

In summary, I think Revit should:

1. Display custom subcategories from linked files in your host project;
2. If objects of a discipline-specific category exist (whether in the host or linked projects), it should display that category even if it is of a different discipline than the Revit flavor you are in. I’m not a big fan of having Revit automatically hide all categories from other disciplines even if they have elements on them. Most users can’t figure out why they cannot turn something on/off (Analytical Model subcategories for Structural Framing and Structural Columns anyone?). I’d be ok with Revit hiding unused categories & subcategories from other disciplines or all unused, but if an element of a particular category exists in the project, that category and all subcategories should be listed in the V/G dialog.

Subcategories in project files: What for?

Troubleshooting

Today I was opening the Arch model (local) and got a ton of warnings regarding dimension strings that needed to be deleted due to their references being invalid. The dialog below was followed by two more dialogs and hundreds of deleted elements.

Unfortunately Revit doesn’t really do a good job at letting us investigate what the heck is going. A way to open a view and see the dimensions about to be deleted would be a good start.

At this point the only thing you can do is to click the Expand button and save the report to html so you can view it later. Unfortunately my project was issued for bid last week and we’re now working on some revisions, so losing all these dimensions is a big problem. The only thing that came to mind was a problem with the structural linked file. So once the project opened, I looked through the html file, picked an enlarged plan detail and opened it up. As feared, the grids and columns were missing, which took away the dimensions.

Now the silver lining is that I was the only one working at this time, so I quickly closed out and checked what was going on with the structural file. Someone inadvertently wrote over the central file while in the process of doing a save-as with this project to start a new one(don’t get me started on that!). So no wonder that dimensions all of a sudden had invalid references!

Lessons learned

1. Keep a weekly pdf/dwf set so you can easily compare what was lost when things go haywire. Or kill trees and print on paper.
2. When bad things happen, make sure everyone gets out of the project while troubleshooting. This prevents major loss of work. For example in this case if someone saved to central after deleting all dims, we would be in some serious trouble. Hopefully now all we need to do is restore the Structural model and re-open the Architectural local.
3. Training, training, training (if you’re in management, this is the most important of all).

For Autodesk

1. Give us a way to investigate and see what is about to happen to the model!!
2. Give us a way to unload links while opening. This way we can keep working and not lose any dimensional references when links are messed up. Currently I’m on hold while we fix the problematic link and then re-open the local. My only option at this point is to close everyone out of the Structural model, rename the folder and then launch my local, thus preventing it from finding the link and only temporarily remove dimension references, rather than permanently.

EDIT: As reader “S” suggested in an email to me, you can unload the workset on which a Revit link resides (which is why it’s recommended that each Revit link is placed on a unique workset). This acts similar to unloading the link while opening the file. However if the problem file was a dwg for example and this was linked in a drafting view, there would be no way to unload it except by renaming the file or folder in which it resides using Windows Explorer.

Troubleshooting

Visibility mystery

Picture this…you have a Site project linked into an Architectural project. You go to a 3D view and nothing from the site file shows up. The treasure hunt begins.

It could be as easy as the workset assigned to the Site link being turned off. Or the link being turned off in the view. Or all the object categories that exist in the Site project file being turned off in the host view. Or having the link visibility being set to “custom” and all categories being turned off. Or the link being overridden in the view and turned off (yikes!). Or a filter’s visibility being unchecked. Or a particular workset in the Site project was closed when initially linking it in. Or a hidden section box was clipping the site project elements out of the view. Phew, I’m out of breath!
However, there is a condition where none of the above are the cause of the problem and could leave you scratching your head for some time. It’s a condition that exposes another little Revit shortfall which makes us beg for even more visibility control.
The problem is a workset in the Site project file that is set to not be visible by default in all views. In this particular case, the users were able to see the information in a plan view set to “By Linked View”, but in 3D views the Site project was invisible. It turns out that all site elements were on one workset set to not be visible by default. We don’t have control over the visibility of worksets in linked files and I think we really need to. The fix was to create a new workset that is visible by default in all views, delete the offending workset and move all objects to the new workset, and then rename it back to what the original one was. Mystery solved!

EDIT:  As of Revit 2011, we now have control over the visibility of worksets in linked files. Thanks Factory!

Visibility mystery

Adjusting stubborn Topography

This trick has a wide range of applications. I have used it before when we needed to move an entire wing of a building by some amount, but couldn't do it within the project because some elements with a vertical workplane prevented us from moving those objects with others horizontally.

In this case it was the opposite. We wanted to move topography vertically, but for some reason, we couldn't. Even if you choose a vertical workplane in a 3D view, topography will still try to move in a horizontal plane. You should be able to move it vertically in a section or elevation, but in our case it wouldn't budge. Also, topography doesn't host to levels, which would have come in really handy in this situation! The last thing we wanted was to edit each point individually or spend a lot of time troubleshooting. So here's what we did:

1. We selected all the elements we wanted to move vertically and grouped them.
2. We selected the group and made it into a link (keep your eye on the Options Bar).
3. Now we were able to move the linked file vertically. We then went in reverse...clicked the option to Bind this linked file (again, eye on the Options Bar).
4. Now it was turned back into a group, so the next step was to ungroup it and delete the unused group.

How many other situations will this technique come in handy to save you? NOTE: Watch out if you're using phasing as you might lose information if you have custom named phases.

Adjusting stubborn Topography

Line weight visibility in linked files

This was inspired by a thread on the AUGI forums and I didn't realize that visibility in Linked Files behaved this way.

When you link a Revit Project into your main host project, the visibility is by default set to By Host View. You can change this option to By Linked View or Custom. So far so good.

If your host and linked projects were started from the same template, you might not notice this issue, which is probably why I never came across this head-scratcher. When getting a project file from some other source outside your office, you stand a good chance that the line weights in each file are not the same as yours and/or other linked files.

When your link visibility is set to By Host View, Revit will use your host project's visibility settings to display the geometry in the linked file/s, together with other settings as shown below.

Notice that Object Styles will also be represented based on the Host file. But here lies the problem: what if the line thickness mapped to the line weights are not the same in each file? That's exactly when you notice the problem. For example in your host project, you might end up with walls showing with different line thicknesses, because Revit will use the line weight per the host file, yet it will still map the line thickness of the parent project file to it's geometry. So while your walls might rightly be using line weight 5 for their cut representation, your host project's geometry will display at 0.018" thick lines per the host's line weight settings, but if the linked project has line weight 5 mapped to a thickness of 0.2", then Revit will use that thickness for geometry residing in that linked (parent) file.

The solution is easy: Use Transfer Project Standards to copy the line weight settings from your host project to the links. I personally don't think Revit should behave this way. If I say I want settings to be By Host View, I would expect the line weight to line thickness mapping to also be honored. Maybe we need a new line item to the above list: Line Weights. You agree? Great, go file a wishlist item on AUGI!

Line weight visibility in linked files