Thursday, April 3, 2014

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.


Tuesday, April 1, 2014

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.


Friday, March 28, 2014

Revit 2015

What’s new?

Not much.


I give up.


Sunday, March 23, 2014

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:Brochure

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:

With IES

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 Material   IES

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:

Lamp in fixture  IES

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!).

Lamp in fixture with no IES

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:

Lamp in fixture  IES   non-metallic materials

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.

Lamp in fixture  IES   proper lens material

Lens Material SettingsJust 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?


Wednesday, March 19, 2014

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.

FamCat and Params

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?!


Saturday, March 8, 2014

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!


Monday, March 3, 2014

Disk Space (Length?)

So you probably came across these highly informative messages at some point:

SF per FT

SQM per M

What Revit is usually trying to say is that there isn’t enough disk space and it cannot sync with central. The above were displayed on the same project, whose units were set to Imperial, so I’m not sure why Revit had a metric fit there for a moment. It appears that disk space is perhaps being measured per length of track on the disk? Ah shucks, don’t try making sense of it, just know to look at how much hard drive space (or perhaps network disk space) you have next time your users get these gems!


Monday, December 30, 2013

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.

Balusters not showing in plan


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.

Supports do not align

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


Sunday, December 1, 2013

AU 2013

Are you ready for AU 2013?! I am very excited to be attending and participating once again. This year it is a little bit more special since I’ll also be part of the Global HOK BIM Summit on Monday before AU kicks off. It will be great to put some of the best BIM brains in one room and talk face to face.

This will also be the first time I’m presenting a class on my own, so we’ll see how that goes! The topic wasn’t an easy one for me to fully grasp, and I hope to make it easier for the 380 registered class attendees to understand (Navigating Through the Storm Using Coordinate Systems in Autodesk Revit). See you soon!



Thursday, November 21, 2013

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.Cannot HostI 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.

Face-Hosted family

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.