Wednesday, November 27, 2013

Stacking Views on Sheets

Why the hate I wonder? It seems like anytime I read about or suggest stacking views on a sheet to get a specific result people respond with "Oh that's yucky!" or "Ew, an awful workaround". Maybe they are too young to remember pin bar mylar drafting techniques where a series of mylar sheets would be stacked to produce a final. Lot's of things are built by adding layers of information, tee-shirts and silk screening for example.

Views are "cheap", easy to make and alter. When one view looks down and another looks up I can combine them on a sheet to get a bit of both worlds and tell a better story. Having to see more views in the project browser might be annoying but I find using drafting detail lines to show a feature above more annoying. Even using the Linework tool for that purpose is view specific and more labor to replicate when necessary.

If we think about it a bit, it's not all that different than using external references and showing them under our own work. In this case we are able to "xref" our own views by putting them on a sheet. We just need to have a special viewport type that doesn't show a view title. This way we don't have to worry about competing graphics and information on the sheet. Combined with the new bossy view templates it get be pretty efficient too.

Don't be too hasty to rule out stacking views.

Tuesday, November 26, 2013

Different Parents

It might be surprising but I run into quite a few people who are not aware that Revit was not always an Autodesk product. I've encountered a few that think it's a bizarre offshoot of AutoCAD. I often hear people say AutoCAD as the same word as Autodesk, or at least as if they are interchangeable in meaning. Autodesk is a company and AutoCAD is software, a product created and sold by Autodesk.

Revit started out as an idea shared by two founders (Leonid Raiz and Irwin Jungreis) and they formed Charles River Software in the late 1990's (97-99). It became a formal product we could buy/rent in 2000 from a company called Revit Technology Corporation. Rumor mongering has it that Autodesk began considering a buyout within the first year of its existence. By May of 2002 it wasn't rumor anymore, Autodesk finalized the purchase of RTC and Revit for $133 million.

I tend to think of my software bias as having been influenced by "my parents". By that I mean people that are "raised" (began using or prefer) by CAD parents like Autodesk, Bentley, or Graphisoft. As such I don't find it surprising that Bentley family members prefer their family experience over the time they spend with another family, like getting adopted in your teen years perhaps. I started with CAD using Apple's MacDraw but my first real production CAD software was AutoCAD (technically I used Generic Cadd before AutoCAD but Autodesk bought it too). So my CAD childhood was in the Autodesk family. By the time I moved in with the Revit Technology Corporation family I had lived in the Bentley family for four years too. My multi-family experience has tempered my zeal somewhat but I still have a clear bias toward Revit...obviously.

When we start using Revit it's common to express dismay and confusion. It isn't always clear to someone that has been part of the Autodesk (and AutoCAD product) family why Revit seems to be a rebellious or stubbornly different child. It doesn't observe the same rules my other parents imposed on me? Well, it had different parents.

As a teen my parents gave me an allowance, enough that if I saved for a couple months I could afford to go to a movie. They insisted I go to bed at specific hours, gradually ascending as I got older so that I could stay up until midnight when I was thirty. I exaggerate just a bit but the point is that parents have different ideas about raising their kids. The founders and developers behind Revit are/were much like parents. They made decisions that formed Revit, determined how it should behave, who it could hang out with, play with, what time it should go to bed etc.

During a recent presentation someone asked me why Revit does "something", I don't recall what "it" was but my response was, "Because...". Many of us have heard that from our parents before, or "Because I said so!" Some laughter ensued thankfully, meaning they saw the humor too.

The truth is I didn't know why and I admitted that, but it is also true that it works the way it does "because", because "someone" decided it should be so or someone decided that doing "it" was something for later exploration and development. That someone is one of Revit's parents: a developer, product designer, marketing director, sales executive... Each product at Autodesk (and other companies too) has a different team that functions as its parents.

The next time you wonder why Revit doesn't let you do "something" like that other software, remember, "oh yeah, different parents!"

Monday, November 25, 2013

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.

Sunday, November 24, 2013

Revit 2014 User Interface is Forgetful

I didn't notice this when 2014 was first released but since the last two web updates Revit seems to be forgetful about the Project Browser and Properties Palette status. I find that I can work for awhile, close Revit and return to find the palette and browser aren't open. When I examine their settings via View ribbon > User Interface the check marks indicate that Revit "thinks" they are open but they aren't "there". If I "close" them by un-checking and then check them again they come back.

I do find it is less forgetful if I allow the Recent Files list to open. There is an option to disable it in the Options Dialog (User Interface section), "Enable Recent files page at startup". If I disable it however I find that the palette and browser linger on screen when I close projects and families which gives the appearance that the project is still open because it will still display information that is part of the last project.

I've visited a few clients suffering with this and have heard from friends as well. It seems related to the new dockable browser API and it's messing with a couple external applications too apparently. If you are encountering this, you aren't alone. Hopefully they'll sort it out and issue another web update or perhaps a Hotfix to sort it out sooner than later.

Saturday, November 23, 2013

Formatting Schedule Wish

I wish I could move schedule fields up and down in the list just by clicking on one or more and dragging, on both the Fields and Formatting tabs. I know it's asking a lot. If I can't get that I wish there were Move Up and Move Down buttons on the Formatting tab for fields too, like this.

I can't count how many times I find myself on the formatting tab and realize that I'd prefer a little different arrangement. No it isn't hard to switch back to the Fields tab, but it seems so's the "same" list. From a development standpoint it is adding a couple buttons and copying code. I could probably manage it with what little I remember of programming in the past. Which of course means it is too easy to get done. :(

Friday, November 22, 2013

Change Parameter from Type to Instance

It's fairly well known that we can change length parameters from type to instance via the Options Bar trick. What is less well known is that we can change other parameters too. I was trading a couple emails with Jose Fandos of Andekan about Manufacturer and Model being Type parameters. He shared a trick in a past blog post. His post explains how to change system parameters from type to instance. We refer to it now as the Vegas Trick because we were attending Autodesk University in Vegas when the subject came up at the bar.

In response to reading a post at AUGI I was curious about doing this for system parameters that Revit groups under Identity Data. Practically all family categories have those built in. That seems to make it impossible to do the switcharoo that Jose wrote about in his blog post, which related to an electrical parameter. However Jose noticed that in Revit 2013 the category Profile > Split Profile doesn't have identity data parameters. Fwiw, in 2014 they've changed that, in fact there is no "Profile" category or Split Profile" sub-category at all in 2014. I was trying to pull it off in 2014 and it took his refusing to be boxed in thinking to try it in 2013.

The process looks like this (using Revit 2013):
  • Starting in the category you really need
  • Add a value to each parameter you want to change
  • Switch to category Split Profile
  • Parameters become editable
  • Change each to Instance
  • Change back to the correct category
  • Now you can control them by instance
If you're interested you can DOWNLOAD Revit 2013 version of a Specialty Equipment family that has been altered this way for Manufacturer and Model.

Keep in mind that we'll still get warned (editing a schedule) that the changes we make to the parameter will affect many instances of the type.

Thursday, November 21, 2013

Room Area Net vs Gross

When it comes to documenting room area we have one global setting called Room Area Computation, found in the Area and Volume Calculations dialog.

We get to choose from four options that affect the entire project's room area calculations: Wall Finish, Wall Center, Wall core Layer and Wall Core Center. Wall Finish tends to work for net area calculations while Wall Center works better for gross area.

When we need to be able to show both net and gross one approach we can take is to use Area elements and Area plans. Unfortunately area and room objects are totally ignorant of one another. That means an area plan using area elements is NOT a room so we've got a lot of redundant data entry to deal with. Another way to deal with it is to print sheets with the Room Area Computation set for one condition and then switch to the other setting for other sheets intended for that condition. We'll need some "redundant" views with tags etc. but perhaps it will provide the necessary differences required.

Another possibility if we are using Revit, the version that includes all the disciplines tools, is to take advantage of MEP Spaces. They ignore the Room Area Computation setting, they only reference Wall Finish. This means I can create a space for each room, yes some redundancy. I can use the Space Naming Utility (subscription extension) to pass the name and number of the related room to the space name and number parameters so I don't have to enter the redundant information. The end result could look something like this, where I use a plan focused on spaces and another focused on rooms to show both net and gross area calculations.

This nexst image is Gross Area using Wall Centerline as the Room Area Computation settings.

This image is the Net Area using Spaces instead, leaving the Room Area Computation the same as for the above.

This is using Area elements instead matching names and numbers manually. The API might be able to be harness to resolve this to some degree.

Something to consider.

Wednesday, November 20, 2013

Shared Coordinates and Worksets

Ordinarily we are not permitted to save changes to a linked Revit model. The lone exception is when we use Publish Coordinates. Any time we makes changes to a model that we've published coordinates to we are attempting to save a change to the linked file. For example when you publish coordinates for the first time you'll get this message.

When we get around to saving the host project file we'll be greeted with this message.

That message is the one that is indicates Revit is going to change data in the linked file. If this file is open by someone else already we'll be politely rejected, though the message is a bit oblique.

But then this message will likely appear right after you click Close for the previous message dialog.

Followed by a repeat appearance of the previous message, "Failed to open document". This means Revit couldn't save the change to the shared coordinates because the file is currently open (read only). This means to be successful we need to make sure nobody is working on the linked model, at least for long enough to let us publish or update the shared coordinate information.

When worksets are being used this changes because Revit can still reach into the file and interact with an individual workset instead, unless someone already is doing that. It is recommended to Import/Link a central file, not a local file. Users should not be working in a central file so it is less likely that publish coordinates will compete with someone. Local files are usually created on the user's PC. This means using Import/Link on a local file will likely fail to work for everyone on the team. We aren't usually mapped to user's computers for file sharing. Let's come back to worksets in a moment.

We'll get the following message when we decide to change the position of a linked model that we've previously used published coordinates on.

This gives us the opportunity to commit the change to the linked file immediately (click Save Now) or postpone that action till we are really done adjusting the link (click OK). Yet another message can appear if someone has changed the linked model since it was loaded or publish coordinates was used.

As the dialog suggests, Reloading the linked file will resolve the situation easily. If we are dealing with worksets again it is possible to have a similar message appear, related to the situation where other users have used Synchronize with Central recently.

This too can be resolved by Reloading the linked file, as long as we cancel the action. If we click OK then Revit will allow us to leave the modified linked file in its new position. After we reload the link Revit won't prompt to Save the new position, a quirky outcome. We need to use Publish Coordinates on the link again, we can just leave the location name the same to publish the revised data.

In the past we could find another user listed in the borrower column for the Project Information workset when someone used the Publish Coordinates feature on a linked file. With 2014 I find that Revit seems to be able to resolve this transaction more reliably. When I am working in my local file and another user publishes coordinates I don't find any other users listed against worksets in the Project Standards group.

To reliably publish coordinates to a linked model:
  • If it isn't a workset project I need to
    • ask any other user to save and close the file temporarily
    • Reload the link (Insert ribbon > Manage Links dialog)
    • Publish Coordinates 
  • If it is using worksets I need to
    • Reload the linked model (Insert ribbon > Manage Links dialog)
    • Publish Coordinates

Tuesday, November 19, 2013

Order of Nested Families in Drop Down Lists

When we use nested families and use the data type to switch between different nested families we often encounter the annoying sorting habits of Revit. For doors this can mean that we get a list of panel choices that could look like E,A,B,D,C,F, and G. For shared nested families it matters how they get loaded into a project.

I find I get predictable results if I load the nested panels into a project first and then load the host doors. I also need to load all the panels in together, at once, not a few at a time. If I don't I find they get jumbled in the list box. If I behave then Revit puts the panels in alphabetical order in the drop down list when I want to swap out a panel later. This is easy to sort out if we are starting a project. If we need a new panel type during a project then we'll probably have to live with the new panel ending up in a strange place in the list.

Fussy Fussy Revit.

Monday, November 18, 2013

Creating Family Templates

Revit does not permit us to use Save As to create a Family Template unlike projects which can be saved as either a project or a project template. It's a bit like a strict parent that insists we go to bed at 8 PM no matter what, even if a TV show we really really want to watch is on at 8 PM.

Along the way, many years ago, someone noticed they could just rename the family to use the template extension .RFT instead of .RFA (family extension). The technique works as long as you don't have a desire to alter its structure (the file that changed from .RFA to .RFT) once you've started to create a family with it.

This means I can rename a family extension from .RFA to a template extension .RFT. Once it's changed I can create a new family by clicking New Family and choosing this special family template. While working on this new family (based on the template) I cannot delete any reference planes/lines or dimensions I created while it was a family (not a .RTE). When Revit opened the file it took ownership of all of "my work" while it was still just a family (using .RFA).

This means that if I want to start a new family based on this template but realize I need to alter the format a little, I have to return to the original "template/family" to do so. Once I've changed the extension to .RFA again I can alter the template's format freely. Any families I've created using the template can't be changed as extensively or freely.

There is no going back to a less well prepared format, at least not with the resulting family(ies). I can move and copy reference planes but I can't decide I don't need them any longer. Revit locks down the reference planes in the same way that the stock templates have done for the reference planes we find there. It protects those parts of the template file. This can be particularly confusing for other people when they come across a family and think they can reverse engineer it or start with this family to create something similar. It's confusing when they can't get rid of so many reference planes and dimensions.

Since I frequently have different things asked of me I just leave families assigned to the .RFA extension, those that I think of as templates. I add the word "template" to the name. This way I don't have to deal with switching the file extensions back and forth, which I find confusing. Which ones did I change, which ones did I leave alone? I just keep my templates in a separate folder. The hardest part for me is remembering to use Save As before I start messing with one. I could make the folder read only to make it a little harder on myself.

I recall slightly different results using past releases. This post is based on using Revit 2014.

Saturday, November 16, 2013

Controlling User Choices in Families

In November 2005 I wrote post called Make Up My Mind to describe how I could control a series of Yes/No parameters with a single input. I've often wanted to manage this by providing a more meaningful list of choices. A couple years ago I chatted with Jose Fandos of Andekan about this. He's made a lot of content over the years and he pointed out that I could get what I wanted, it just wasn't possible quite as directly as I'd hoped.

Here's a screen capture of the Family Types dialog that I mocked up for a related thread at

This technique uses a nested Detail Item family that has three types: Default, Vertical and Alternate. These refer to three preset choices for the orientation of a family.
  • I nested the family into my main (host) family and associated it with a Family Type parameter called Choose Orientation (at the top of the dialog).
  • I created three parameters which are also using the data type Family Type (next 3 down).
  • Each of these is preset to one of the three orientation types in the nested family.
  • I created three Yes/No parameters that will be used to control the visibility or orientation of forms in the host family (group of Toggle parameters).
  • Each Yes/No parameter is mapped via a formula that, (in a counter-intuitive "IF" statement format) stated in plain English, equates to "If Choose Orientation = Set Condition A,B or C then my parameter value is True".
  • I can use each one of the Toggle parameters to control other elements all based on the user selection for Choose Orientation.
The middle man Set Condition "x" parameters are necessary because a Yes/No formula can't evaluate the Choose Orientation parameter value directly in the formula column. When the user encounters this family they just use the Choose Orientation parameter to decide which orientation is appropriate. Everything else adjusts based on this choice.

Download the Example Family

Friday, November 15, 2013

View Reference and Camera Location

We still have no annotation for camera or 3D views like we have for sections, elevations and callouts. With the introduction of View References as associated with the Matchline tool and their subsequent expansion in later releases we don't have to wait. We can make our own. It won't be precisely associated with the camera or its orientation. It will be up to us to make them reasonably close. Here's a quick example.

If we can do this for a camera view I hope this makes you realize that you could use the same technical to create other view annotation that isn't tied inherently to the view like sections, elevations and callout graphics currently are. It would be a little redundant but for example structural engineers often like to point to column details like this. If I create an enlarged detail of a column I can use a View Reference to provide the graphic look they want.

Something to consider.

If you'd like to reverse engineer these examples: CAMERA Ref and COLUMN Ref.

Thursday, November 14, 2013

Errors and Omissions

This is a repost from September 2009 based on having this conversation a couple times recently.

Every now and then I read an article pumping BIM or Revit. It used to be few and far between but new articles pop up daily. All too often the words, never, perfect, automatic, press-of-a-button and many more show up in the text. These words are used to compare Revit with other software and are often meant to highlight the strengths that Revit has. The fact that we can generate elevations and sections easily and that they are derived from the model without drawing them completely from scratch is wonderful. Many examples can use a little dose of reality.

There is an Urban Legend where a person bought a Winnebago and thought the cruise control didn't require someone behind the wheel. Most people laugh or at least chuckle at the notion that someone would set cruise control and get up to make a sandwich (the version I've heard the most) and think that the vehicle could safely navigate on its own.

Let's be clear - we can make mistakes in Revit too.

I used the image above a few days ago regarding interference detection but each of these things can be done easily in Revit.

Revit coordinates information much better and makes it more obvious that things are wrong too, like the things in the image. When things are working well, if it is correct it is correct everywhere. With Revit, when it is wrong, it is wrong EVERYWHERE too. This is an important distinction. When comparing Revit to other software the thing that is wrong in other software may be correct elsewhere because there is no connection to the other drawing or representation of the building. The distinction here is that documents are derived from the modeling process in Revit and embellished to create a finished document, with documents as the deliverable or focus for now.

Schedules are never wrong! I read this one every now and then, unfortunately this is incorrect. A schedule that does not use sorting/filtering, design options or phases as criteria will not report incorrect information. A schedule will NOT misrepresent data though. For example, a single panel door will not magically become a double panel door unless someone swaps a single for a double in the model. A schedule CAN misrepresent the whole story though by excluding information because of criteria applied by the user. User Error CAN and WILL creep into a Revit model. You can't blindly accept the results you get.

If we can make mistakes in cad and in Revit then what's the difference?

The difference is in how many of the mistakes are easily prevented or eliminated. Revit does a great job of managing the annotation related to views, sections, elevations, details and enlarged views etc. So much of the hassle of checking these is greatly reduced. When mistakes are made in Revit a team is much more likely to bump into them because they are working on the same data set or model. With the separate file process used by cad a team can be quite isolated from one another. How do I know if someone is making mistakes in their drawing if I really only see their work when it is printed out? Even then I have to visually compare their work with mine. Digitally I can reference their files and check them on the computer. All of this is so much easier, or at least more fluid, and we are always in the context of the building with Revit.

So much of quality assurance is the rigorous studying of printed drawings for inconsistencies. Much of it is based on years of experience and even intuition. I know that this and this are likely conflicts so I'm hunting for them. Most firms have checklists that go on for days.

It is my observation that teams using Revit know more about each others work and the whole building than teams who use other software. How can you avoid being more aware of what someone on your team has been up to when you see and walk by their work in the model each day? I've also observed many times that two users will have a conflict because they both observed a problem and set out to fix it at the nearly the same time, which generates a permission warning.

With my Revit bias you won't likely find me telling you Revit isn't the correct choice for you. I do want you to have realistic expectations though. The Staples EASY Button is a great fun thing to think of but what we do in this AEC business is rarely truly easy.

Mistakes can and will be made using Revit. Revit does give you a much better chance to catch and minimize mistakes as well as the opportunity to focus on making good decisions, and doing so as early as is practical so that the costs associated with those decisions can be managed well. Said another way, a past client once said to me in language more colorful than I'll write here, "My staff are making mistakes in cad all day long, at least in Revit they will be better coordinated!". Perhaps a bit too practical or not a lofty enough goal, but focused and realistic!

Wednesday, November 13, 2013

Detail Level and Interference Check

I've written a couple posts in the past (January 2012 and August 2009) about creating clearance elements for use with Revit's own interference checking. Toward the end of one post I mentioned incompatibility between using Detail Level settings with forms that are intended for interference detection.

I wrote, "Keep in mind that the obvious way to manage visibility by using Detail Level won't help us for now. Why? Detail Level doesn't work with Interference Checking, the solid has to be "visible". If we assign the clearance solid to use a specific Detail Level the Interference Check tool fails to see the solid at all even if we change the view to the correct detail level."

I continued, "The Bottom line, we can't use Detail Level to manage the visibility of clearance solids. We must use sub-categories or Yes/No parameters. Using sub-categories is a broader brush solution while Yes/No is more involved because you have to manage them at the family level. When we use these methods we can turn off the visibility of a clearance solid and the Interference Check tool will still find them."

All these years later the incompatibility remains.

We can re-use common forms for clearance families if we nest them into other families, they don't need to be "Shared" to work. We can use a different category element (for example Generic Model > Clearance) and it will detected as interference based on the host's category. Just don't use Detail Level settings to control the visibility of the nested clearance family either.

I also suggested that Autodesk standardize "Clearance" as it's own category. Alternatively they could establish a sub-category of Generic Model or even for all categories like they did with Hidden Lines (for Show Hidden). This way they could, at a system level, help us define what clearance elements are, how they are defined, what they should look like and how they should behave.

Somewhat related here's a May 2009 post I wrote about Design Options and Interference checking not working well together. It's still the same in 2014.

I wrote, "The Interference Check tool does not filter out results for elements assigned to various Design Options that "interfere" with one another. Keep this in mind the next time you are reviewing the results. You'll have a lot a "meaningless" collisions if you have any number of of options."

Stay interference free my friends!

Tuesday, November 12, 2013

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?

Monday, November 11, 2013

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.

Saturday, November 09, 2013

Foundations and Insulation Calculation

I got involved in a thread at that asked about calculating the total bitumen insulation required to cover concrete foundation surfaces. The original post described using the Paint tool and how much time it took. I always wonder if people are responsible for the calculations or just curious whenever I read such requests. Sometimes I ask. Intellectual exercises might be interesting but they can waste a lot of time if the results don't actually get used by someone.

Since I put the effort into it already I decided to use this post to share the example project I created in response. I shared an earlier version in the thread but this one has more ideas expressed.

I'm inclined to try to use schedules and formulas to calculate/predict the insulation material required instead of using paint and a material takeoff. The Isolated Foundations (footings) have one form (most of them) so there aren't compound layers like foundation slabs, floors or walls.

It isn't as simple as just reporting all the surface area of each kind of foundation. It isn't even simple to do just that. The surface touching the ground doesn't get the insulation (my understanding in this situation). No insulation is required where a column sits on a footing so we need to subtract the column base area from the top of footing surface area. No insulation is required where a wall sits on a footing either.

We also have parameter inequity. Isolated Footings don't have a "thickness" parameter. Foundation Slabs and floors do. Inconsistent application of dimensional values is the sort of trouble we face when we use the provided family categories (as their naming/behavior implies we should) and try to compile their information using the "same" notion of dimensional criteria. They just aren't all equal, they don't have the same "beliefs".

My approach started out with a foundation schedule that includes footings and slabs, a schedule for walls and a third for columns. I needed to distinguish between footings and slabs so that I could create formulas to figure out the area for the top and sides of each kind of footing. Floors and Slabs have Default Thickness and Perimeter. When they are rectangular they also have Width and Length. If they are irregular they don't. Foundation footings don't have thickness but have Width and Length.

I used a formula to divide the Volume to arrive at an Approximate Height to use to calculate surface area for top and sides. I used a parameter called Is Slab (an integer) so my Bitumen formula could decide which formula technique applied. I just enter a 1 for slabs and 0 for footings. This is the foundation schedule for wall footings, isolated footings and slabs/floors.

As you can see I added some rows to the header to explain the empty cells in the schedule. I also added the formulas (after capturing the images) to the comments so it's possible to validate the results without having the model.

Here's the schedule for the walls. I've not resolved the overlap of walls onto footings or the walls and their own footings in the schedule above. I'd probably create another schedule for subtracting the bottom surface area of the walls, or if possible include it in this one.

And here's the schedule for the columns, I put the (-) in the header to make it a little more obvious that the area should be subtracted from the other totals.

You may already know that columns don't have a base width or length parameter that we can see in schedules. They have a type name but the parameters that govern their base dimensions are called "b" and "h", like the corresponding graphic in some structural design manuals I've seen. I added two shared parameters, Base Width and Base Length, to the column family and just made them equal to "b" and "h". That's probably the easiest way to resolve content that fails to use system parameters that are compatible with other families, as well as content that you download and find the same conflict between other content of the same category.

Assuming the approach above is completely uninteresting these are some possible alternatives we could consider.
  • We can "paint" on materials and there is a Split Face tool which will work on floors, foundation slabs and walls but not structural foundations or columns. We can model all foundation elements as floors and/or foundation slabs which would make it easier to use the Split Face tool and then paint on the insulation.
  • Use a combination of the schedules above and some use of the Paint tool and material takeoffs.
  • We can create separate families for the insulation conditions that can be scheduled by themselves, or at least for the foundations that can't be "painted" with Revit's paint tool.
  • We can build more complex footing families that have an additional form(s) for insulated surfaces and these can in turn be used to define them in a material takeoff, instead of a regular schedule.
  • A talented programmer with the Revit API could take into account all sorts of permutations and generate a pretty comprehensive summary).
I've posted the project file if you'd like to DOWNLOAD IT. Happy insulating!

Friday, November 08, 2013

Project Version Wish Revisited

Blogging, twitter and otherwise working "on the line" is cool!! I complained in a blog post just two days ago about not knowing the version of a Revit project file. Sean Burke via Twitter suggested the API might be harnessed to provide a solution, specifically tagging Harry of Boost Your BIM. Harry took up the challenge and within a few hours provided a solution and a video to demonstrate how cool working with the Revit API can be (yes Harry is cool too).

Here's the video he shared via his Blog Post response.

Harry's solution looks great and I'm off to download it!! Of course this means I'll have to whine on my blog more often.

Thursday, November 07, 2013

Level Matching in Schedules

If you've used the Level parameter in a door or room schedule to sort and group them you may have also been surprised when you attempt to do the same thing including a linked file's elements. The Level parameter becomes unavailable in the filter tab of Schedule properties when it includes linked elements.

Behind the scenes Revit doesn't look at a Level the same way we do. We see a name like ground or second floor but Revit sees a unique ID instead. That means a linked project might have the same levels, the names we read, but they aren't the same ID. To a computer they couldn't be more different.

Revit reconciles this same situation with phases by providing a phase mapping tool in the properties of each linked model. When we use that dialog we are telling Revit that "this" is the same as "that". It seems pretty reasonable to me to do the same thing for levels. Provide a level mapping button right next to phase mapping, or combine them into a project mapping dialog. Maybe it doesn't have to be a mapping dialog. We could just interact with them in a view to map them to each other. We do this when we use Copy/Monitor.

The current workaround is to filter a schedule based on some other data that is uniquely level related or worse, actually entering "level" information into each element so they can be filtered by it. Add to the un-Revityness is that we now have to encourage people to add the same info to their model so we can use it in our schedule. Especially frustrating when the "same" info is already in the model.

Wednesday, November 06, 2013

Project Version Wish

You may have experienced this too, maybe just once or forty times. I received a file to look over and it's not obvious which version of Revit it was created in. Naturally by the time I got a chance to look at it I couldn't just ask. The file name doesn't give me a clue. Some firms include a version designation in the project file name, for example "1234 Our Big Project-A-13.rvt". The "13" tells me that its a Revit 2013 file. There are plenty of annoying things in life, waiting for a Revit project to upgrade unnecessarily because I don't know what version it was created in is a drag.

Recently a tip was offered (but I can't remember who or where I read it, sorry) that you can use Show History on a project file instead of fully opening it. It helps you catch when you are attempting to open a project in a older version of Revit than the file was created with. It does not help with an older file being opened with a newer version though. Sadly I didn't remember this tip (even though it wouldn't have helped) until I got the dreaded "This is a one time upgrade process" message. Nuts!

I've got a couple wishes. First I'd love it if Revit would store a value in the file properties that indicates Revit version. Second I'd love for Revit to ask first, "Do You WANT to UPGRADE? and a "NO, NOOOO, please on all things holy NOOOO" button.

Tuesday, November 05, 2013

Monitor a Multiple-Segment Grid

When multi-segment grids were introduced they were not able to include them in the Copy/Monitor "loop" for Grids. We can monitor them, sort of. Since Copy/Monitor won't cooperate we can create our own "copy" of multi-segment grids by selecting them in the linked model and using Copy to Clipboard and Paste Aligned to Current View. We just need to remember to use the TAB key to cycle "in" to select elements in a linked model. Alternatively we can sketch our own version over the grid(s) in the linked model.

Once we have our own version we can use the Monitor part of C/M to let Revit watch over it, sadly...only sort of.

When we just use Monitor Revit recognizes the individual segments, not the whole multi-segment grid as a complete grid. If their original changes the process break downs even further. We do get a warning that the monitored grid has changed. If we select our version of the grid we don't get the Stop Monitoring button that normally allows us to sever the relationship. Our version also doesn't trigger the Coordination Monitor button when we select it after getting the warning when we reload the link or open our project fresh. If we just delete our version the coordination monitor warning is still lurking and I find that it will show up again later complaining about the deleted grids (ours). At this point it is messier to use Monitor than just watching for changes ourselves.

If we are willing to place individual grid segments over their multi-segment we can use Monitor and get normal results if we monitor each of their grid segments against our own individual segments, just not if ours are also are a multi-segment sketch based grid.

Short story, even using monitor only on multi-segment grids leaves us wishing for better. Hopefully the Copy/Monitor tool will get smarter and work with Multi-Segment grids too!

Monday, November 04, 2013

Change a Level Association for a Room

I read a wish at AUGI asking to be able to change the associated level of a room via the Properties Palette. My initial reaction was, "Yeah I can see that".

As I thought about it a bit more I believe that the process has been limited to using Delete and then placing the room again or using Cut to Clipboard and then using Paste elsewhere because simply changing the level relationship in properties does not ensure that Revit or the room will find boundaries.

If there are no boundaries to be found Revit would generate a warning and the room would have a record against it in Review Warnings. To resolve that the room would either have to be re-positioned or walls would need to be created to provide the boundaries. If we compare that effort with deleting the room from a plan view and placing it again on a different level it doesn't seem like much difference to me.

In general I think it would be nice to have more flexibility to alter element properties via the properties palette. The context we often need to appreciate how they work in the model may not be represented by a list in the palette though. Changing the value might be easier but it might not be less work overall.

Friday, November 01, 2013

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 " away from text to finish...".