Tuesday, 20 January 2015
We recently had a team working on a high-rise project and they wanted to use the Level 8 plan as an underlay for the Level 5 design. In other words, using a level above as a reference for a lower level.
PROBLEM: The walls didn't show, but plumbing fixtures did. As a matter of fact, it seemed like anything that was supposed to be cut in plan view was not showing. We tried just about everything to fix the problem...changed the view discipline, checked the phase filters, and so on.
It turns out that the View Range settings are crucial to the behavior of underlays. If EITHER the host view or the underlay have the View Depth set so that the views 'cross' each other - cut object styles will not be displayed. This usually happens when View Depth is set to Unlimited.
While this seems to make sense for an upper level that uses a lower level as an underlay, it behaves the same way in the opposite. If the View Depth of the upper level includes the lower level within the view range, Revit thinks the elements are already being displayed and does not show them in the underlay.
Tuesday, 13 January 2015
Antony McPhee provides some constructive commentary on the standardized shared parameters provided by the NBS (National Building Specification) in the United Kingdom over on the Practical BIM blog.
(Thanks to Cesar E. for the contribution)
Monday, 27 October 2014
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:
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 3).
Wednesday, 24 September 2014
For Example, you open Revit, click to open a file and the open dialog box "Pops Up". Only, Revit seems to hang and you never get the dialog box to display.
Try this quick little Windows Trick to get the dialog box to become "Sticky" to your mouse and then move it back onto your viewable screen.
2. Perform the following Keystrokes:
A. ALT+Space Key
B. M (This is for Move)
C. Push one of your Arrow Keys (Doesn't matter which direction)
D. Move your mouse and the active dialog box will be attached to your mouse cursor and you can now place it where it can be visible.
Keep in mind this is a Windows function and will work for more than just Revit, the solution works on anything that has a standard dialog box or window that can be Minimized, Maximized or Closed.
I hope this helps alleviate some frustrations in finding where dialog boxes go and seem to make your application hang, but really it's waiting for a response from you!
Tuesday, 20 May 2014
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.
- 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.
- 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:
- Select all instances of the keynote tag in the project;
- Remove all keynote tags visible in the view from the selection;
- 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
Monday, 14 April 2014
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:
- 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;
- If the door is then flipped, the To/From Room parameters do not update. The user has to make manual adjustments if desired;
- 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;
- 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.
Friday, 11 April 2014
Here’s a list of best practices David Ivey shared for synchronizing with central (SWC) in Revit:
Never leave for extended periods of time (i.e. Lunch, Meeting, Home) after hitting the Sync button.
Revit will often ask for something before the process is complete, and if this happens while you’re out, your team can be stuck with a central file that is ‘in use’, and be kept from saving/working.
Always use the Worksharing Monitor (WSM), and consult it before hitting the Sync button.
This will save you and your team time by not making Revit slowly wade through two or more concurrent SWC attempts. Wait for an opening in the WSM, and then sync. And yes, WSM will work in a Citrix Revit session.
Always use the Sync and Modify Settings command, so that you are presented with the dialogue to release borrowed and owned elements.
Check all available boxes when syncing (with the exception of the Compact box), so that all objects and elements are returned to the central file.
Add comments in the field provided. These comments are helpful in tracking down problems that may occur from time-to-time in the model. Short, concise descriptions of work are all that is required. This is a problem solving tool, and not a means for assigning blame (as some believe).
Always save locally when prompted. SWC when prompted when working alone, or after consulting the WSM on small team projects (2-5). For larger projects, consult with your project’s BIM Coordinator. On larger projects, there may be a SWC schedule to follow, usually set in 30-120 minute increments depending on project, team, and model size, or during deadlines.
Over-communication with your team is far better than poor communication. Utilize Jabber (or other instant messaging application), email, your phone, or your voice, and make sure you and your team are all on the same page.
Monday, 24 March 2014
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:
- Delete/hide the filled regions before exporting;
- 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;
- 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.
Monday, 17 March 2014
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.
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
- 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!
- 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;
- 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;
- Include proper materials!
- Use Type Catalogs instead of making a plethora of individual families. It is more difficult for you, and for us, to manage them otherwise;
- 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?
Wednesday, 12 March 2014
The folks in the UK at Bond Bryan Architects have created a list of numerous resources available on COBie – Construction-Operations Building Information Exchange. What is COBie? Check here first, and then pay a visit to the Bond Bryan BIM site for more: bimblog.bondbryan.com/cobie/