Eccentricity of Wall Footing

I replied to a thread at AUGI regarding the Eccentricity parameter of a Wall Footing. They observed that Revit seemed to ignore their input and didn't understand what it was meant to do. In this case the width of the footing was less than the value they entered.

The parameter is intended to shift the footing over, from interior to the exterior face of the wall. The footing starts out centered on the wall above.

The maximum eccentricity is equal to (Footing Width/2)-(Wall Thickness/2).

The interior wall surface can be aligned (flush) with the interior face of the footing but not further, creating any overhang of the wall, which seems logical to me. A picture might help?

Create a Local File - How Often

Every time...

I no longer reuse Local Files. My attitude and habits have changed a little over the years. I wrote this POST in 2008 and then THIS on in 2011. I've touched on the subject many times within the context of other workset related posts.

I treat my Local File as ephemeral...temporary... I make use of the Open File option Create New Local each and every time I start working on a project again; yes even if I just stopped working earlier to have lunch or join a conference call.

Revit Viewer

Yes it still exists.

I've been doing some work with Autodesk as a Revit Mentor helping users navigate their 30 day trial. One of the recurring themes is, "I only need Revit to view other peoples models. How do I do that?" In the old days a version of Revit that lacked a license turned into viewer mode. At times that proved a bit dangerous because a user could lose a license (network issues or internet access) while working on a model and find themselves in Viewer Mode and unable to save work they ordinarily could, should be able to.

To counter that situation we now have a separate application that is Revit Viewer. It's installed alongside Revit, wherever you decided to store it on your computer. In my case it's listed like this when I search in Windows 10. FWIW, I don't put any icons on my PC's desktop so that's how I start everything, click on the Window...type a few letters, launch an app. It's the illusion of an uncluttered mind! My actual desk...well that's a different matter...

When you run it you'll be greeted by this message before it will finish opening and let you open a project.

It is worth stressing that the limitations the dialog above describes kick in as soon as ANY change is made. I frequently hear, "I can't print in Viewer mode". That happens when you change the model, to which they reply, "I want to print using a different titleblock, I switched to a different one".

Yeah, that's a change...

It doesn't matter how minor or subtle a change is, the key word is change. If you move a tag, add a dimension, put a view on sheet, change a view's scale, a view's detail level...yeah those are all changes. Trying to print (or save/export) afterward will cause Revit to pop up the dialog above again. If you get the dialog, use Undo until the action you want will work. Most likely you'll have to undo everything you've done just after opening the file.

I should clarify, using Viewer won't allow exporting to formats that can be modified (that is part of the license warning message). That means Viewer can't be used to export to DWG, DXF, IFC etc. We can use Viewer to Print or Publish to DWF.

Temporary Dimensions and Activate Dimensions

I've written about Temporary Dimensions and the Activate Dimension button in the past (2007-9), these are some posts that discuss them.

Space Bar Subtle Effect on Temporary Dimensions
Dept. of Reviteristics - Activate Dimensions
Activate Dimensions
Activate Dimensions - Redux

Temporary Dimensions don't appear when two or more elements are selected. When that happens you should see the Activate Dimensions button appear on the Options Bar.

Temporary dimensions also don't respond to families that host nested shared families. That's because these families are also regarded by Revit, under the hood, as a selection of two or more elements.

Revit 2016 R2 - Changes to Underlay

They've reconfigured the Properties Palette and changed how they describe and provide access to the Underlay concept.

As you can see above, the Underlay concept now has its own Group Header in the Properties palette. They've renamed the Underlay parameter itself to Range: Base Level. The new Range: Top Level is a read-only value that just reports the next level above the Base Level. That can be helpful when it isn't the one you expected, for example when there is an intermediate level for a stage .

Keep in mind that if a view is created for a level we can't prevent that level (like Stage above) from being the next one, the one that appears in Range: Top Level. I think it could be better if a Level's Building Story parameter could influence this condition so a view could exist for the level but not be factored into the Underlay's display process, allowing it to skip past or ignore the Stage level.

The Underlay Orientation parameter kept its name but the words used to describe its choices are now Look up and Look down. The plainer language seems to help people understand what Underlay is really doing. At the very least Look up is more accurate than implying it is really generating what we have learned is meant by Reflected Ceiling Plan.

Also very worthy of a mention is that new plan views have their Underlay - Range: Base Level assigned to None instead of the Level Below like in earlier versions.

Hmm, writing that last section, it occurs to me...this feature used to just be called Underlay, a parameter AND concept on its own with a second related Underlay Orientation parameter. Now we have a concept of Underlay with three parameters.

Experienced users will now confuse new users by asking them, "What's the view's Underlay assigned to?" or telling them, "You need to change your Underlay setting."  ...ah progress...

Oh, and Hat Tip to Niklas Strannefors, an Autodesk Application Engineer in Sweden, for prompting me to write about this subtle change.

KeyNotes - You Keep Using that Word...

A recent exchange went a little like this:

Them: "Steve! I need some help with my keynotes!" Me: "Okay, how are you doing them?" Them: "Huh? I just drag this family from the Project Browser and place it in the view. When I look at my keynote schedule I don't see the keynote being added."

When software uses the same word we routinely use to describe something we do it is supposed to make it easier to understand and use. Sometimes the opposite happens, as in this situation the word Keynote or the practice of key noting  (keynoting). A good many of us in the AEC business are familiar with the concept of using keynotes on drawings.

I find it interesting that I didn't find a definition readily available on the interwebs for what we do with and call keynotes. There were lots of trade specific sites but not the traditional dictionary or wiki version. Most refer to being the keynote speaker at an event or related to music.

Regardless, for us it is a system to reduce clutter on drawings by placing symbols that either carry numbers or letters or both to identify different conditions that we should look to a separate place (key, like a map key to symbols) to read more information. Ideally it means we get drawings that are cleaner looking instead of the clutter of long descriptions nestled among the graphics that describes the building itself. It's also a way to help reduce the chances of making spelling errors or stating things differently because more than one person is usually involved in the process of completing drawings.

In Revit there are three ways we can apply keynotes to drawings. First we have a formal tool called, not surprisingly, Keynote. Second we have an older slightly less formal technique using a Noteblock Schedule based on a Generic Annotation family. Third we have the old school approach where we use a Generic Annotation symbol and then separate Annotation (lines) and Text elements to provide the appearance of a formal schedule we are familiar with.

I've often referred to the Keynote feature as the rich man's keynotes because it requires ongoing rigor and advance planning/effort.

We have to manage an external keynote file (TXT) and use specific annotation tags that work with this external data. Our families can each store a keynote parameter value (which a tag reports) and we can create ad hoc User Keynotes too. Keynote Schedules can (a Filter option) display only those that appear in the views that are on each sheet, a distinct advantage over the other techniques.

In the image below I'm using a cool tool called Keynote Manager to review keynotes. We have to organize the information that we want to be available for keynoting ahead of time or at least be prepared to stop and start when we realize we are missing something. The external data and process is more formal and rigorous. That's why I've observed it is also poorly adopted.

When we combine this process with Keynote Legends on sheets we have a consistent and predictable structure for keynoting activity.

In contrast the Noteblock approach, which I've often called the poor man's keynotes, depends on data stored in specific Annotation Symbol families.

It does require some rigor but not quite as much as the formal Keynotes tool and there is no external TXT file that keeps the data consistent. When we create a Noteblock Schedule we have to choose the correct Annotation Family to base it on. Then the schedule reports how many instances of that annotation family (symbol) we place in views, that are then placed on sheets. These are much harder to filter so we only show those that relate to specific views on sheets, there is no built in feature to filter them.

The third approach is not really any different than how I've seen it done for many years with CAD and hand drafting before that.

We place symbols, change the number/letter and then later create a legend on the sheet that provides a summary of the keynote symbols we've placed in the drawing. We examine the drawing and make an entry for each symbol we observe on the drawing. It isn't hard to do but it isn't fun and very error prone, especially as the project progresses and changes occur.

Referring back to the exchange at the beginning of the post, it turns out that the technique that was being used was the last one, symbols, lines and text. It helps a lot to figure out which technique is being used before launching into helpful responses that assume either of the other two possibilities are in play.

Wish - Insert From File - Work with Templates

Insert from File allows us to import views from another project, views like schedules, drafting views or even sheets that contain either. It is biased toward RVT files though.

It would be handy if it we less biased, enough to include RTE (Revit templates) too. Since we probably have standard stuff set up there anyway. Doing so would allow me to acquire a view from a template file instead of having to first save one as a new project or find another project that is already available in a project folder elsewhere.

Shared Parameters are Shared Definitions

We tend to think of Shared Parameters as a thing, equal to Family and Project parameters. I've even described them as such in past posts on the subject. If I'm very picky and technical they are not a thing, they are a device, a parameter definition, shared to either create a family parameter or project parameter or both.

Yes, they help us create a Family or Project parameter, but on their own they are nothing, they only exist in a text file. That text file only defines their name and data type, nothing else. Okay technically the file has a little more data in it than that but it's only used internally by Revit. It doesn't mean they have standing or truly exist on their own. We have to apply them to Family/Project parameters for them to mean something, be something, be useful.

Written another way, a family parameter (either component or system) can be created from a shared parameter and a project parameter likewise but there are no shared parameters that aren't one or the other.

This is why I regard them as a definition stored in a dictionary, the Shared Parameter file.

View Discipline

Daryl wrote on Monday that the concept of View Discipline isn't documented well. Software documentation tends to be a bit dry, too often a very literal, "Un-checking this turns the feature off". Well that is obvious but "why" would I want to turn it on or off? Unless it is truly self evident, why a feature exists is a bit more involved but much more satisfying help.

The concept of View Discipline appeared with Revit Structure. It was meant to make it simple to alter the appearance of our model to be more in sync with what a structural engineer wants to see. When MEP (Systems as it was called then) appeared a year later they extended the concept to Mechanical and Electrical (plumbing lumped in with Mechanical till release 2013).

Daryl used plan views as his example of how the help documentation isn't accurate. Plan views are not the best view type to see the truth in the help claims. Ducts for example, he wrote, don't show up when the architectural discipline is chosen. They CAN show up, they probably won't be visible because they are above the cut plane. When Mechanical is assigned Revit changes the nature of what plan and reflected plan mean. Ducts at 10'-0" AFF will appear in a plan view with the view discipline Mechanical assigned. They won't with Architecture. They are there, just above the view.

This subtle change occurs because the notion of a plan and reflected plan view means slightly different things to architects and engineers. A reflected plan, architecturally, means that elements that are lower mask elements that are higher, such as a ceiling and light fixtures mask elements above that ceiling. A HVAC plan is different because most engineers want to see the highest duct masking lower ducts. It isn't a reflected plan, it is a plan whose cut plane is, in a way, altered to be above the highest elements and "look down".

Technically the view range settings can be identical but switching to mechanical discipline will show ducts that weren't there a moment ago when architectural was assigned. They were there but the discipline change altered how Revit calculates the display of the elements. Engineers don't generally do reflected plans so Revit made it easier to generate regular floor plans that show their elements in a way they expect to see them.

The combination of View Discipline, Object Styles, Visibility/Graphics Overrides and View Range are all responsible for what we see in a given view (technically there are more). Changing one of them is not going to ensure that we see what we really want. We've got to make sure they all have complimentary settings. There is no real difference between Mechanical and Electrical disciplines graphically, based solely on the View Discipline parameter changing. The views dedicated to each of those disciplines also use V/G and possibly view range settings to make them look correct. If you examine the stock templates you'll find that these views have each others element categories turned off (with V/G) to achieve the look we are after. Apart from the automatic graphically biased changes they make, they really just help us segregate views in the project browser.

In my own way:

Architectural - All model elements treated "equally", according to Object Styles, but with architectural bias with respect to view range and cutting elements.

Structural - Similar to architecture but hides non-load bearing walls and some hidden line behavior with respect to concrete floors/slabs and foundations.

Mechanical - All other disciplines are half-tone and transparent (help says "on top"), duct and pipe and related element categories take priority and behave according to Object Styles. Mechanical elements like duct and pipe will appear in plan regardless of their true elevation with respect to view range, as long as they are within the Primary Range.

Electrical - Same as Mechanical.

Plumbing - (new to 2013) Same as mechanical.

Coordination - Same as Architectural but provides for segregation from it for easier management of views.

Then there is the Sub-Discipline parameter, a Project Parameter that first showed up in Revit MEP templates. I see architecture firms, that have been exposed to RME, using the same parameter now in their architecture templates because of the added (for consistency as well) control over the Project Browser sorting. That's the essence of the parameter's existence, to manage the Project Browser according to the kinds of views each discipline typically creates. Such as Power and Lighting plans for electrical and HVAC Duct vs HVAC Piping.

Keep in mind that views in stock project templates are also configured to only show certain element categories according to the discipline bias implied by their name and discipline parameter setting. The combination of the View Discipline parameter and Visibility/Graphic Overrides is responsible (among other possible view properties) for the final result of what you see in a view.