Controlling a Solid Form with a Visible Parameter

Here's a video trip back to a basic family editing concept. It describes two solids, a cube and sphere. I assign parameters to their Visible parameter and then show how we can use a formula to toggle one of them on/off and using Family Types to manage them. This works fine for solids, voids are another matter...and the subject of a later video.

Phases and Phase Filters Follow Up

I received a comment from a reader asking how to show all the elements in a view after having done the demolition work. The Phase Filter Show All should provide this however in this case they were attempting to show everything from a later phase. In this scenario there are three phases: Phase 1 (existing), Phase 2 (new work) and Phase 3 (the view they want to see things from).

That poses a problem because the earlier work (demolition and temporary) will not be displayed anymore because it is "gone" when you move forward in time to a view assigned to phase 3. This image is of a 3D view that is assigned to Phase 2 using Phase Filter Show All.

In Phase 3 items that were created in Phase 1 and 2 are both regarded as existing now, as long as they were not also demolished since they were created. Once they are demolished they no longer "exist" as far as that View and Phase Filters are concerned. This is what we see in Phase 3 with Phase Filter Show All.

To show all the proposed work together, Phase 1 (existing) and Phase 2 (new work) should be sufficient. In a view assign it to Phase 2 and use Show All Phase Filter. It is important to understand that elements always belong to a particular phase but their appearance (controlled by Phase Graphic Overrides) is affected by the Phase settings of the view they are seen in and that changes from view to view.

We really can only see all elements, including those that have been demolished or are temporary from a view assigned to "now" and one phase further in the past. Any further in the past than one phase and those demolished and temporary items are no longer part of our virtual world.

Starting my Project after Receiving a Model

From a Revit MEP or Structure perspective getting a project started, without delving into subtlety, should look something like this.

• Link the architecture model - Auto - Origin to Origin
• Examine an elevation - Make sure your levels match theirs (it's also helpful to get a better sense of the scope vertically)
• Use Copy/Monitor to create (levels you don't have) and watch the levels for coordination (optional but a good idea)
• Room Bounding (MEP) - The arch link has a Type Parameter called Room Bounding, this should be checked if/when you are using Spaces
• Create views for each level after you've made sure yours match theirs
• Repeat this for each discipline, HVAC, Plumbing etc...
• Phases between files should be mapped (same place as Room Bounding, and to truly work they need the same names too)
  
• If you need your own grids to adjust how your documents look - use Copy/Monitor to get a watched set of your own grids

As I alluded to in the beginning, there are other subtle things like worksets that can factor in as well, but assuming the above is all done, you're ready to start adding your own work.

Revit and AutoCAD

It's been 14 years since Revit formally began knocking on the doors of architectural firms. The first response quite often was, "We've already got {insert your software here}, no thanks"! Other responses were, "Really? Let's have a look"! Which was then followed by "Oh gosh, you mean it doesn't do "X" just like {insert your software here}? Well thanks for coming by, good luck"!

As Revit matured there were fewer opportunities for showstopper items. The rejection response or yeah, but response also matured to focus on the practical side of changing an office from this to that. Such as, "We've got all these people who are {insert your software here} experts. We can't justify the time and effort required to move to Revit". Another familiar one, "We've got a decade of {insert your software here} detail and object libraries, we can't possibly be expected to do that all over again." Revit Structure was introduced (2005) and the conversation began again with engineers. A year later Revit Systems (now MEP) started the same dialog for another set of engineers.

When Autodesk decided to buy Revit Technology Corporation they confused many of their own customers who, until then, were using AutoCAD or Architectural Desktop (aka ADT, now AutoCAD Architecture aka ACA). I think Autodesk has a curious relationship with its customers. All too often I meet (and read people's writing) who, regardless how much they like the software they use, are at best ambivalent about being an Autodesk customer, at worst resentful or angry.

Witness some of the comments in response to my earlier post about Revit 2015's new features. Accused of being a monopolistic company or evil empire, we even joke that friends have joined the dark side if/when they are hired by Autodesk. I'm not sure what they can really do to alter this perception, except to suddenly offer their software for free? I suspect the stockholders might object to that move.

With that in mind, it has taken a formidable marketing effort to get Revit where it is today. In my opinion the phrase Building Information Modeling (BIM) was born in part because Autodesk desperately needed to differentiate ADT/ACA from Revit, at least as BIM is defined and expressed by Autodesk. The notion of using computers to help accomplish the broad goals of BIM is nearly as old as computers so it's not a brand new idea.

And yes, other companies lay claim to the doing of BIM and living up to BIM ideals too. It (BIM) just wasn't on the lips of AEC professionals or their clients the way it is today before Autodesk began expressing it in conjunction with Revit. This means Revit was the latest expression of those ideas on a desktop computer instead of a mainframe. Marketing is the telling of a compelling new story to motivate people, to consider changing how they do things, to buy things. Like them or not, Autodesk has done an earnest job of telling the story of BIM and Revit.

One of the many stories we've heard that was meant to help us in our transition was how easily Revit worked with other CAD software's data. Revit was the new kid on the block. What chance did it really have if it couldn't import a DWG or DGN file? Being able to import external data was meant to ease the collaboration with firms that didn't use it as well as the transition from other software.

All these years later I keep reading, "It is necessary to use Revit AND AutoCAD", or "Revit can't be used productively without AutoCAD" or "...since AutoCAD is a superior drafting tool it isn't sensible to use Revit for basic drafting tasks".

It is NOT necessary to use AutoCAD if you use Revit. The error (thinking that it IS necessary) is mistaking necessity with what is merely an available interim approach as we work through the transition from AutoCAD to Revit.

Using AutoCAD to do detailing is NOT optimal because doing it entirely within Revit is integrated within the project more tightly and logically. If you are not efficient drafting in Revit then the implementation is not effective, but it could be. That's not Revit's fault, it is our fault (though it could always ship with a larger stock library). If you'd like some examples of Revit details that are devoid of lines/circles/arcs/text have a look at ARCxl's free samples. If you are looking for a shortcut to build that better implementation then their library might a place to start.

To some degree the perspective, "It's better, faster to draw details in AutoCAD" is a mind over matter issue, not a software issue. We tend to ignore or forget the reality that we've been changed by {insert your software here}, not the other way around. The software doesn't change to suit us. Our use doesn't change the software, we change in response to how it works. If we are fast then it's because we've grown accustomed to it, learned tricks, customized it, built our own library and so on.

It's no different whether we are talking about AutoCAD, Revit, Excel or Word. We do influence what the developers code into the software but we respond to the software and then provide feedback, not the reverse. The only exception is when no code exists and the software is in its infancy. Once code exists we are always dealing with legacy decisions.

When we say that {insert your software here} is faster or better than Revit it really means we know it better, we are more comfortable with it. There was a time that I'd agree I was faster with AutoCAD or Microstation than Revit. That is far from true today. In fact I find AutoCAD to be a very frustrating experience now.

Faster is also a subjective term. What context? Faster sketching a single line? Faster creating an entire detail? Faster for whom? Me myself and I? What about downstream members of the team? What about the hours of design and investigation required to decide what to draw? What if another section is required to figure out what is required to finish that detail? What if the Revit modelling activity helped inform the decisions? What if the ability to create more sections automatically or have a look at the model in 3D provides more insight?

The further we can step back from our experience and bias with a given software the easier it is to see they are all flawed in some way, Revit included. I clearly remember realizing just how convoluted AutoCAD is when I began supporting Microstation users that had to start using it (AutoCAD) instead. They'd just shake their heads at the quirky rules and methodologies that were in stark contrast with Microstation's own quirky rules and methods. They are ALL quirky. Some quirks just happen to match our own thinking or approach better than others.

As for our legacy library of details, we forget or minimize the fact that it didn't happen overnight. It was built project by project. Remember, all the previous details were drawn by hand, right? At this point I think it's a safe bet that, like most libraries I've seen, it could stand some careful weeding or pruning anyway. Maybe it isn't so precious that we can't consider creating Revit native versions now? The sooner we do the sooner each project can be better integrated.

If you take anything away from this post at all I hope it is this:

It is NOT necessary to use AutoCAD to be productive with Revit. Revit does NOT need a software crutch to be useful or a productive good decision for any firm. The longer you pretend that it does or is, the longer you prolong not being as productive as Revit was intended to help you become.

Creating Door Families

Long post warning!

I wrote supporting documents for two presentations I did about using the family editor and creating door families, they are:

Autodesk University 2005 Session BD21-1L: Autodesk Revit Building Family Editor: From the Beginning (using Revit 8.0) - Download It
Central States Revit Workshop 2013: A Door's Life (using Revit 2013) - Download It

I also wrote an earlier post here and shared A Door's Life as a Box embedded document.

I recently responded to questions about the techniques the older handout describes and then, as the thread grew, later criticism at RFO that my second document does not live up to their experience with the original. The following stream of consciousness is, for the most part, my reply there. I have rewritten parts of it so hopefully it makes sense here apart from the thread at RFO.

If you work through each document, or have already, the following describes what I experienced writing the newer version; why I didn't find it practical to just "refresh" the original, though I did start out thinking I could just do that. I started by opening the AU 2005 BD21-1L handout word documents and using Save As. Fwiw, that document was created using Word's Master and Sub-document concept (think Xref's for Word), each section is a separate document linked to a master for formatting, style setting and page numbering.

When I first started pondering (over 18 months earlier) what became "A Door's Life" I was thinking about a session for RTC in Europe. Coincidentally I received two suggestions via email within a couple weeks of each other recommending the AU 2005 handout should be updated. One even said he'd do it and submit it as a class for AU, asking if I'd have any objections. I wrote back that I didn't have any objections. I don't think he did it though, at least not that I'm aware of.

Reviewing the original outline I added the section about nesting hardware because its more common outside the USA to include hardware in door families (thinking about RTC EUR). I decided to remove the section devoted to creating the nested variable lite panel family with voids because, during the eight years of work and travel I've done since the lab at AU, I've never met anyone actually using it (until the thread at RFO). It's a relatively complicated and labor intensive part of the document too.

In its place I described creating two simpler nested panels, one derived from the first since that's how many firms actually end up going through the process. This also meant I could put the more relevant (especially in 2013 than 2005) clearance form (part of the nested swing) and hardware section in without increasing the page count too much. When CSRW submissions were requested I was already restructuring the handout (it is in imperial units) and I decided to use it for their workshop instead and took a different direction with the RTCEUR session. After a bit of reformatting it became a CSRW session and I finished it.

As such, the final form of A Door's Life is based loosely on the CSRW template, I started with it but I took some liberties. The AU 2005 BD21-1L handout is 48 pages and the font is primarily Arial 11 and based on the AU 2005 template. In contrast A Door's Life is 80 pages (3 pages are the Table of Contents, no ToC in AU BD21-1L) and uses the fonts; Calibri 11 and Cambria 10 (for lists). As a result the appearance is certainly different (see next image).

The tips (and additional comments) are a burgundy color to fit the color of the CSRW template graphics (see left image).

Doing the writing and editing I was immediately confronted with images of the Revit Building 8.0 user interface that included the Design Bar, Menu and Toolbars. When I finished the work I'd ended up replacing nearly every image. Even images that didn't need to be looked so out of place against the new interface that I often chose to replace them anyway. It's like remodeling a room that is connected to others. Improvements in the room make the other rooms look shabby.

There are also the feature and language changes from 2005 to 2013. Every instruction and description that referred to Design Bar tab, Menu or Toolbar had to be replaced with references to ribbon tabs, panels, buttons, properties palette, and other subtleties. There are also new, perhaps better, choices for how to offer some instructions, via right click, palette, view control shortcut bar etc.

There are changes in Revit itself like the behavior of the nested swing family. Between 2005 and present day the swing technique described in the 2005 handout doesn't work anymore. It's necessary to constrain it a little differently, the text of the old process had to go. The nested swing in A Door's Life has more features to describe as well. The clearance form section nearly takes up as much space as the panel/void section did in the AU 2005 handout. The clearance form describes a much more valuable lesson, in my opinion, about constraining sketches as well as the whole concept of clearance forms which isn't part of the original at all.

I think its worth mentioning that over eight years I've changed. I've been affected by the people I've met, taught and all the work I've done since. I've learned a lot more about Revit, this business, writing, editing, document formatting etc. I've done technical editing for two Revit books (beginning another now) and contributed chapters to two editions of another. My opinions and approach to writing and describing things has changed, evolved. I'm a different person than I was in 2005 and I learned a LOT from doing that lab too. I find it hard to imagine I could look at work I did eight years ago and be satisfied with "Save As"...and I wasn't. I also did not intend or expect either document to define a singular process to build "your" perfect door family. I hoped to describe the techniques that can be used together or separately to help organize anyone's own door library and all the concepts apply/extend to any other content easily too.

I closed my response in the thread with "I am grateful that you've found the original document useful and worthy of the praise, that it deserves to be updated. I won't hide my disappointment that you find the newer version not as worthy of your praise. I guess what they say about sequels is really true."

Keynotes By Keynote vs By Sheet

If the choice is a little confusing perhaps the following explanation will help a little?

By Keynote uses the number of the keynote based on your keynote file.

This means a sheet can show keynote value like: 101, 204, 302, 601 etc. These aren't "sequential" in that there are gaps between numbers based on keynotes that exist but not used in any views on the sheet. This can result in questions from a contractor like: "Are keynotes 102-203 missing?" This approach also works best when you really want a keynote "number" to be consistent with another reference document, like specifications (CSI numbers).

By Sheet requires the view with keynotes to be on a sheet to receive a number.

This allows keynote values visible on a sheet to be sequential, 1, 2, 3, 4 etc. If a keynote tag is empty then that view has not been placed on a sheet yet in order to determine what number it should receive. This also means that a keynote for Gypsum Wall Board may be numbered "3" on one sheet and "15" on another, all depending on how many other elements have keynotes applied. This approach reduces the likelihood that a contractor will ask about "missing" keynote values. This works best when it is more important to provide sequential numbering unique to each sheet.

Rotate Tool

When we start the rotate tool the first task is to decide if the origin of the rotation is correct. Revit usually places the origin at the center of the extents of the selected elements. Put another way it's rarely where we really want it, but then how could it really know what I want. We've got three techniques to choose from to put the origin where we want it:

• Place button (Options Bar)
• Space Bar (equal to clicking Place button)
• Click + Drag the origin icon.

Using the Place button or Space bar we just have to click where the origin ought to be. Using Click + Drag we need to click on the origin icon (left mouse button), click + drag it to the correct location.

Once we're satisfied with the origin we can enter a specific angle value on the Options Bar and press the Enter key. The rotation uses a counter-clockwise rotation from 0 through 360 degrees. Entering 45 degrees will cause this wall to end up like this. To get the reverse we just provide a negative value instead.

If we prefer a more visual approach we can rotate by defining an angle with two clicks. The first pick/click defines the start ray of an angle and the second the end ray. If we know the angle value we can just type the value after the first click (start ray), the listening dimension that appears when we move our cursor away from the start ray will accept the value. If we are attempting to rotate elements based on other elements then we just need to click on them with the start and end ray pick/clicks.

An often overlooked option is Copy, located on the Options Bar. This turns Rotate into Rotate AND Copy. Just remember to check the box for Copy before you make your last Pick/Click to define the angle of rotation. Edit: Andreas reminded me in a comment that we can activate the Copy option by pressing the CTRL key. Lot's of subtle options for just one little command eh?

Adjusting Automatic Sketch Dimensions

When we are working on families Revit hides Automatic Sketch Dimensions (ASD's) from us unless we use Visibility/Graphics to turn them on (Annotation Categories tab). Revit guesses are often close enough when it creates ASD's. For example the profile of a skirt/apron beneath a table top is adequately constrained by the ASD's in this image.

When I add another sketch inside the first to define the thickness of the skirt/apron Revit guesses correctly again. If you select ASD's Revit doesn't let us delete them. If we add our own dimensions and either assign a parameter or invoke the EQ or Padlock constraints Revit will remove the corresponding ASD.

If Revit places a ASD incorrectly we can change what it's referencing. Select it and click on the witness line grip (dot icon) and drag it to a correct reference. For example, in this image Revit guessed that it's more important to reference the Center (Front/Back) Reference Plane. That's not what I had in mind.

In the little bubble of the image I've revised it so that the ASD is referencing the correct elements. Revit will respect this change unless we change the family and cause it to revisit the constraints, such as deleting a form or altering an existing sketch. Remember to keep an eye on ASD's.

Finishing Text

I read a post at AUGI tonight that mentioned using the Modify button on the ribbon to finish typing or editing text. The intended technique to finish typing text is to click out side the text box. If you look at the Status Bar when you are typing text you should see this instruction: "Edit the text and click anywhere in the view to finish editing".

In my opinion "anywhere" isn't accurate, technically you have to click anywhere but within the text box. I think it's more accurate to say, "click outside or away from the text to finish".

The complaint in the post was that using the Modify button sometimes results in the text vanishing. It is still there but not visible until you manage to select it again or refresh the view or do something else that refreshes the view. I find that the text vanishes IF I am creating the text and click Modify. If I just edit existing text the text doesn't disappear when I click Modify to finish.

I don't think clicking Modify is "intended" behavior or that it is supposed to properly finish editing the text. It does work if we've begun typing some text, or edit some text. If we've only clicked on screen and then click on Modify the "empty" text box is not left behind. A similar result will occur if I just start another command like Wall, or Door. My observations are based on using Revit 2014.

I'm sticking with the intended "...click away from text to finish...".

Opening Views

This is an echo of something I wrote in 2011.

If you are in a plan view, when you open a new floor plan view (any "plan" view) Revit will attempt to respect what you were just looking at in the previous view. For example, if you zoom in to look at a specific room or door family and then open a floor plan for another level, Revit will open the new view zoomed to the same area of the model (but on the other level).

As another example you might have two floor plans, one for furniture and one without. If you are looking at the furniture plan, zoomed in to see a single room and then open the other floor plan for the same floor you'll find Revit opens that new view focused on the same place.

The key is the view you open can't already be open, just in the background. I've posted a video to explain visually...

If you are in the habit of closing hidden windows then this can be quite effective as you transition from one plan to another.

Where did these Rooms Come From?

When you examine the Options Bar while the Rooms command is active you may find something like this image.

Rooms in that list are "Not Placed" but we (someone) may have created them by placing a room and then deleting them later. They could also be left over from when the project template was created, rooms that were created along the way but not eliminated before turning the template over to the project teams. Rooms are to be managed with schedules. We have final control over the reality of a room there. If we don't want them in the list on the Options Bar we can either place them where they should go in the model or delete the room's row in the schedule.

Deleting a room in a floor plan does not remove the room from the Revit database permanently. Deleting one from a schedule does. This allows us to move a room to another location or another floor without recreating the information. I can delete a room on the second floor (in a plan view) and then use the "Not Placed" record of this room to put it where it should go on a different floor. If I decide I don't really need a room I can just open the schedule and delete it for good.

For some background, Revit allows us to create a list of rooms prior to any actual walls defining where they could go. Imagine having a meeting with the client and they give you a list of rooms they want or need. You can create a basic room schedule with number, name, and area for example. Then each time you click the New button in the Row panel Revit generates a new "Not Placed" room. Repeat and fill in information until all of the project's program information is entered. Now as users create walls the room are "waiting" to be placed where they should go.

By the way the same things are true for the Area and Space elements.

Undoing the use of Clear Cell in a Schedule

I wrote a post in June 2013 that describes the new feature for Revit 2014 schedules called Clear Cell. This allows us to separate the view name in the project browser from the name we see in the schedule header. I got a comment on that post yesterday asking how that can be reset or undone. It's pretty simple though not obvious perhaps. It boils down to putting a parameter into the header instead of the text we used after using Clear Cell.

To reset the header, while in the Schedule Editing mode/view, click in the Header field, notice the Parameters panel on the ribbon?

Click Category: (a drop down list box) > Choose Schedule

Now click the Parameter: (a drop down list box) > Choose View Name

You should see now.

The brackets indicate that Revit will provide whatever the parameter value is. In this case its the parameter value for View Name.

Hiding Columns in Schedules

We can hide a column if necessary. Hopefully that's not a surprise. Each field in a schedule has a parameter called Hidden Field, available when we are looking at the Formatting tab in the Schedule Properties dialog.

We can also right click on a column while editing a schedule, in a schedule view, and choose Hide Column.

We can use right click to Unhide All Columns but it will reset them all, as the name implies.

If we use this on more than one column and only want to restore one of several we need to return to the schedule properties dialog and the formatting tab to uncheck the Hidden Field parameter.