Filter Criteria Order Matters

Taylor wrote to me to say that he noticed a subtle quirk when he wanted to filter pipe in a schedule. He needed to focus on Mark values that contain M15 and M16 for example. He discovered that the filter would work if he put the criteria in that order but that if he happened to reverse them like this, M16 and M15, Revit no longer found the M15 pipes.

Definitely subtle.

Family Not Shared vs Shared

This isn't about sharing things with others. This about the concept that Revit 7.0 provided to families in 2004. It presents itself to us in Family Category and Parameters dialog or just in the Properties Palette if nothing is selected.

Shared or Not Shared means nothing unless the family is then nested into another family. There is really no reason to make a family shared at all if it isn't going to be nested in another family.

Most content is Not Shared, not checked. You can nest families that are not shared and you will see them when the host or parent family is loaded into a project. You see them but they aren't really there, they are just symbols. Revit has not loaded the definition of the nested family(ies) into the project. You can confirm this by scanning through the list of families in the project browser, you won't find it there.

When a family is Shared, checked, something special happens when the host family is loaded into the project. The nested family is loaded into the project too. You'll find it IS in the Project Browser now. Since it is now "real" that means Revit can include the nested shared family(ies) in schedules. You can tag them too. You can use the 2014 Displace Elements on nested shared families too.

You can also place an instance of the nested family separately if desired. By the way, nested families, whether shared or not, "kill" temporary dimensions, they don't show up automatically when you select the family. You need to click the Activate Dimensions button (Options Bar) to get them to appear.

Mass Floor Area vs Volume

I managed to trick myself into believing that area and volume for a "floor" should be the same whether a mass has one or several mass floors. To help explain my delusion, I created a mass that is a 50x50x50 cube, with five levels.

If I remove two levels from the mix (levels 2 and 5) I get twice the volume for floors at Level 1 and 4

Looking at the 3D view it immediately made sense to me. Looking at the schedule I found myself thinking something was wrong. Why is there double the volume? Why would the floor think it is so much bigger? The real problem was my perception. I was thinking floor, the thing I walk on, instead of a "floor", where I am in the building.

If it isn't obvious, the Mass Floor area is the surface area of the mass floor element. The Mass Floor Volume is the volume between mass floors or the top and bottom of the mass if there are no other mass floors.

Btw, you can select and delete a mass floor, like in a 3D view for example, and that's the same as opening the Mass Floors dialog and un-checking a level.

Learn to Program the Revit API

If you are interested in learning the Revit API Harry Mattison (Boost Your BIM) created an online course hosted at Udemy (The Academy of You).

It's delivered in 33 video segments which vary from a few minutes to a little over fifteen minutes. It's also very reasonably priced at $149.00. Maybe I'll see you on campus?

Learn to Program the Revit API

Paul Aubin Book Survey Seeks Input

Paul Aubin recently mentioned that he's working on a new book, title TBA. The title is one of the things he's asking about in the survey.

If you are interested in the subject and can spare a few minutes to

Click to Take the Survey

Project Base Point Manipulation

I written before that I occasionally experience something that feels like a "Revitary alignment" regarding features in Revit. I'll see a post at AUGI or get an email or two from friends or clients asking about the same thing or theme. I recently ran into a user that manipulated their project by moving the Project Base Point. Then a post at AUGi meandered into a related conversation.

General Statements

• The Survey Point allows us to show where an imported CAD file's origin is relative to your model (CLIPPED)
• The Survey Point allows us to identify a benchmark location on the site instead of referencing source file's origin (UNCLIPPED)
• The Project Base Point does not ever "need" to be moved (CLIPPED) normally (my opinion/belief/preference)
• The Project Base Point will allow us to move our project on the site to reposition it (CLIPPED) but the file origin isn't changed
• The Project Base Point (UNCLIPPED) will let us identify an alternate location that Spot Elevations and Spot Coordinates can reference

Applied to a Project

Let's say you design a house, import a survey and it's off to the right and above your building. If you use Acquire Coordinates on the survey file you should find the Survey Point (CLIPPED) moves to mark the origin of the source survey data file (sometimes this is quite far away). The Project Base Point (CLIPPED) can be used to reposition the building over the site. Just drag or move it with specific values. What you see moving is the "Project". The file origin is untouched and you should see that the linked survey file isn't moving either. If you import a small origin "marker" file using Auto - Origin to Origin you'll find that it lands at the Project Base Point. Now if you move the Project Base Point (UNCLIPPED) you see that you can move the icon to another location but it still references the "file origin" (see image).

That approach works for a single building on site but is not very effective for multiple buildings on site. The approach I advocate where we create a site file that is coordinated with survey data and serves as the master coordinator for multiple buildings which are linked into this master site file is much more effective and versatile. Since this subject can be confusing enough I advocate using the same approach for any project so I can learn one technique and use it over and over, since it works for any project.

Revit 2014 Update Release 1

An update for Revit 2014 became available recently. It has been blogged and tweeted many times already but I chose to echo it now because I've encountered questions about it a few times this week. This applies to all Revit versions, Architecture, Structure, MEP and Revit (aka "one-box"...all Revit disciplines in a single Revit install). These are update links for each version:

Revit Architecture 2014
Revit Structure 2014
Revit MEP 2014
Revit 2014 (one-box, only available as part of BDS)

Families with Nested Families and MEP Connectors

While trading some emails with Aaron Maller recently he mentioned that he observed that he could create circuits for nested shared electrical families. I don't recall Autodesk publicly taking credit for adding or allowing this behavior but I find that it has been possible as far back as the 2012 release. I'd try earlier releases too but I don't have them installed anymore. Since I started preparing this post I've discussed it with Jose Fandos and he confirmed that it is possible in 2011 too.

I'm a bit frustrated because I thought I tried to explore this possibility a couple years ago while making some electrical content. Rather than dwell on what I thought wasn't possible I'll focus on what IS possible instead.

Experience tells us there are many components that have a variety of options or configurations that can prove difficult to include connectors in, for example a boiler with its electrical panel available either on the right side OR the left side. When a single connector is placed we are inclined to placing it in the "middle" so we can "connect" it to a power supply. That's easier to accept for electrical connections but not as easy for piping or duct.

When the connectors are native, placed directly in a family, it isn't possible to put two connectors in place but disable one or the other. Revit sees both even if we only use one of them in the project. With two connectors in the model we can define where connections take place more accurately but ultimately we end up with one valid connector (connected) and another lurking as "unassigned" within the system browser. It might not a big deal but Revit's developers encourage to assign everything to systems so this approach means there will always be some we can't assign properly.

If the connector is part of a nested shared family and this nested family is assigned a Yes/No parameter to control its Visible parameter we gain control over not only when it is visible but also whether or not Revit sees a valid connector in the host family when it is loaded into a project. This is a crude example with connectors for pipe, electrical and data circuits, offering a conceptual right and left configuration.

When I use a yes/no parameter to control the visibility of the nested families it is interesting to find that the system browser responds to their condition. As can be expected Revit will delete a circuit or system associated with a nested connector if we choose to turn it off.

So far I find that I can create systems, connect pipe and duct, draw wires as well as tag the nested shared families. This means that it may be a bit easier now to define a component that has multiple circuits. This can help counter the limitation that a family can only report circuit information (in a tag) for the primary connector when multiple connectors are in a family.

It isn't perfect...naturally.

Nested families with connectors are harder to see and therefore are harder work with. The connectors are only visible when you hover over the location where they are when you are using the appropriate tool, like duct, pipe or wire. That also means we can't use the convenient right click "create pipe/duct/wire" options because we can't see the connectors.

It may also confront us with a need for sub-categories for connector geometry, not for the connectors themselves but any forms we use to host them. It can be easier to find the connectors if we can see the hosting forms but we may not want to see them in every kind of view.

Ultimately I think it's worth exploring further. Perhaps you'll agree?

Schedule Linked Files

We can schedule elements that are in linked files but there isn't a schedule that is only interested in telling us what linked files there are. We can determine which files are linked easily enough while working inside Revit. What if we want to document what files are linked into our model and include this information on a sheet? We can take advantage of the addition of Grids and Levels as elements we can schedule in Revit 2014.

If we assume that all projects will have levels and probably grids a schedule that is assigned to one of those categories can be manipulated to look like it is just a schedule of linked files. Then we can combine that with a Starting View if we want to see it each time our project is opened. Add the schedule to a general information sheet and it can be part of our documentation too.

I created a schedule that includes the fields for RVT Links and at least one for Grids. In this example I used Grids to drive the schedule but Levels are probably a better choice.

When we load a linked file we can supply a unique "Name" value. When we use Reload From or Reload later to update the model we can revise the "Name" parameter to show the current version/date.

Make a custom titleblock family and add the Project and Client related parameters as desired. Load the family and create a new sheet using this special titleblock. Add the new schedule to the sheet. To use this as a starting view activate the Manage ribbon and click the Starting View button. Choose our special sheet view as the starting view.

I used the Clear Cell tool, new in Revit 2014, to remove the link between the schedule name and the header text. This allows us to call the schedule something meaningful in the project browser and show something else in the header of the schedule on the sheet, as shown in the first image in the post. Since schedules can be on any number of sheets it is an easy matter to place it on additional sheets if desired.

A Doors Life

As I mentioned in an earlier post I presented a session called "A Door's Life" at the recent Central States Revit Workshop. It tackles creating a host door family that nests 2 panels, 2 frames and 2 handles. It also features a nested clearance form for clash detection and a variable plan swing angle. The host door permits rotating the 3D panel and hardware to any angle as well, though 0-180 is probably the range that's most useful.

If you are interested in more information this is the handout that attendees received (embedded here).

As the handout will tell you it isn't meant to be the perfect door. It's a demonstration of concepts and how to put them all together. If you're lucky you'll end up with something you can use right away or at the very least have a good idea how to get where you want to go.

Click to Download the completed files for each exercise.

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.

Transfer Project Standards and Shared Coordinates

These two are not friends. They are even less friendly when worksets are involved. In earlier releases the project base point and survey point were assigned to Workset1 (2012 and older). In a post some time ago I mentioned a support issue that IDEATE's techs encountered where a user assigned them to a different workset and eventually deleted that workst. It resulted in unpleasant crashing.

If you look closely in 2013 and 2014 you'll find they are assigned to a workset called Project Info and we can't change that anymore.

Unfortunately the more mundane information like the project name, number, issue date, client name and address and many more are also Project Info.

When we use Transfer Project Standards hoping to share the same mundane project info with related linked project files (seems a reasonable expectation) Revit wants to transfer project base point and survey point information too. You'll get this dialog when you fire up Transfer Project Standards (TPS).

This is what my dummy project looks like before using TPS, note the Survey Point's coordinate values and position.

Here's what it looks like after TPS is done. The project base point and survey point have reversed their orientation to one another and they are very far apart now (I zoomed in closer though), far enough that the walls are tiny and hiding under the project base point icon.

If two files are already sharing coordinates they aren't immune to this "feature" either. In my testing I find that the coordinates still get messed up if I use Transfer Project Standards and Overwrite in order to pass along the other project information. It appears that the safest thing to do once Shared Coordinates are established is... DON'T Transfer Project Standards AND leave Project Info selected.

I think that the Project Base Point and Survey Point should be more isolated so they have their own Project Setting based workset, not shared with other Project Info. I'm glad they made it harder (impossible) to reassign them to a different workset to eliminate the other problem I mentioned earlier but they've introduced a new quirk as a result.

I find it mildly amusing that Transfer Project Standards acronym is TPS...reports anyone?

Linked Ceiling Hosted Light Fixtures and MEP

A ceiling hosted light fixture can cut the host ceiling. When an architect uses one of these fixtures the ceiling surface the Revit MEP user has to work with actually has a "hole" in it. This means that they can't put their own light fixture in the same spot because there is no ceiling there.

Technically that's an oversimplification. We CAN put a fixture in the same location but there isn't a face for Revit to detect easily. If you try to use the Downlight - Recessed Can family it's origin is too far from a ceiling's grid pattern to let us put it within a tile. We can put it in randomly and then move it to the correct location. We'll get yelled at though, the light isn't properly hosted now.

If we do the same sort of thing with the troffer family (2x4 fixture) it will be a bit more tolerant as well as not losing its face association.

This sort of discipline collaboration isn't tons of fun.

Drafting Views have an Origin

When we create a new drafting view we are presented with an empty view. We are free to begin our drafting exercise anywhere we see fit. It's not obvious but there IS an origin in the view. If we import a simple CAD file that has some lines that define where the 0,0,0 origin is we'll find out exactly where the origin is in the drafting view (use Auto-Origin to Origin).

What does it matter? It may not matter at all. I've often wondered about it since Revit cares about keeping us near the origin of the file for our model views and complains when we import external files that are very far from origin or very very large.

As such I can't help but wonder if we ought to be careful to keep our details near the origin of drafting views too. I have encountered drafting views that have their contents very very far from the origin. It's easy to do, just zoom out a bit and start detailing. It just seems inconsistent with the best practice expectations for model views.

I'm inclined to create a "template" drafting view in a project template to begin drafting views with (duplicate them) with the origin clearly marked, like shown above. I'd welcome someone from the factory chiming in to say this is a good idea or unnecessary.

Revit Server Documents

If you visit the wikihelp site for Autodesk Revit Server you'll find (if you look closely) these documents are available for your use/review.

Bandwidth Requirements for Revit Server
Cost-Effective Revit Server Deployments
Locking and Worksharing in Revit Server
Revit Server 2012
Revit Server and Riverbed Steelhead
Understanding Revit Server
User of Revit Server on High Latency Networks

Revit MEP Circuiting

I created a short video that describes the basic interaction between electrical devices and creating a circuit. It's really meant to help explain what happens when a device is already assigned to a circuit and we select it along with other elements that aren't circuited. The ribbon changes based on our selection and a circuited devices impairs our ability to create a circuit for the other devices that are eligible to create one.

• A device that is not part of a circuit, when selected by itself, will cause the Power button to appear
• A device that is part of a circuit, when selected by itself, will display the additional Electrical Circuit tab
• Multiple devices that are both part of a circuit and not part of circuit will only display the context ribbon relevant for the devices, no circuit tab or power button
• Selecting multiple devices that are assigned different electrical requirements will disable the Power button

When we select devices we need to be sure to glance at the ribbon for clues. Here's a video (no audio, turn on Captions).

I also wrote an earlier post about circuits if you're interested.

Quirky Roof - Roofing Around

A recent thread at the Revitforum.org asked about this roof form.

Don't worry about the dimensions. I used them to make sure a roof would work if I was "careful". I later messed around with it a bit to see if I could reproduce the error the original poster described, like this.

The other day I was discussing roofs with someone and I brought this situation up. I used the arrow keys to nudge walls around and thought the result was worthy of a quick video to demonstrate how different proportions affect the roof outcome. It's certainly quirky, maybe even "buggy"?

Light Fixture Grid Positioning and Wires

I've seen some lighting content that has been modified to make it easier to align with acoustical ceiling tile grid patterns. For example this stock family is the Downlight-Recessed Can.rfa with some reference planes added so we can snap to the grid during placement, or use the Align tool easily afterward.

I didn't bother to assign any parameters to control them. I can use them to fit the fixture in a 2x2 grid or use the Align tool later to position it in the middle of a 2x4 grid. It might not be obvious but I can use one reference in a family to move the family over by selecting another part of the family as my second pick. This means it is easy to just set the reference planes at a fixed position and use the family's own references to move it over if necessary. It just means I don't have to have parameters to decide if the fixture is meant for a 2x2 or 2x4 grid. All this is seems good at first except when it comes time to add wiring to the fixtures.

These helpful reference planes end up affecting where the wire's graphical ends terminate. The fixtures are connected to their wire but they just stop at the extents defined by the reference planes. Not fun when you have to adjust a lot of wires to get closer to the fixture. This means Reference Planes aren't ideal for this task. This is what the family looks like if I use Reference LINES instead.

I've held the same attitude toward adding dimensions in this example too, with much better results as well! We can set the reference lines to Strong (IsReference) and uncheck the Visible parameter. They won't be visible when you select the family but the Align tool will "see" them and Revit will highlight the ceiling grid pattern when you place the fixture too. Fwiw, if you leave it checked they still won't be visible when you select the family.

Fwiw, Model and Symbolic Lines that are Strong References and assigned to Invisible Lines provide the same result. You can uncheck the Visible parameter so they aren't visible when you select the family.

(This is based on working in 2014, it does not work in 2012 or 2013. Nothing seems to resolve it in those versions)

View References

You may recall earlier post about this relatively new feature? I also mentioned how the 2014 Sample Project file uses them. Hopefully you've found them useful in your projects by now. This post is how I imagine they could expand on the concept.

It's a common situation to need to refer to common details within the context of a schedule, like this.

I think we'd need a new Type of Parameter called View Reference. We'd pick it from the list when we add a parameter to a schedule.

I imagine the schedule interface getting this addition when we click in a field that has the view reference type of parameter assigned.

My goal is to tie a detail view reference to an actual view so that such information is really connected together logically. It doesn't really matter to me if the end result looks like what I've mocked up as long as the end result is better integration of the information.

Workaround Alert!

In the meantime, one way to deal with this issue (without my wish being granted) is to use schedule keys. Start by creating a schedule key(s) for each detail type that needs a reference. It may require additional parameters. It sure would be nice if we could use Shared Parameters for them too, but that's another wish list item.

We fill out the key with all of the detail reference combinations we will have. In a door schedule we can choose each detail for each condition from those listed in the key. Not hard and a bit more reliable than typing them manually for each door. At least this way we are picking from a prepared list.

Technically if we've entered one value for each detail reference we can just pick from the previous entries without the schedule key. That's not really the problem, just one aspect of it. It's the need to update all of the detail references if something changes to the sheet numbering or detail numbering on the sheet, for every instance it's been applied to a door.

Well, may wishes come true?!!?

Search the Project Browser

Just a little reminder, don't forget you can search the Project Browser!! Forget what you named a family exactly? No problem just search for what you do remember! The hardest part is remember you can search it! It's just a little right click away.

Schedule New Row

Despite the recent improvements to schedules I find myself wishing for a subtle improvement to the Insert > Data Row feature. Paul Aubin commented on this at the Central States Revit Workshop during his Friday session for Interiors. I'm not alone, and the people in his class were on our side too.

The majority of the time we are likely to use it to insert a new Data Row. Since the Insert Above and Insert Below only is relevant or available when working on cells in the header they are far less likely to be used. I think Data Row ought to be a separate button. The other two options could appear to the side and as two buttons, one above the other, if we click on a cell in the header.

The current process adds clicks to what used to be a single click experience. Just say no to more clicks, it's a clicktastropy!

Linked Files and Visibility/Graphics

When you examine the Visibility/Graphics dialog you'll find each Revit file you've linked is shown in a list under the Revit Links tab. In this example I've linked Building A, B and C into a host model. The Project Browser shows three linked files and Visibility/Graphics shows the same three but also shows one child link beneath the top level row for each link.

The top level row for each link is the definition of the linked file while the child beneath it represents the actual instance that is placed in the model. The single child for each link provides a way to customize the appearance of the individual linked file apart from the parent definition. Ordinarily this would NOT be required. If overrides are necessary it is sufficient and appropriate to just alter the definition (top level) only.

However if for some reason you were to use two instances of Building A and Building C the Visibility/Graphics dialog would look more like this, while the Project Browser would remain unchanged.

The new child rows listed for Building A and C are the result of copying the originals for each to a new location. Each new row provides us with the ability to use Visibility/Graphic overrides for each child differently if necessary. For example, I could turn off the first instance of Building C without affecting the second instance.

As you can see, the upper Building C is off now. I could also use the button that appears in the Display Settings column to override individual instances of the linked files. If I want to alter both copies the same way I just need to change the top level definition. I start by checking the option "Override display settings for this instance", choosing Custom, activating the Model Categories tab and then changing the Model Categories drop down to Custom. Now I can override individual model categories in just one instance of the two copies of the linked file.

The link names you see are not default values, I changed them via the Name parameter in the Properties palette.

When worksets are involved the top level is assigned to the Type Parameter "Workset" and the child has its own instance parameter for "Workset" too. This means the definition can be assigned to a workset but each instance can be assigned to different worksets.

If you see more than one child instance of a linked file and there should only be one child that probably means someone has copied a link inadvertently. If you can't tell then it's likely they used Copy to Clipboard followed by Paste Aligned to Same Place and there are two instances on top of each other. Since it's been so easy to accidentally select a link I see this happen fairly often. It can create some confusion when people are trying to override graphics and their efforts don't seem to work. There may be another copy lurking underneath.

Dropping Files

My son is into "Dub Step" and he tells me "the drop" has special meaning but this post is about dragging and dropping files into Revit. You may be aware that, like other Windows applications and files, you can drag and drop a file from Windows Explorer into Revit and Revit will open the file.

As you have probably noticed I like subtle stuff. Brian Mackey mentioned in his adaptive point session at Central States Revit Workshop yesterday that where we drop the file affects how Revit will respond. If we drop a file on the ribbon Revit will open the file. If you drop the file into the canvas or drawing area, and a project or family is already open, it will likely load the family into the other open file instead. If you really want to open the file just be careful where you drop the file.

In Dub Step terms, "Where's the Drop dude?"

Double Clicking Tags

In Revit 2013 we found a new feature to be quite annoying, double clicking on a room tag would put us in the family editor. That is particularly bewildering to new users. Usually we were more interested in typing in a room name or number. With 2014 we received new options to define how Revit should respond to double clicking on a family.

At the Central States Revit Workshop this morning, Brian Cowles with IMAGINIT mentioned a subtle change that is easily missed. If you leave the setting "Edit Family" as your preference it is almost the same as 2013 except that where you put your cursor is important before double clicking. If you double click on an editable label in the tag it will place you in edit mode for the parameter. If the Move symbol icon is displayed when you double click you'll edit the family. This means you can take advantage of double clicking AND avoid the downside.

Love subtle stuff!

Blog Plug - Steven Shell

Just a short post tonight to plug a new blog that my friend Steven Shell decided to start called BIM: Integrating Art & Technology He is a practicing architect in Tuscon (sole practitioner) that skipped over the whole "CAD thing" and went straight to Revit from hand drafting. He's a self taught Revit aficionado that will tell you he's learned from the Revit community's willingness to help and share with each other. That and his own irrepressible style and creativity...

He's also a lover of music and expresses it through his guitar and the band he fronts called Shell Shock. That's why I call him the "rock-n-roll architect". I've had the pleasure of sitting in with his band (on drums) a couple times in the past. I'm grateful for the guys tolerating me bringing their quality down briefly.

As a solo architect making his way in this new "BIM World" I think he has something to offer others. Often we just need some confidence based on the knowledge that someone like "me" is out there doing it and so can I. He's considered starting a blog before but worried about what he wanted to say. He seems to think he's sorted that out and has begun. The easy part is done, starting it. I'm hopeful he continues to find a reason to write, to share his thoughts with us!

Go Steve!

Sneaky arrows

On the ribbon there are two arrows that gives us access to more information. The first one is the "I'm hiding a list" arrow.

When you click on that arrow you get a drop down list of more options or features.

The other one is the "I've got a dialog for you" arrow.

That one will open a dialog box to let us adjust settings. That one is the sneaky arrow for the Site Settings dialog. There are similar ones for each trade's settings dialog (HVAC, Electrical and Plumbing).

Look out for sneaky arrows.

Phase and Poche Materials

As you're likely to know already Revit provides a feature to change the appearance of elements to distinguish between phases of work. When you examine the Materials dialog the "Phase-X" materials were created by the development team and they exist to support the way that feature is intended to work. The templates are configured (OoTB) to automatically "work" if you use the phase features.

When I visit the 2014 Architectural template I find three "rogue" phase materials in the dialog (image above). The four highlighted in yellow are assigned to the Phases Graphic Overrides.

I've no idea what these three other materials are assigned to. When I examine the Materials dialog and the icon for "asset use" (highlighted with the red circle in the first image in this post) the four "good" materials report that the associated asset is shared with 8 materials. The three rogue ones are not using an asset shared with any other materials. Easy enough, I deleted them. Revit will let you delete any of the phase related materials even though the Phase feature is technically relying on them to work as intended out of the box.

In general nobody will use the materials for anything else, not really suited for anything else. They "work" as intended and are preset so they do. The only real interaction anyone needs to have with any of these materials is if something about how they look isn't quite what we want. If we don't think demo elements should be red we can change the material to use something else or increase or decrease the transparency for example.

The other material highlighted in yellow is the poche material (pronounced Poe-shay). It's also a feature that was originally tied to the graphic display of the model when Coarse Detail Level is in effect. However they've made the Poche material assignment a Type Property of 3D views.

You have to assign a material to have it take effect. In the past Poche was hardwired to the effect. Now you can technically use any material in the library instead. Poche isn't required itself to work anymore. Here's an example of it being used on the section through a pavilion model.

A Door's Life at Central States Revit Workshop

I'll be presenting a session next Friday called "A Door's Life" at the second annual Central States Revit Workshop.

Central States Revit Workshop Details
August 15 (Thursday) and August 16 (Friday), 2013
Scott Conference Center - Omaha, Nebraska
Registration: $250 (does not include accommodations)

BIM/Construction Speakers
Bill Allen, Scott Chatterton, Megan Johnson, Matthew Lewis, Cauitta Robeson, Connor Christian, and Aaron Baker

Architecture/General Speakers
Bryan Cowles, Steven Shell, Ryan Cameron, Nathan Miller, and Jason Gardner

Interior Speakers
Kelli Lubeley and Carla Edwards

MEP Speakers
Shawn Zirbes, William Spier, Kelli Lubeley, Todd Shackelford, Brett Grell, and Dave Benscoter

Structural Speakers
Aaron Krovance and Luke Stevenson

Special Guest Speakers
Paul Aubin, Brian Mackey, Dezi Mackey, Birgitta Foster, Andy Jizba, Chuck Mies, and me


As for my session, it's not literally about the life of a door. Since this is about Revit it's biased toward dealing with doors as a concept, some doors that look like these.

The handout that attendees will receive is structured as a lab with step by step activities. The session is 70 minutes in a lecture format so rather than going step by step in the lecture I'll be touching on each of the ideas involved with each exercise. I prefer to let people see how I approached the subject by working in Revit, instead of "PowerPointing" my way through. My goal is to leave enough "space between notes" to permit "inquisitive interference".

If you are nearby then you've got to make sure you get to the workshop. Even if you aren't it's still a great deal for two days of Revity goodness.

See you there!

Naming a Reference Plane

I read recently that just adding a name to a reference plane would cause it to be "strong". The notion of Strong, Weak and Not a Reference are related to the IsReference parameter, which I've written about before. It's my observation that adding a name to a reference plane has no impact on it's behavior in a project. To test my belief I created a small family with a collection of reference planes with various combinations of Name and IsReference parameter values.

The reference plane on the far right is set to Not a Reference and has the Name No 3. Its the only one that is invisible in the project environment. The two on the far left have IsReference values (Weak and Strong) but have no Name either, they still are detectable in the project. I sketched dashed lines from the detectable ends of the reference planes. The dashed line on the far right is sketched where the reference plane should be but I couldn't snap to the end because it isn't detectable there. I also added a dimension string across each detectable reference plane.

I think my beliefs are intact, just adding a name to a reference plane does not alter its IsReference conduct in a project. When we create a new reference plane Revit assigns Weak Reference to its IsReference parameter. If we copy a reference plane, those that Revit lets us copy, it also assign Weak Reference to the copy.