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

Phantom Keynotes 2.0

Summer is here and life’s getting very busy, long vacation is over (sadly), now it’s time to get back in the swing of things! I just realized I missed re-posting something on Keynotes and Legends, so here we go…more to come, stay tuned.

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

I posted about this topic in the past (see Phantom Keynotes) and it seems that we keep finding issues with Keynote Legends reporting keynotes that don’t seem to exist in the view. I have also written a follow-up post (see More on Keynotes) to discuss other visibility issues and other problems related to this functionality and the current User Interaction shortfalls. Recently some Electrical users pointed me to additional instances of misreporting by Keynote Legends, so this post will summarize those findings. These can be reproduced in Revit 2015.

1. If the Annotation Crop Region is not enabled, keynotes attached to objects that lie outside the model crop region are still reported, which is completely unexpected. The result is the same whether you use Element Keynotes or User Keynotes. The expected behavior should be that if keynoted objects lie outside of the model crop region, those keynotes should not appear in the legend, regardless of whether the annotation crop region is enabled or disabled.
2. Another instance of Phantom Keynotes occurs with keynoted elements in close proximity to the view’s model crop region. This issue is exacerbated even more when the tags are far from the objects they are attached to. With the Annotation Crop Region enabled, the keynote still appears in the legend unless the boundary of the Annotation Crop region touches the edge of the keynote annotation. This is completely unexpected and the following series of images illustrate the problem:

 

If the Model and Annotation Crop Regions are adjusted such that both the model element and the keynote tag lie outside these boundaries, the legend will rightly not report that keynote:

However the Keynote Legend will still incorrectly report the keynote if only the model element is outside of the Model Crop Region, but the Keynote Tag is within the Annotation Crop Region (the legend is actually only concerned about the tag, not the model element):

 

Please be very careful when using this functionality and double check your work (don’t assume that the Keynote Legend will hide unrelated keynotes for you!). The only workaround at the moment is to pick the keynote tags that shouldn’t be listed in the legend and manually hide them in the view, which is a very ugly workaround. The following process needs to be followed for each view:

1. Select all instances of the keynote tag in the project;
2. Remove all keynote tags visible in the view from the selection;
3. Right-Click and Hide all instances in the view.

The desired and expected Keynote Legend filtering is as follows:

• If the keynoted model element is not visible in the view and as a consequence the tag is also not visible, do not report it;
• If the Keynote Tag is not visible because it is manually hidden in the view or because it touches or is outside the Annotation Crop Region, do not report it.

Phantom Keynotes 2.0

Filled Regions and DWG Exports

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

This sounds like an odd paring for a blog post subject, but they are unpleasantly related.

When a view contains the following items and you export to a CAD format, you will likely experience loss of data:

• Families with nested Generic Annotation such as Security Devices, Fire Alarm Devices, Electrical Fixtures, etc.
• A large filled region covering a big portion of the view, usually to identify areas of work and areas outside of work.

This issue was filed with Autodesk Support and it has been known for at least 3 to 4 years. It seems that regeneration of the nested families fails, which results in the absence of these devices in the export. They are actually still in the view, but since in most cases there is no geometry visible in plan except the nested annotation itself, you end up with no object representation. The following are some workarounds, some more acceptable than others, depending on your situation:

1. Delete/hide the filled regions before exporting;
2. Change the filled regions to Solid Fill and everything will export as expected. You will then need to open each exported file and change the hatch to something other than solid within the CAD editing software;
3. Do not use component families with nested annotation. This is obviously not an acceptable solution for MEP (#2 or #1 seem to be the only viable solutions), but might be acceptable for Interiors, where they can simply show these devices through the use of Generic Annotation families placed directly in the view. These can be scheduled within Note Blocks if required, however this workaround means you cannot make these objects visible in other views to properly coordinate your work, or see them in elevations, sections and 3D views.

There is no good workaround for this issue and the best is probably #2. Let’s hope the Factory can get this fixed sooner rather than later.

Filled Regions and DWG Exports

Revit 2015

What’s new?

Not much.

Commentary

I give up.

Revit 2015

Manufacturer Content - Lighting

I originally wrote the following on the HOK BIM Solutions blog and have since received some additional comments/observations that I would like to add here before re-posting (thanks a lot to Dan Stine!):

1. Revit does not support absolute photometry (i.e. LED IES files). This probably has to do with the format of the IES file where there is a -1 in place of the wattage value for an LED file and Revit is not currently able to handle this, which means you cannot produce renderings for LED Photometry.
2. An IES file describes how light is emitted from a fixture and takes into account all geometry, color, reflectivity and all other characteristics of the fixture. The reflector is only required to be modeled if you’re using a light source to make the fixture look more believable, or through using a self-illuminating material on the lens (the post below will describe all this in detail). These are also invaluable for lighting calculations, not just renderings.
3. Once an IES file is used, the family remembers the information and a link to an external file is not necessary. This is similar to the behavior of MEP families in 2014 which contain embedded lookup tables (note that even though it appears that the Photometric Web File parameter can be connected to a custom text parameter, it does not seem to work. A support request was filed to confirm if this is a bug).
4. Things get more complicated when doing lighting analysis such as with ElumTools, which require lighting content to be created with specific standards:
• Nested light sources must be shared
• Light source ignores all geometry in the host family
• Light from nested families “sees” geometry in host family (e.g. shadows from the arms of a chandelier)
5. Another challenge with rendering in Revit is reflectance. The Daylighting Analysis for Revit uses a formula based on the RGB values of the appearance asset for a given material. ElumTools uses a similar technique (which can be overridden in their Material Mapping dialog) but is based on the RGB value used in the Revit Material Dialog’s Graphics tab.

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

I will reluctantly kick off this post first with a little rant: is it too much to ask from a Lighting Manufacturer, that their BIM content render appropriately? I think not!

I am sure (hopeful, really) that there is good lighting content out there, but I’d like to take you through a specific journey that in my opinion, was unnecessarily painful and is probably quite representative of today’s common reality. So here we go…a user needed to do some “quick” renderings of an interior, utilizing a fixture by Focal Point called “Equation”. Based on the marketing brochure, this is what these should look like:

Here’s the resulting render using the Architectural family downloaded from the manufacturer’s website (for the purpose of this post, I kept the exposure settings constant so you can easily see the relative differences):

It is clear that the family is built incorrectly. The overall geometry might be close enough (it wasn’t to my liking either, so what you’re seeing in this post is a rebuilt version, where I broke it down further so materials could be assigned to different parts of the family, including the internal reflector), but lighting is not emitting through the fixture. Editing the family revealed that the lighting definition was not set to Photometric Web. The MEP version of the family did have the lighting set to an IES definition, but who do we really expect to do an interior rendering? In my opinion, if you have photometric definitions for your fixtures, you should use those definitions exclusively, no exceptions.

After downloading and adding the IES definition to the Architectural family (which was ceiling-hosted…more on that later on), we end up with this:

This is clearly darker than the original version, so the luminance of the original family far exceeded reality. Now, I understand that we’re not designing a lighting strategy/layout based on a rendered image, but we do expect the result to be perceived as close to the built reality as possible. The IES definition gets us closer, however we still need to do something about the fixture itself. The quickest, most efficient technique is to use a self-illuminating material for the lens, which results in a decent render if the fixtures are far from the camera, but would not be suitable for close-ups due to their “flat” appearance. In the example below, the material’s Luminance setting was set to 300:

Self-illuminating materials add to the general brightness of the image beyond what you get out of the IES definition, but there’s really nothing we can do about that, except tweaking the resulting render exposure to get it close to how we perceive the scene should look like.

For a more realistic look, the fixture needs to be built differently. You need to rough-in the internal reflector, place a tubular light source to mimic the lamp as closely as possible, and then nest the family into another one so you can set the additional Photometric Web light source. Since the family I was editing was already hosted, I nested in an empty family into it instead:

The most noticeable and perplexing issue are the inconsistent artifacts around some of the fixtures. I was able to reduce them a bit by shortening the light source, but they would not go away completely (I think this is a bug, but have not yet confirmed…comments welcome!).

The other issue are the harsh shadows, which are a result of the lens material being incorrect (used frosted glass) and can be easily tweaked as we’ll see shortly. With this method you add a significant amount of light to the scene, above and beyond the Photometric Web definition. The image on the left uses the tubular light source only with no Photometric Web. I noticed that I was using the original family’s metallic paint for the reflector and once replaced with a non-metallic white, the scene improved slightly:

Tweaking the lens material was necessary to get this scene closer to the lighting atmosphere resulting from these fixtures, although those pesky artifacts mean that post-processing cleanup is still required to get a presentation-worthy product.

Just in case you’re curious about the lens material, here are the settings I used after some trial and error (click to enlarge).

What an adventure! I really don’t think it should be this painful to make a “quick” rendering using manufacturer-provided content, especially when dealing with lighting. We really need to be able to drop in such families, complete with appropriate material settings, and move on with our design work, rather than requiring a total rebuild, tweaking of their materials and several test renders.

Lighting Content Building Tips for Manufacturers

1. Start with a non-hosted lighting family so you can use the light source that is built-into the family template to emit light from the fixture. This also gives you the flexibility to simply nest into any other hosted family template, rather than rebuilding each one from scratch and making change management difficult for you and your users!
2. By doing #1, the end user can then decide whether using a self-illuminating material for the lens is a better solution and they can simply edit the family to remove the light source (emitting from the fixture) if that is the chosen path;
3. Nesting into a hosted template means you can now also use the Photometric Web definition in addition to the other light source used to make the fixture appear to emit light. If an IES file is available, the fixture should not use anything other than these definitions. Also, make them downloadable together with the families, not separately! It is torture to figure out which IES file belongs to which fixture and which configuration. See #5 to manage these better;
4. Include proper materials!
5. Use Type Catalogs instead of making a plethora of individual families. It is more difficult for you, and for us, to manage them otherwise;
6. Don’t miss building the reflector and the cavity within the fixture where the “emitting” light source will reside. If you only consider the exterior of the fixture, your end users will have to spend a lot of time re-building them in order to produce acceptable renderings. And once they find another manufacturer that does a good job with their content, guess what is bound to happen?

Manufacturer Content - Lighting

A Stinkin' Simple Railing - Part 1

When long-time users pour so much passion and energy trying to make Revit better through constant feedback, they eventually get burned out and exhausted when they do not see significant change, version after version. Sadly, I find myself in that situation and it is getting harder to stay positive about Revit, even though it is still my preferred software of choice (how about that for leverage?). The way Autodesk have been treating its development these last couple of years is nothing short of appalling. They seem to have forgotten the “works like an Architect thinks” mantra and sadly too often Revit seems to work like a clunker and thinks like a delusional Architect instead. The API keeps improving, which is great, but I expect a heck of a lot more from the exposed part of a platform that is briskly coming up to its 14th birthday since becoming commercially viable. If software age is more like dog years, one can safely say that Revit is no teenager.

In the spirit of (desperately) trying to stay positive, I’d like to write about all the problems with the “new” railing tools. Nowadays for Autodesk, “new” means less than 20% completion. I wish I had that luxury myself, so I’ll just roll around in envy for the time being.

I documented these while trying to build a simple, wall-mounted handrail commonly found in fire escape stairs. Since there are too many issues to list and document in one post, I’ll do it in multiple parts so I can be of service to my loyal readers. Some might not see this as being positive but in my book, the first task on the path to improvement, is to acknowledge your problems. I will suggest workarounds and best-practices where possible.

Some bugs have been resolved in Revit 2014, but not all projects I deal with are in that version (actually as of now, very few are). Template versioning has become a real headache where things work differently depending on what template version a project was started from: the upgrading process alone is unlikely to guarantee nirvana. Note that everything I’ll be posting about has been confirmed through Autodesk Support.

BUG #1	Occurs up to
Posts in “old” railing on “new” stair	Revit 2013 SP3*

STATUS: Resolved in Revit 2014 SP1 *only if you start a project from a 2014 template.

If you had a previously working old railing definition that used posts to define extensions and you used it on the “new” assembled stair, the posts do not display in plan. Your existing projects are not going to get fixed through an upgrade to Revit 2014. In this case you’re going to have to re-build them with a different railing definition. As you can see below on the left, the railing works on old sketched stair definitions but not on the assembled stair. If you start a project from a new 2014 template and copy & paste the faulty railing definition shown on the right, it works. Why not when upgraded? I have no clue.

 

BUG #2	Occurs up to
Terminations not visible in plan	Revit 2014 SP2

STATUS: Unresolved

Termination families do not represent themselves in plan views but when you hover over the railing, you see the invisible outline of the termination family. Visibility should be controlled through the family subcategory and detail levels, but this is not happening. So if you were thinking creatively of using a termination as a railing extension to get around other buggy behavior, forget it.

 

BUG #3	Occurs up to
Align tool on supports doesn’t work right	Revit 2014 SP2

 

STATUS: Unresolved

The align tool does not work correctly on supports when handrails are sloped. When they are flat everything is fine, but if it slopes (which is the most common), the support is moved by the incorrect distance and it takes several subsequent alignments to get it close to where you want it - it never properly aligns, just keeps getting closer and closer. Workaround: Use the move tool in lieu of Align.

Stay tuned for more bugs and “as designed” issues. Happy New Year!

A Stinkin' Simple Railing - Part 1

Copy/Monitor & Batch Copy for MEP Update

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

In the previous post, I made a partially correct statement and want to elaborate more on it. I said that re-hosting doesn’t work, but turns out it just failed in my particular test files due to some special circumstances. In general it should work.

When re-hosting fails

In the test files, ceiling-based fixtures were used. When this model was linked and I ran Copy/Monitor, Revit took that ceiling-based fixture and modified it without my knowledge (no warning was ever issued). The copied fixture was not the same version as the original one and it turned into a pseudo-version of a face-based family that is different than a true face-based family: Geometry was on the bottom of the face rather than the top, and there were “remnants” of the original ceiling-hosted fixture, such as a “Ceiling” reference plane. When I tried re-hosting the pseudo face-based fixture, Revit complained and wouldn’t do it.I suspect that the above is due to the trick that Revit is trying to play. Here is the original fixture:

The following is the modified copy/monitored fixture. There is a perfectly valid reason Revit did this, because in the host model there is no ceiling geometry:

However a true face-based family would be like the following image. Note how geometry is built on the top face and there is no “Ceiling” reference plane. I think this is the reason that Revit is unable to re-host the family shown above.

When re-hosting works

When copy/monitored fixtures are face-based from the start, Revit does not need to do modifications on the fly as described above. In this case, re-hosting works as expected. So if you are faced with copy/monitoring of hosted fixtures other than face-based, such as ceiling or wall-hosted, make sure to use the type-mapping feature, so hosted fixtures are substituted with pre-loaded face-based families.

Final thoughts

There is definite room for improvement in linked model workflows, especially for the MEP disciplines. The recommendations for transferring light fixtures from a design model to the final documentation model are as follows:

1. Use face-based families whenever possible and name hosted fixtures clearly so they can be recognized and substituted;
2. Use the batch-copy feature and specify the type mapping so hosted fixtures can be substituted with pre-loaded face-based fixtures;
3. If you are not going to monitor fixtures for changes in location, do not use the dedicated Stop Monitoring tool. Instead, remove the link and re-link again when needed. This way copied fixtures can be moved around freely without the need to re-host them.

Copy/Monitor & Batch Copy for MEP Update

Copy/Monitor & Batch Copy for MEP

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

The Copy/Monitor tools tend to be a Love/Hate relationship in that very order. In fact we have recently been using the batch copy functionality because we sincerely love it due to its flexibility. But that love is fading quickly due to some unexpected repercussions.

A common scenario to employ this tool on, has been when a Lighting consultant/designer is working in a separate model (for design purposes only, not for documentation) and our Electrical Engineers need to circuit these lighting fixtures and document them in their power and equipment drawings. These fixtures need to be hosted in the electrical model for proper circuiting. Copying and pasting fixtures one by one from the linked lighting model is highly inefficient. Opening the source model to copy and paste into the documentation model also doesn’t work due to hosting issues (most of these families are face-based and cannot be pasted) and also due to the fact that Paste >> Aligned to Same Place uses the Internal Coordinates to determine location and this is not always consistent between models. On a side note, best practice dictates that you link other discipline models via Auto – Origin to Origin to avoid these problems.

We have received several reports and anecdotes of performance degradation when copy/monitored fixture counts are high, so we have been disabling monitoring soon after the copying is complete and resume with manual coordination from that point on.

Unfortunately when you stop monitoring by using the dedicated tool, MEP categories become pretty much useless as they can no longer be modified!

EDIT: Refer to this post. If you try re-hosting, you have to use the workplane positioning option, which is not desirable. I am not sure why Revit even asks you to do this because copy/monitored elements do not have a host in their properties.

There seems to be no work-around, short of deleting all fixtures and starting over, which is really bad. Lesson learned: Do not stop monitoring with the dedicated tool! If you want to stop monitoring, remove the link. Once you do this, none of the MEP categories will behave as shown above and you can freely move them around and re-monitor at will. These categories then pretty much start behaving as Levels, Grids, Columns, Walls and Floors, which we can stop monitoring at any point without experiencing the same repercussions.

At least we now have a plausible workflow for future projects and the love for the batch-copy tool has been (cautiously) restored.

The nice thing is that you can specify type mapping and only batch-copy one fixture type at a time. Just make sure that if you want to use this as a pure copy tool with no monitoring, to then remove the link soon after. You can re-link it back in, but this is currently the only safe way to stop monitoring without putting future revisions to the position of these fixtures in jeopardy. Autodesk has recorded this behavior but there is no estimate when this will be addressed.

Copy/Monitor & Batch Copy for MEP

More on Keynotes

This is a quick follow-up post to this one on the topic of keynotes. I have to confess that this is one of my least favorite tools in Revit. Not because of the potential of using keynotes in documentation, but because of the overall lackluster implementation in Revit, which tends to leave a lot of holes in the workflow.

We have also been plagued by too many visibility and collateral issues in the past:

• Pre-Revit 2013, keynotes didn’t work properly in dependent views (never posted here about it after reporting the issue, but it was resolved in Revit 2013);
• Borrowing of Sheet Worksets when keynoting elements in Linked Files as explained here at the Revit Clinic in pre-Revit 2014. This has been addressed in the current release as explained here, which is my primary reason for upgrading existing projects to 2014;
• Besides the visibility issue noted in my previous post, keynotes buried in design options, even if not visible in the view due to V/G settings, still schedule in the Keynote Legend (thanks to Trey Klein for this one!);

I’m sure there are other issues, such as the inability for multiple users to edit the keynote text file, API limitations that prevent developers of Keynote plugins to reload a modified keynote text file as soon as it is modified, and the list goes on.

Steve Stafford has a very good post on the topic if you’re into using this functionality. My biggest point of contention with keynotes is the over-use of User Keynotes, which increase “laziness” in updating Revit families in content libraries to actually include keynote information and discourage abiding with firm standards (assuming they exist). There are instances where keynotes need to be placed on the fly such as in addition & renovation projects containing demo plans, where you’re mostly assigning “actions” to collections of elements rather than definitions/”nouns” to singular elements. However in most cases, I encourage users to first assign a keynote value to their families, and then place Element Keynotes instead.

If you’re a heavy keynote user, you absolutely have to use a plugin. Mr. Stafford references a very good one by Steve Faust of Revolution Design, called Keynote Manager. I believe this is the first plugin ever built to address keynoting inefficiencies and is nowadays a very mature and full-featured product. I have been toying around with another one recently from KiwiCodes called Keynote Browser. It is still not as fine-tuned as the Keynote Manager, but could be a slightly cheaper alternative if you don’t need as much functionality, although at the moment Steve’s solution is much more solid and reliable.

More on Keynotes

Phantom Keynotes

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

We have had several users report that some items in Keynote Legends could not be tracked down in any sheet view, even after verifying that keynoting default settings are correct. This issue had me scratching my head for a while until I figured out what was going on.

Here’s a typical scenario where this could occur: You have a core & shell project that was documented and under construction and the model gets copied as a new project for the Tenant build-out phase. As the model cleanup process commences, users start reporting that they cannot find some keynotes that are being reported on the legend.

While troubleshooting, I noticed that when enabling the view's underlay, the phantom keynotes showed up together with the tagged elements, which then led me to tweak the view range and ultimately discover how these project files were started and what the root of the problem was: when the view range was adjusted, keynoted elements were no longer visible, but still reported in the Keynote Legend. As you can see in the image below, a plumbing fixture was keynoted and properly listed in the legend:

In another view, the cut plane and top plane were lowered until the element and keynote were no longer visible in the view::

In the above image, you can also observe that right-clicking the family type also reveals that the object is not visible in the view, yet it reports in the legend. Note that hiding the element and/or tag in the view makes the legend update accordingly, but in the above example the legend is misreporting.

This has been confirmed as a bug and slated for a future fix. In the meantime, please be careful and use this example to help in your troubleshooting efforts.

Phantom Keynotes

Cut Representation of Slanted Columns

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

We have confirmed a bug with the cut representation of sloped Structural Columns in views set to a Coarse Detail Level. (EDIT: the bug seems tied to the symbolic linework that shows only in Coarse). This issue occurs in Revit 2014 SP1 and in prior versions as well.

The Structural Column family in the following example was set to not show pre-cut in plan views. When the Detail Level of plan views is set to Coarse, the cut representation is inaccurate. In this example, the slanted column (End Point Driven) was modeled in an elevation view from Level 1 to Level 5 and later stretched past these extents. A view associated with Level 1 (Fig. 1 – click to enlarge) was modified to have the same cut plane location and bottom plane as another view associated with Level 4 (Fig. 2 – click to enlarge). We expect the cut representation to be unaffected by the view’s Detail Level, however as you can see the column cut representation is incorrect when this is set to Coarse:

Fig. 1

 

Fig. 2

Also slanted columns, stairs and probably other categories, are not respecting the view’s Depth Clipping settings and are shown in full projection below the cut plane. Until this bug is resolved, please use caution and avoid setting your plan views to Coarse Detail Level when locating interior objects and equipment around slanted columns.

Cut Representation of Slanted Columns

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

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

Spiteful CAD Imports

So this week the buildingSMART managers at HOK were discussing ways to get rid of imported (BAD!!) CAD files in Revit projects. Should be something that is easy to do, right? Well, not so easy it turns out.

If you need to do this, you might simply fork out a little cash for a custom plugin. Autodesk Exchange has a good number of such things available and my cohort Brok Howard pointed me to Purge Cads. I have not tried it, but I did confirm with the developer that it does not touch linked CAD files, so for a couple of bucks, this will get the job done fast.

One way or another, you need a plugin. In my case I had Ideate Explorer at my disposal. Unfortunately it lumps CAD Imports & Links together. If you have this plug-in, here’s what you might call “an obscene work-around” to hack your way to the finish line:

• Assuming you have worksharing enabled, have another user go to the Manage Links dialog and re-load all loaded CAD Links and load & unload all unloaded CAD Links. All we need is to have another user borrow these linked instances so we can get their name in the following step;
• Go to the Manage Links dialog and try to load/unload the links. You will then get a list of CAD links that you don’t have permission to edit (the ones touched by the other user in the above step). Take note of the names;

• In Ideate Explorer, select all CAD Imports/Links, then go to the Revit filter and de-select the instances listed above.

• Now delete the selection and the links will be retained.

Autodesk (or Ideate), if you’re reading this, don’t you think our lives can be simplified by a smidgen? This type of functionality should just be built into the product. The amount of solutions we have to default to via plug-ins is getting way out of hand!

Spiteful CAD Imports

Color Schemes in Reflected Ceiling Plans

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

 

Color schemes are a great analytical and visualization tool which can be used in floor plan, section and elevation views. Sadly, this functionality has been left out of reflected ceiling plan views. So how do you go about creating a colored ceiling plan?

There are a few of options at your disposal and each has its downfalls.

A) Overlaid Views on a Sheet

Create a floor plan view and turn off everything except rooms, then apply your color scheme. Create a reflected ceiling plan view and set ceilings to 100% transparent. Finally, overlay these views on a sheet.

The main drawback with this solution is that you are unable to work in a composite colored RCP view since the final result only exists on a sheet. Activating the RCP view and editing directly on the sheet results in the other view appearing half-toned, so it’s still not a perfect solution.

B) Plan View with RCP Underlay

Create a floor plan view and set the Underlay to Reflected Ceiling Plan orientation for the same level as your view. Set the Color Scheme as desired…

…and uncheck the halftone option for Underlays.

(Manage>Additional Settings> Halftone / Underlay)

The result is similar to A) above, but now you can work directly in the colored view since there is no required compositing of views on sheets.

The main drawback with this solution is that you are not truly seeing an RCP view, so some features that occur above the cut plane might not show up properly or not at all. For example take a look at the door: the frame should show up at the head in a true RCP view such as in A) above, and is thus incorrectly represented in this “hacked RCP”. Please also note however that Revit represents cut families based on the representation stored in the family itself, so you have to be very careful with object representation even in a regular RCP view (ex: the window has an extended sill, yet that sill shows up incorrectly in RCP views too).

As with all workarounds, there are no perfect solutions, so make sure you understand all the issues before choosing the option that works best for your project. Hopefully the Factory will eventually enable Color Schemes for Reflected Ceiling Plans as well!

Color Schemes in Reflected Ceiling Plans

Shared Positioning

This is a topic that has – historically - caused confusion across all levels of Revit users, myself included. I seem to have to re-learn the ins and outs of shared coordinates and the myriad array of associated tools every time I have to intervene on a project where multiple linked models are employed. This week has been one of those weeks, but this time I am thoroughly documenting this topic in an effort to shorten the learning curve next time this comes up once again!

For starters, HERE is a very good summary blog post by Steve Stafford with links to other of his posts on this very topic.

I will write more in detail on this as time permits, but in the meantime, I will offer the single most important strategy to avoid confusion: if you don’t need Shared Coordinates, don’t use them when linking and positioning models! Sounds simplistic, but it is valuable advice and you should ensure to touch on this in your BIM kick-off meeting. If you have separate discipline models for a particular building, they should link into each other with Auto – Origin to Origin from day one. This way you reserve Shared Coordinates for other purposes. Don’t use this system to fix sloppy and incorrect linking because you lose the flexibility to use it for other desirable purposes, such as reporting true site coordinates. For example if you want views showing Level 1 at 0’-0” in some sections/elevations, but want the ability to report the exact height above sea level or to report site building coordinates in a site plan, you won’t be able to do it simultaneously in the same project if you have consumed Shared Coordinates to fix improperly positioned models at project startup. EDIT: I should have worded this better. What I mean is that if you use Shared Coordinates as a linking fix with no regard to properly locating the shared coordinate origin and orientation based on a true survey mark, you would have to repeat the process later if you need to report coordinates relative to this point (especially the elevation above sea level), which can be a painful exercise later in the project.

The other problem I’m finding with the use of Shared Coordinates is that if a model with shared positioning is moved and this in turn causes Revit to save the location back to this linked model (sometimes even when nothing has actually moved), the Project Standards workset gets checked out and not properly relinquished. This results in a team member of one discipline (ex: Mechanical) owning the Project Standards workset in the Architectural model, which can lead to quite a bit of finger pointing! I’ve witnessed this several times when Architectural wants to edit the project address and they are locked out because Project Standards is owned by someone that has no business being in their file.

So are Shared Coordinates pure evil? I won’t dare go that far as their use might be absolutely necessary when exporting data to other applications, such as when needing IFCs for use in Solibri Model Checker. They are a great tool when used with care and caution, but they are undoubtedly one tough nut to crack.

Shared Positioning

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

Wall Quirks

Got very busy around here, hence my extended silence. To make matters worse, there’s Euro 2012 now so…while Zach Kron continues to chirp away at funky forms, nodes, divided surfaces and adaptive component families, I think I’m going to continue pointing out the Quirks of Revit Walls^{TM .}

When you unlock the bottom of a wall layer, you can extend it past its bottom constraint (and vice versa for the top). This functionality has been in Revit for as long as I remember. Nowadays we get a lot more control through Parts functionality if we want to fine-tune for panel joints, thickness, extents, etc. Layer unlocking is very handy when trying to rest the base of masonry veneer on a brick ledge or when you want the gypsum board layer to stop below the top of the stud layer for example.

However there is a peculiar condition that we’re presented with when we edit the profile of a wall to create an opening. I totally understand the programming logic of why, but from an architect/builder perspective, this does not make any sense at all. When the profile is edited, the bottom-most horizontal line is still recognized as the base of the wall, so if you edit the Base Extension Distance, you end up with that same extension happening at the “opening head”. And as you might have guessed, the programmer and I just don’t see eye to eye on this one as I don’t believe it should behave this way. Anyone else agree?

So in an effort to outsmart Revit, I inserted an opening instead. As you can see in the middle example above, it seems to solve the issue. However this only works if there is a positive offset value for the opening and as you can see on the right example with the opening having a negative or no base offset, the opening head is messed up once again…#fail3.

By now you’re ready to stop using the unlocked layer functionality; but wait a minute, there is a way (as always!): start an in-place wall family and create an opening in there (Revit will ask you to pick a host).

I know, it shouldn’t be this hard. We see eye to eye on that one.

When working on my first Revit project, I dealt with this same issue only to have it resurface years later while helping another team. It was actually the same exact design scenario: an exterior wall with varying “panel” finishes and continuous stud backup. The team edited the profile of one wall and nested the other in. However when the layers were subsequently unlocked and the masonry lowered to rest on the brick ledge, all head conditions messed up and started overlapping the layers of the nested wall. In such a case, your best option is to not even mess with openings and just embed one wall within another using the Cut tool in plan view, since it’s easier there.

Now when you need to adjust the size and location of the embedded walls, you won’t have to chase around the project correcting the openings as well. And the unlocked layers won’t give you any heartburn either.

Wall Quirks

Fine-tuning of material surface patterns

When materials with surface patterns are used, there is a good chance that you need to tweak its position, and perhaps even rotate it to some degree.

With system and in-place families, this is very easy to achieve, the latter being a little more tricky. So let’s take a wall with a surface pattern for example. You can tab and pick one of the lines and nudge/move/rotate as desired. Even the align tool works like a charm in cases like this. In fact, we use it all the time for tile-work in interior elevations (filled regions are a bad idea for this purpose as you cannot control the fill position/orientation, so painting the wall with a material and fine-tuning the joint locations represented by the surface pattern, is a much better solution). You might be mostly familiar with doing this on ACT ceilings, where you control the position and orientation of the grid by fine-tuning the surface pattern positioning.

When it comes to in-place families, Revit doesn’t allow you to directly control surface pattern positioning. To achieve this, you have to be in in-place edit mode. This is a very subtle, but important fact as you’ll see shortly.

Unfortunately with component families, there seems to be no way to adjust material positioning in the project environment. But recall my point above about the subtle fact…you can adjust the surface pattern in the in-place family editing environment, so why not add some parameters to expose this functionality in the project environment while editing a component family?

As it turns out, you can only adjust the pattern rotation, which is better than nothing. It is really finicky to get it to work and you have to do it a certain way or it won’t work properly. I could not find a way to modify the position of the the fill in the x-y directions, no matter what I tried: ref. planes, ref. lines, constraining to the geometry etc. None seem to work. However rotation works well and I was very surprised to find that even when you change material or the surface pattern (from orthogonal to slanted etc.) in the project environment, the functionality kept working and did not cause the notorious “can’t create type” error.

It is very peculiar to note that you cannot actually flex the rotation parameter in the family editor more than once, or the family will break. Here are the main rules you have to follow:

• The angular parameter has to go from a reference plane to one of the pattern’s lines. I found it easier to use an orthogonal crosshatch while building my test;
• Make sure to set the angle to zero before applying the label to the angular dimension or it’ll somehow try to rotate the pattern (this is definitely a bug) and cause a “constraints not satisfied” error;
• When loading the family into the project environment, the angular parameter has to be zero, otherwise the surface pattern comes in skewed. I noticed that if you load a family with a pattern rotation of say, 10 degrees, the pattern in the project will actually be rotated at twice that amount (20 degrees in this example) and the family doesn’t react when changing the angle between 0 and double the original angle (20 degrees in this example). So make sure the angle is zero when you load it! Just don’t try flexing it in the family editor either or it’ll break.

This technique works for all material application methods on geometry in the family editor:

• Painting a material directly on the geometry face
• Painting a material parameter on the geometry face
• Assigning a material directly to the geometry
• Assigning a material parameter to the geometry

I’m not sure how useful this workaround will be to anyone, but there you have it! Hopefully the Factory will resolve this issue and we’ll be able to fine-tune surface pattern positioning directly like we can on system families.

Fine-tuning of material surface patterns

Revit2013 in Perspective

Finally! We can now work in Revit in perspective view. I’m so sick and tired of hearing about how the other software can do this and have to sit there and endure the justifiable criticism. But no more!

As you can see below, just click on the View tab and select the new Perspective button. It’s that easy. Arguably my #1 feature of this new release. Way to go Factory!

Revit2013 in Perspective