Thursday, January 31, 2013

Keep Readable

Text elements have a property called Keep Readable. This prevents the text from being displayed upside down and reorients rotated text elements so they are "readable" from left to right and bottom to top. As soon as text transitions past 90 degrees and then between 180 to 270 you'll find the text flips to ensure that it is easier to read. All of this is true for text in a project view.

In a family the text elements share this parameter but it doesn't matter if you check it or not because the family governs whether text remains easy to read. This setting (Keep text readable) governs all text, even nested label families, in the family setting.

If you are working in the Family Editor you only need to worry about this one setting to force all text and nested label families to behave, so to speak.

Wednesday, January 30, 2013

Hosted or Not Hosted

The description "hosted" or "not-hosted" that we use for component families can be a bit confusing. Technically ALL families ARE hosted. They are either hosted by a level, a wall, a ceiling, a floor or a face (surface of some element). When we say not-hosted or non-hosted we generally mean that a family is not specifically associated with a certain host element like a wall, ceiling, floor or face. A chair, desk and various other families across many categories are "not-hosted" though truly they ARE hosted by a Level. They can sit on the floor or are free to be above or below it by altering their Offset parameter.

I often think that it is a disservice to spend time calling them just one or the other. It seems more explicit to use a family name that describes what host is required. A family called, "MyCoolFamily-hosted.rfa" might be better called "MyCoolFamily-Face.rfa" or "MyCoolFamily-Wall.rfa" or "MyCoolFamily-Level.rfa". We could reduce it to a single letter designation. For example the families could be named "MyCoolFamily-W.rfa" or "MyCoolFamily-L.rfa". What if the file extension allowed for this subtlety so the names are not affected by it? Extensions for families could be .RFF, .RFW, .RFC, RFF... Uh oh floor and face both are "F" we could use S for surface instead of face?

These different placement methods also mean we have to be careful to consider what sort of hosting nature a family has before we start placing it. We have to resort to reading the family name and/or glancing at the ribbon for any placement options to figure out what the family expects us to do. It would be great if a family could be assigned to a primary placement option. For example, light fixtures usually want to attach to a face, not the vertical face option we are offered by default. Ideally we could specify the hosting priority for each family and use the ribbon only to choose an alternative when those rarer situations happen. Maybe the ideal spot for this parameter is in the Family Category and Parameters dialog, like OmniClass and other settings..

Just writing out loud...

Tuesday, January 29, 2013

Revit Systems and Daycare

You probably wouldn't put those two in the same sentence? Imagine a daycare center with a hundred children running around and no supervision. Now imagine the same thing but put ten adult teachers in the room. It is probably not nearly as chaotic as the first situation.

Now change the center to Revit and the children to MEP component families. Without assigned systems it is much like that unsupervised daycare center. Each system functions like a teacher or parent assigned to several specific children to keep things organized. Ultimately this allows Revit to function more efficiently.

Isn't it interesting how effective the use of family and people concepts extend to Revit ideas and features.

Monday, January 28, 2013

Tag on Placement Quirk

My friend Tom wrote to me the other day asking if he was crazy or if I could confirm that Revit 2013 has a quirk when placing a light fixture in a ceiling plan. Well he isn't crazy, at least not about that. It isn't just for light fixtures either, seems to be for any component. When placing a component in a floor plan view you get this ribbon configuration, or close to it.

When in a ceiling plan you get this version...sans "Tag on Placement".

Seems unfair to me. There was a recent Hotfix posted for Revit 2013 but it does not appear to address this issue. I demand equal opportunity for Tag on Placement!

Wednesday, January 16, 2013


Earlier I wrote that Harry started a blog (Boost Your BIM) focused on using the Revit API to enhance your projects and process. He created his first formal application, Image-O-Matic, which is now available on the Autodesk Exchange. When I first saw it I thought about using it to document testing family parameters and types.

He decided to run a contest to encourage Revit users to get acquainted with the app. He offered up a tantalizing video of Marcello Sgambelluri's work to get your creative urge going. Visit his site for all the contest details. Here's an embedded copy of the video he posted.

Tuesday, January 15, 2013

Omniclass and Uniformat Selection

It would be nice if we could search for keywords when attempting to assign the parameters for both Omniclass and Uniformat. Sometimes the best category to use in Revit isn't necessarily the correct category in these classification systems. This means a fair bit of time wasted hunting for an appropriate value. I search the source files to find keywords first which isn't the most straightforward.

Monday, January 07, 2013

Copy Monitor and In Use Element Types

When you edit the Options for Copy/Monitor doesn't give any indication which of the families that show up in the lists are really used. This means you can assign elements unnecessarily.

In some cases it seems somewhat apparent which are used or not. In the first image the Level type actually used has a slightly different options than in the second image, which is the level type not used.

It would be cool if Revit identified the elements and types that are actually in use in the linked file, at least without having to read between the lines.