Fittings Do Not Look Right

A troublesome thread popped up at RevitForum.org the other day and DMapes came to the rescue. I haven't encountered this peculiarity before, and now that I know about it it's a bit surprising that I haven't. I guess I've just been lucky.

When you use the Underlay setting in Revit MEP you run the risk of altering the way your pipe fittings (duct fittings too in views using Detail Level: Coarse) scale and/or look. Here's a good and bad side by side.

The pipes on the left are good but those in the view on the right are smaller and halftone, as a result of using the Underlay setting.

Set to None the fittings look correct, but using the same level the fittings are associated with as the underlay equals sadness. It doesn't seem to mind if you use other levels as the underlay though. Careful with your underlay!

View Template Usage

The other day I wrote about my transition between Revit versions and differences between what we can do with View Templates. Harry "Mr. Boost Your BIM" Mattison offered some code to relieve the tension. It's pretty cool how few lines of code and provide useful answers. Check out his post. Be sure to read his post tomorrow too, he's going to enhance it a bit and share that too!

Views on Sheets

When you have to add views to sheets just the task itself can take a long time. You will find that trying to put a view on a sheet will take less time if there is nothing visible in the view. Try it. Close all the worksets and place a view on a sheet. Now do the same thing with all the worksets Open. Even a modest size project should see a difference. It isn't that surprising. Why don't more people think of it then?

If you are using guide grids to position views consistently you'll need to be able to see at least some grids or reference planes but not much else. Next time you find yourself waiting for views to generate as you place them on sheets remember to close worksets or at least reduce how much Revit needs to show while it is doing it.

Three Minutes with Guide Grids

This feature is often overlooked or dismissed but it does deliver a consistent way to mark locations to help us keep plans aligned from one sheet to the next. Check out the video demonstration at You Tube.

Insert 2D from File

I read another post this morning that prompted me to mention "another door", another way to get where we want to go. In this case James mentions using the Display Model setting for a view to only show the annotation (2D stuff) that's been added. The intention being to then copy/paste that useful stuff to another project. It's a harvesting exercise and one the developers created a specific tool for, "Insert 2D Elements from File".

This tool allows you to browse to another project, select from the views of that project and choose those that have 2D information that you'd like to use in this project. If you've ever thought, "I know there is a great detailing in a wall section in XYZ Project, I wish I could just grab it", you can!

It's brother (or sister) Insert Views from File allows us to harvest drafting views, schedules and sheets that contain either.

Filter Pesky Levels

Need another way to manage the Levels of linked files? Sure we can assign them to specific worksets and have matching worksets in our model. Sure we can edit the V/G settings of the link in views (and view templates). Here's another, use a Filter and the criteria "Structural" that is available for levels.

When you examine the properties of levels you should find the parameter Structural. If the engineer uses that for their levels and you don't, then this concept works.

Now build a Filter that hunts for levels with the Structural parameter.

This is before the filter is applied.

This is after the filter is applied.

They can do the reverse by reversing the logic of the filter, Structural = no.

Happy Filtering!

Not on Sheets

Let's imagine you've been working on your project for awhile now and your project browser seems a bit out of control. It's pretty likely it doesn't take all that much imagination.

How can you tell which views are properly assigned to sheets and which aren't? I read a post today that offers one solution using a View List, a schedule of views.

You can also use the Project Browser sorting features. All the stock Revit templates include a browser configuration called "not on sheets". It's got a filter looking for views that don't have a sheet name parameter assigned.

If that's true the view remains in the views portion of the project browser. Those that are assigned to sheets are hidden from view. If you are thinking you could do the reverse to see those views ON sheets, really no need. You can just review those by expanding the Sheets portion of the project browser instead.

In fact this segregation lends itself to the notion of using working and production views that I wrote about the other day.

If my role is documentation I can focus on the sheets part of the browser. If I put on my modeler hat then I can move up to the views part of the browser instead. The "not on sheets" browser configuration will strip out all those documentation views for me.

There is also nothing wrong with some naming conventions to help declare their purpose. I like to see user names in working views so we can chase down the person who needed it to see if we can safely remove it. I've met some who manage such things with a scheduled Monday purge of so called working views. Ever run across a project with 200 sections views, all un-referenced? Nah, I didn't think so, your project teams are far too organized and careful.

Many people also use more formal naming for production/sheet views compared with working views. Something like PLAN - OVERALL - FLOOR SIX sure looks more formal than Level 06. If you use the Title on Sheet parameter then it gets a bit harder perhaps. For those just the presence of Uppercase versus lower case can be a subtle clue to their intended use for the team.

A hat tip to a little browser organization!

Why Use So-Called Working Views

When I get to work with people that have recently joined a firm that has been using Revit for quite some time the notion of working and sheet (or production) views is often confusing to them at first. When I first started to use Revit it was just me working on models alone. I didn't compete with anyone for other views.

Enter worksharing (worksets) and now we are sharing all the views of the project with any number of other people. The first view we fight over is the Default 3D view. I want it to show shadows in hidden line with ghost surfaces and Tony wants it in wireframe with all the walls off. The first one of us to make these changes will become the borrower of the view. The other will lose out, sort of. They'll get to see their changes (some kinds of changes, not all) too but Revit won't let them save the changes. They'll see a message declaring this too.

Revit was changed to deal with this conflict better by giving us our own 3D view, adding our Revit username to the default 3D when we create one, by clicking on the Default 3D button. They saw that users were creating and specifically naming their own 3D views that way so they figured, "Hey we can code that in!".

Over time we've learned that having some specific views for modeling activities versus those that we want to rely on for putting on sheets worked to our advantage. It also led me to write about the notion of Revit Roles that I've discussed here before (Modeler, "Documenter", Detailer, and Content Maker)

If I want to change the way a specific floor plan looks I really don't want to have to remember everything that was done to make it correct for the sheet it belongs to. It is easier to just work in a separate floor plan view instead, after all a floor plan is nothing more than a specialized report of the model. Of course View Templates make it much easier to restore a view's settings.

With 2013 View Templates get more aggressive too because they can be assigned to a view and take over many of the things we can alter, forcing users to edit a template instead of just using Visibility/Graphics overrides directly. The change actually enhances or increases the likelihood that working (modeling or personal) views will be useful. Working views don't need to be assigned to a view template because they aren't intended for sharing with others, putting on sheets.

Do you have to use working views and sheet views? No. Can it help improve your project experience, sharing it with others? Probably. It is more complicated, more views to deal with (check out the post by Phil Pleiss about managing views in the project browser), but it does provide the freedom to do certain tasks without the fear of messing up things that people often feel.

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.

Revit 2013 - View Types

It is now possible to create new view types for all views except for area plans and sheet. This means you can create your own versions of floor plans according to discipline or perhaps design phase. We've been able to do this with sections, elevations and detail views for some time. As Revit's features have been merged into the new Building Design Suite "Revit" it became apparent that putting all the tools in one box created some curious view, view template and discipline control issues that had to be sorted out, thus being able to create view types for more views was born.

Further, views can be tied to view templates and have changes to a view template take effect immediately in a view or many views. We can apply a view template like before, just to make a change or we can assign a view template to the view so that it will alter the view without the past extra step of applying the view template. This is the typical assumed behavior that most people where surprised to learn did not happen in the past.

One curious thing that is documented at the WikiHelp site regarding these new view types, changing a view from one type to another does not actually apply the view template change that is assigned (if any) to the view. It is an instance parameter so it's an extra step you've got to take to make sure the view has the correct template assigned.

If you use the Apply View template option on a view assigned to view template already you'll get this message.

It's confirming that you really want to apply a different template's settings to the view. It also says that the only properties that will be altered are those that aren't in conflict with the other template. Hopefully the swapping of view types won't occur much after creating them initially and getting this sorted out. If you do find yourself needing to swap them around, just remember to check the view template assignment.

Tip: They've added View Template to the available fields in View Lists (schedule) so it can be managed there too.

Oh Where Art Thou Camera?

I wrote a post in March 2008 about this, still waiting. It would be excellent if in plan we could document where a camera is placed. Sure we can create a family to document where they are but that doesn't provide the automatic view reference that other view annotation enjoys. Seems kind of un-Revity to me, you?

If you decide to create a camera annotation how do you know exactly where it is after you place the camera? Good old "right click" will help, just select the view in the Project Browser, Right Click and choose Show Camera. Make a note of where it is and drop your annotation there.

Opening a New View

One feature of Revit that has been with us for a long time is also quite subtle. When you open a new floor plan view Revit will attempt to respect what you are currently looking at in a floor plan view. For example, if you zoom into look at a specific room or door family and then open a floor plan for another level, Revit will open the new view zoomed into the same area of the model (but on the other level). The key is the view can't already be open. I've posted a video to explain visually...

View Filter Stack Order Matters

Here's a quick reminder about View Filters, the order they appear in matters! From Autodesk's WikiHelp documentation:

Note If multiple selection filters are applied to the same view, the order in which they are listed denotes priority. The selection filter nearest the top of the list takes precedence. (bold emphasis is mine)

If you apply filters and find that you don't get the result you were after, double check the order you've applied them. You might just need to move one up or down in the list to get the result you want.

Dept. of Unfair - Move Tool is Insensitive

When they added the Guide Grid feature to Revit they made it possible to snap to Grid intersections (and Reference Planes) through a viewport. This means we can move a viewport into the same location from one sheet to the next based on an agreed grid intersection such, "A1 will be what we use as a reference location to put our floor plan views on the sheet the same way."

They added this after many years of hearing users complain about views not lining up on sheets. Me personally, I got over it early. Seemed to me that far fewer sheets were affected by this concern than the number of sheets that weren't. I don't mind having the feature but it just never bothered me. I could get things close enough that nobody would notice, especially working with real paper in hand. Granted it is easier to tell in the digital world "flipping" pdf pages or comparing a CAD file overlay. For me though, it didn't really amount to a hill of beans in the job trailer. As a contractor in the past I was more worried about information actually being on the sheet at all to be worried about whether they stacked from sheet to sheet exactly.

Oops I digress...

In order to make this possible they needed to make Revit more sensitive to the contents of the viewport when using the Move Tool. Unfortunately Revit seems to think we live in an orthogonal world because the only Grids or Reference Planes the tool "sees" are orthogonal ones. No arcs, no grids at an angle, sorry Charlie. Now it isn't hard to place a couple orthogonal Reference Planes somewhere or to choose a different Grid intersection perhaps but it would be nice if Revit was more malleable, enough to let us pick any intersection of Grids or Reference Planes.

From Autodesk's WikiHelp:

Item 7. Snap to the crop regions or datums in the viewports and move them into alignment with the guide grid lines to specify a precise location on the sheet. (bold emphasis mine)

This means we can forget about the datum stuff (Grids/Reference Planes) and use the Crop Region. Of course the Crop Region has to be visible to snap to it and unless you are using a Scope Box to manage the Crop Region (to keep them consistent for many views) it isn't really the most reliable reference point to use either. Here's a visual aid, a short video discussing it too.

Quick Tip - Move a View to a New Sheet

I've added this bit in front of the original post (09/03/2011) after getting a couple comments: This post assumes that "you" are already familiar with the concept of dragging a view onto a sheet from the project browser. Not everyone is aware that it is possible to reassign a view to a sheet by dragging within the Project Browser itself.

If you realize that you've put a view on the wrong sheet you can just select it and "delete" it. The view is removed from the sheet, no it isn't actually deleted (on the off chance you haven't done it before now). Probably already knew that much. Did you know that you can drag and drop it on another sheet instead? When you expand a sheet listing so you can see the views that are on it, listed under the sheet name, you can select a view and drag it to a new sheet. When you let go of the mouse button (ends the drag mode) Revit will open that sheet and let you place it.

Yet another way to manipulate stuff. In practice it becomes harder to use when you have a real project with lots of sheets. Often you can't get both sheets within your view of the browser and it's a little awkward to scroll up the Browser. Revit will do it, just have move your cursor toward the top or bottom of the frame to convince it you want to.

Added this too (09/03/2011): I also like to use the Right Click option > Add View because the list it offers is only eligible views. You have to scroll the list to find your view but at least you know you won't run the risk of dragging a view to a sheet that's already on a sheet.