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

Upgrade Warning

With Revit 2015 R2 (don’t try to keep up with version and update identification this year, it’s quite comedic!), we are getting some nice little things. One enhancement that deserves a thumbs up in my opinion is the prompt you get when opening a project that needs to be upgraded, since now the user gets the opportunity to cancel and not be forced to wait until Revit is done. This is especially nice when temporary upgrading of links is involved.

I’ve written about this in the past and so has Mr. Stafford, whose post from today got me thinking. I’m torn between wanting a show-stopper dialog that requires a click to continue, versus the new implementation. The former is better from a disaster-prevention standpoint because you have time to pause and think, especially when opening files that go through the upgrade process quickly and the probability of missing the warning is high. However since Revit does not give us any command-line tools for upgrading projects, nor the ability to suppress warnings, this would be quite disastrous for mass file upgrading via the API. In an ideal world, I would rather get a dialog that the user has to click an option to proceed, as long as we also have the ability to suppress warnings for automation’s sake when we know what we’re doing.

Upgrade Warning

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

To/From Room Door Parameters

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

Prior to Revit 2014, these parameters were very unreliable and prone to error. With Revit 2014, we saw the introduction of a new family parameter called Room Calculation Point, which can help with reporting consistency. However be mindful of the fact that this setting has to be manually activated, otherwise the information will remain as unreliable as before. You can read more about the topic in this RFO thread.

Here are some facts about how these parameters work without the Room Calculation Point enabled:

1. If rooms already exist on either side of a wall when a door is inserted, the room on the swing-side of the door will be set as the To Room;
2. If the door is then flipped, the To/From Room parameters do not update. The user has to make manual adjustments if desired;
3. If no rooms existed when a door was inserted, the first room added to either side of the door will be set as the To Room;
4. Both doors and rooms have to be in the same model for these parameters to report. The schedule can reside elsewhere, however manual changes between the two reported rooms have to be made in the host model.

As you can see, the reported information is prone to error and highly unreliable. Another big issue is the fact that door swing direction does not imply “ownership”: a door could be swinging out of a room and technically belong to that space. It is also usually not possible to infer hardware functionality from swing direction and door “ownership” alone.

By enabling the Room Calculation Point, we can at least address data errors. The To/From Room parameters will then update consistently regardless of whether the door is placed before/after the rooms, or whether the swing direction is altered after placement.

As with a lot of things in our industry, there is no standard way of documenting doors: some include information for the room that the door “belongs” to, some include both To/From Room information, while others completely exclude these columns of data. I happen to be of the opinion that the latter is the most prudent choice, although the Room Calculation Point parameter makes me less concerned about data inaccuracy. However be very careful: changing the To/From Room parameter when the Room Calculation Point is enabled, will actually flip the swing direction! This is a behavior change that you really need to be aware of.

If you happen to use the To/From Room parameter to report “ownership” only, you can do so with even greater reliability by employing the following trick. The little leaders are hardwired in the family template to prevent them from crossing the Internal X-Axis:

By shifting family geometry, you can then consistently report “ownership”. In the example below, both the To Room and From Room parameters will always report the room on the swing side of the door. Note that you can flip the To/From direction if you need to, although that would not change how these values are reported in the example below:

The other very positive side-effect of doing this is that now you cannot accidentally flip the door direction from the schedule, since both To/From Room parameters will report the same data. If you want to report ownership based on the outswing-side, simply shift the geometry in the opposite direction. Please note that “ownership” rules cannot be changed at the instance level (ex: you have to commit ownership of a door to always be on the swing side at the family level), so if you need to change this and still use the Room Calculation Point, you will have to double up on your family definitions in a project, or employ some of the workarounds described in this RFO thread.

To/From Room Door Parameters

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 on Mobile Devices

These days everything revolves around the “cloud” and mobile devices, so it comes as no surprise that Autodesk announced the availability of Revit 2015 in the App Store and Google Play.

They really worked hard this year to keep the new version devoid of too many new features and fixes. Some users felt quite disheartened when they saw how little their hard-earned subscription money had yielded, but soon realized that this was a well-planned maneuver by Autodesk to increase Revit’s circulation amongst smartphone aficionados. The Marketing geniuses at Autodesk pointed out that subscription has not increased that much if you think about it, since you can re-use all your Revit 2014 learning resources for the forseeable future. Publishers are quite upset as this will likely hurt their sales, but popular authors of Revit guide books are quite happy since they can now enjoy a lavish vacation with their families instead of updating their work. In fact a few have even suggested that publishers simply start printing books in binder format so they could just slip in a couple of pages each year moving forward, and just change the binder cover with a new pretty picture that clearly cannot be done in Revit.

Rumors on the Internets hint towards efforts by hackers to even make Revit 2015 run on the “Jitterbug” or your old Nokia flip phone. I’m quite excited about this potential development, which could increase the use of Revit exponentially and also aid in breaking any existing generational barriers. I’m still quite skeptical about how they’ll manage to get the download package to fit, but I think if they removed broken and incomplete features, the application would probably fit with some extra space to spare.

In the meantime Graphisoft continues in the struggle to capture market share. They think that the cloud has promise as well, and are now playing catch-up to Autodesk once again.

Close sources of mine (sorry, I‘m not about to go Snowden on them) think that this is a huge, visionary move by Autodesk. I frankly disagree, as evidenced by my overall lack of amusement, which is further emphasized by my deliberate omission of any exclamation marks in this beautiful piece of writing.

Revit on Mobile Devices

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

Creating Non-Hosted Families from Hosted Versions

I just recently discovered this gem and it seems there are a few people that know about it. Perhaps it was discussed in a forum or some other place, but since I never came across this nice little tip, I thought of sharing it here.

In this post, I talked about a “pseudo face-based family” and this week while I was not even thinking about Revit or anything work-related for that matter, I just had a thought and wondered whether the hosting extrusion could be deleted (I know, my brain is weird sometimes!). So I tested this out and then realized that the resulting family is no “pseudo-anything”, but simply built into a host-less template with the Work Plane-Based option enabled.

So the highly-intuitive process (sarcasm anyone?) of taking a family that is built in a hosted template such as face-based, wall-based, ceiling-based, etc. and produce a non-hosted copy is as follows:

1. Place an instance of the family you want to hack in the drawing area. You can insert multiple ones at the same time;
2. Save the file and close it;
3. Open a new Revit file from no template. This ensures it is completely empty and Revit will thus create this hacked copy when we do step #6;
4. Link the previously saved model into this new file;
5. Go to the Collaborate Tab>Copy/Monitor>Select Link and pick the linked file. Once in C/M mode, click Coordination Settings and make sure that the family types you want to hack are set to “Copy Type”;
6. Click the Copy button and pick the families you want to hack;
7. Finish and exit from this mode when you’re done.

The copied families that Revit created are hacked versions and no longer built inside of hosted templates. Now simply edit the families, delete the extrusions, set them to not be work plane-based and save them…done!

Now I ask, if Revit is able to do all this, why not give us a stupid button instead of this frustratingly long and obtuse workaround?!

Creating Non-Hosted Families from Hosted Versions

Data Management

Data management is something we struggle with constantly, and the more we collaborate across the globe and beyond the walls that contain a single office, the more complex it becomes.

I don’t typically post advertisements here, so I’ll keep it short and add my commentary (what, you thought I wouldn’t have anything else to say?!). Imaginit have made a free video available about this topic, demonstrating how Autodesk Vault could address multiple workflows. The first 15.5 minutes of this video are dedicated to an AutoCad workflow, whereas the rest address a hybrid workflow which also includes Revit Server and their related product, Clarity.

 

To be honest, Vault has never really struck a chord with me because it was built primarily to manage a multitude of files that need to be accessed by one user at a time. This issue goes completely out the window with Revit projects, where the only useable component becomes linked file control. We can already do this in a multitude of ways (ex: Newforma InfoExchange transfers) and Vault just seems like too much complication for in-house collaboration. The only thing that could have some promise is family management and the ability to reference “published” files (as opposed to “live” files) between office locations. For example HOK offices collaborate a lot amongst each other and we utilize a series of techniques, depending on team setup. A simple method entails server to server nightly file copies to be used for linking purposes. This simply automates the transfer of linked files between offices, whereas with external consultants, teams initiate file transfers on a weekly basis via InfoExchange. Vault appears to have some potential to achieve this as well, but just seems like too much technology to manage. Why complicate when you have something that is quite simple and works already?

In the last few minutes of the video, we see a glimpse of Clarity. I think the software has a lot of potential and nice features, such as the Room Data Sheet reporting functionality which is all interlinked with other reports, but unfortunately I believe Imaginit has slammed the doors shut for most companies thanks to the (excessive) price point. I think the enhanced security features that can be added to a Revit Server infrastructure are quite powerful, such as limiting external team access to certain projects. However it is much, MUCH cheaper to simply install a couple of additional virtual servers to host a dedicated Revit Server infrastructure to handle confidential projects.

Imaginit also have a nice e-learning portal called ProductivityNOW. They make some resources available free of charge such as white papers, seminars, tips & tricks, etc., while others are restricted to paid members. So go ahead and check it out, you might find something useful there too!

Data Management