Ever have one of those projects where the walls go at some angle other than 0 or 90? Tired of trying to get walls to come in at 47 degrees? Try rotating your workplane.
On the Home tab in Revit, look for the Workplane panel on the ribbon. It is usually to the far right.
Click on the “Show” button, and you’ll see a blue grid over top of your floor plan. That is the plane that you are modeling in. To change your working angle, just rotate the workplane. Select the workplane and use the rotate tool.
Might be a good idea to rotate it back to its original orientation when you are done, to help avoid confusion.
When renumbering views on sheets, Revit requires each of those views to have a unique number. So you quickly drag the views you want on a sheet. You go to renumber a view to #1, and Revit says “nope”. Glancing at the sheet, you see no other view titles that use #1.
What’s the deal?
Almost every view on a sheet has a number, even if the title for the view isn’t reporting it. Elevations, plans, RCPs, sections, 3d views, area plans, and drafting views get numbered as soon as you put them on a sheet. And no two numbers can be the same on that sheet.
Look at the sheet again. Chances are there is a drafting view on there, or an overall plan that doesn’t show the number. Go to the view properties of that view and look for DETAIL NUMBER. One of them is already 1, or whatever number you are trying to use. If you don’t need that view to have a number, change it to something very high (like 99) that won’t get in the way of any other views you add to that sheet. Just because the numbers of views have to be unique, they don’t have to be sequential.
I recently did a presentation for Revit RVA called “A Day in the Life” that chronicled an actual day of Revit support I had recently. A topic that I brought up that got some interesting looks was the idea of the need for customized support.
I’ve said it before, but the premise is that not every user learns in the same way. Along those lines, not everyone responds to support in the same way, since at the end of the day a big portion of Revit support is getting your users to learn something new.
If you are support person, or want to be one, it is critical to get to know your users. That may seem like a no-brainer, but I have seen MANY support departments that to consider themselves floating in a little bubble, only sending help “out” and not taking the time to know their users and support them in a way that suits them.
This isn’t rocket science; a support person should know the technical level and experience of their users. Can you trust that they are communicating the problem properly? Do they just need a little nudge in the right direction or do they need you to walk them through the problem and solution? Is this time for them to learn what might come next for this issue, or is that just going to frustrate them more?
All of these mental evaluations can only be done if you know your users. It saves time for everyone, and the user gets a better support experience.
Sheets can be a tad confusing when you have them loaded up with views. Don’t forget that sheets themselves are views also.
What this means is that the sheet will have its very own Visibility Graphics settings. The Sheet’s settings do NOT override the settings for the views on that Sheet. So you can’t turn off walls on the sheet and expect to not see walls in your views. You need to go to each view and turn off the walls there.
So, be sure to pay attention to what Visibility Graphics settings you are changing. I have seen several occasions when the settings for the sheet were changed when the individual thought they were changing the setting for the view. It was chaos! It was madness! Dogs and cats, living together! (Not that bad. But we did scratch our heads for about a minute.)
I don’t think anyone is going to argue with such an obnoxiously vague statement like that. It’s kind of like saying “murdering kittens is bad”. Not a brave stance, but technically, it is correct.
A major part of what tech support is, is training. Someone does something that doesn’t work out the way they expected. If the support person is doing their job properly, they will look for any opportunity to teach the user a better way to do it. (Yes, I understand that sometimes this is not feasible. Let’s say, for example, the PC is on fire. There is no amount of training to help a user work past that. Just put the fire out.)
it has been my experience that if one user is having problems with something, there is at least one more who is having the same problem, OR, in the future there is another user who will have the same problem.
We work hard to share information about these little issues with everyone here at the firm. And since there are many different ways that people assimilate information, we have several different ways of sharing that information internally. (I also use this blog to share many of them externally – most of the “Quick Tips” are inspired directly by a question that popped up)
First and foremost, is one-on-one communication. Sitting down with a user, or remoting into their PC to step them through the issue is probably the most effective, but obviously not the most efficient when we need to let a large group of people know about the issue.
For long term documentation, we have two areas on our company intranet that we use: we have a BIM Manual, and we have a “news” section where we post “Revit Reminders”, and any major standards and content updates. The Reminders are small nuggets, again picked up from an actual user issue that occurred recently. The BIM Manual has more in depth instructions for topics that fit there, but it also has a section that collects all the reminders.
The third main avenue of communication is meeting for Revit issues. Once a month we have a meeting in our main office that we broadcast to all the other offices. We also try to record them and post on the intranet for folks who miss. Here we cover any of the little tips we picked up, major Revit related news, content updates, etc.
Finally, we have the old standby of email. This is for time critical items, and is usually limited to a specific team: “Get out of your model NOW! IT’S GONNA EXPLODE!!!”
So, we have multiple ways that we try to communicate with the end user, and we try to ensure that we have shared any tips through at least two of those channels, if not all of them.
Again, not everyone learns the same way, and not everyone can take in data the same way. It is NOT my job to force people to consume information in one specific way that I like the best. It is my job to try to get everyone in the firm to work better and smarter.
I have discovered over the years that I enjoy programming. My brain really gets a kick out tackling a logical challenge and overcoming the issues you can find when writing a program.
I’ve had the opportunity to create some really baby Revit Add-Ins over the years, and it’s been a while since I made something new. My work programming with Revit are limited because either 1) the amount of time it would take to program something isn’t worth it, 2) the Revit API is limited and I cannot actually accomplish what I want, or 3) I don’t have nearly enough knowledge in programming to get the task done properly. Usually, it’s a combination of all three.
This past week, I hobbled together some free time, and was able to work together the beginning of a new add-in. Unfortunately, it is probably also the end of this new add-in as well.
I have a backlog of items in my head that I wonder why Revit doesn’t do, or at least, do better. One of those is allowing for distinction in line weight in elements in elevation, based on distance from the “viewer”. This is an old standard in manual drafting days; if something was closer, you use a heavier pen, and if it was farther away, you use a lighter pen. Revit cannot automatically replicate this effect, and it would be nice if it could. You do get more information, or at least clearer information, when you have this.
Granted, you could do this manually with element display overrides, and I have seen folks do this, but at the end of the day this is tedious and prone to errors. I have also seen some other solutions, but nothing that didn’t seem dangerous, BIM-wise.
So, I took a whack with the API. After some head scratching, sketching, and basic geometry, I had a workable prototype.
Top secret notes!
In any cropped elevation, it would slice the crop into thirds; near, middle, and far. Any wall (I started with walls only to keep things simple) in the “far” zone was set to halftone, walls in the “middle” had their surface pattern color set to a dark gray, and finally the walls “near” the viewer, had the projection lines beefed up. Pretty straightforward idea, and it worked well on my little test model.
BeforeAfter
I got pretty excited. Technically, it was still the manual trick of overriding the element’s graphics, but it was done with a single click.
And then I started thinking about modifying the code. I wanted to add an option to allow the user to select where the “near” and “middle” started…which wouldn’t be too tricky. I probably should add an option to allow some user selection of lineweights… not awesome, but not bad. But first I would need to build in other categories. I looked at an elevation print I had sitting on my desk and started planning out each element. Let’s start with the rood!
And that’s where I realized my problem. Many times, when a roof gets modeled, it is a single element that covers the entire building, whether it is a flat roof or sloped. So that is a single element that is in all three “zones”; near, middle, and far. If the roof has sections that show up in each, they will all have the same element override, pretty much ruining the effect.
So, I sat and stared at my wall for a bit, trying to come up with a way around this.
My wall
But even the zen of Lego couldn’t get my brain to an acceptable solution.
So, this programming project is gonna get put in the file cabinet for now. Maybe I’ll come up with a genius realization one night in my dreams! Maybe the solution will come to me while I stare at a pile of mashed potatoes! Probably not. Usually the pile of mash doesn’t last long enough for me to have any epiphanies.
This means something…
I’ll keep programming, and I’ll probably keep banging into walls. But every once in a while I’m able to polish off a little gold nugget, and that seems to make all the head banging OK.
Every so often, you may still need to get the linework from an AutoCRAPfile to show up in your Revit views. I know. It’s sad, but true.
I am fully in the camp of not needing ACAD to do drafting. I know there are a LOT of folks out there who swear by this process, but I don’t buy it. Time to throw off the crutches, I say!
Once in a blue moon, you may need to get access to ACAD linework in your Revit model. Our rule of thumb is that 99.99% you need to make sure that you are LINKING the .dwg file and not IMPORTING it.
Importing will suck all the linework from the .dwg file and put it into your Revit file, adding each layer as a linetype which can cause chaos and confusion.
Linking the file will give you the classic link “onion skin” effect, where the contents of the .dwg can be seen in your Revit model, but not touched. Changes to the .dwg can be reflected in the link. And you can control the appearance (linetype, lineweight, color) of different layers from the linked .dwg by going to the view’s Visibilit Graphics.
LINK, do not IMPORT your .dwgs and your Revit file will be much happier for it.
Fun fact: Revit even when you link in a .dwg, Revit “imports” the contents of the file into your model, it just keeps it in a nice “quarantine”. This is why a linked .dwg will still appear in your model, even when Revit warns you that it can’t find the .dwg file. It’s also why linking in a .dwg file causes your Revit model to bloat up like me at a donut store!
This isn’t the first place this issue has been documented, nor will it be the last place, but it reared its monstrous ugly head the other day.
A Revit user was printing out individual PDFs from floor plans, and reported that the filesize was HUGE. I was dubious at the hugeness, so I grabbed a couple and took a look:
Whoa. Yeah, that’s a big PDF
OK. So maybe they were a little big.
Some of you probably already know the issue. It turns out, if you use a non-rectangular crop region and print a sheet, some PDF print drivers freak out, exploding your file size.
It feels like a lot of them are getting better, but these users were using a recent version of PDF Creator (because we really like the price) and still getting these results.
Printing the PDF again as a PDF seemed to trim a lot of the file size. Also using a “stepped” edge instead of an “angled” edge helped out as well. Which was weird.
Strange – smaller PDFWeird – larger PDFs
Hopefully this will clear itself up eventually, and this post can be something we all can look back on and laugh and laugh and laugh.
In your Revit model, the level is the key starting point. Everything, ultimately, relies on the level.
Floor plans and RCPs are directly associated with a specific level. You cannot have a plan without a level. And once a plan is tied to a level, it cannot be associated with any other level.
This tight integration between level and view also can cause the NAMES to be tightly integrated. By default, the name of the plan or RCP view for a level is the same as the actual level name. Renaming one can change the other. And this is precisely where you need to pay attention.
We all have gotten somewhat lax about reading the warnings that any software pops up, usually clicking YES or OK without thinking. In Revit, we need to read the pop ups. It is trying to tell us something and quite often, it is trying to tell us something important.
When you rename a level, Revit will ask you if you want to rename the associated views. Likewise, when you rename a plan/RCP view, Revit will ask you if you want to rename the level. There is no set rule about clicking yes or no, the only rule is that you need to read what Revit is going to do and figure it out.
Example 1: you start a new model, and you rename the default “Level 1” to “FIRST FLOOR”. Revit asks if you want to rename the associated views. Well, yeah, you probably do. It wouldn’t make sense for you to have your level be “FIRST FLOOR” but the associated plans be “Level 1”. So let Revit rename away.
Example 2: you have a model that you have been working on and you create a new floor plan to show the existing phase of FIRST FLOOR. You go to rename the view to “EXISTING FIRST FLOOR” and Revit asks you if you want to rename the level. In this case, no, because it would change the level name from “FIRST FLOOR” to “EXISTING FIRST FLOOR”, which in this model makes no sense for the levels.
So, the big rule is to read what Revit is telling you, and make a proper decision from that.
So, you’ve created your group, and you are about to place an instance of it. You want to nudge it into the corner of the room, but the origin of the group is smack center in the group. So you place, then align, then align again. And you have to do this in each room. Too many clicks.
Wouldn’t it be great if you could move the origin of your group? Wouldn’t this be a bizarre article if you couldn’t?
So, to “slide” the origin, selec the group. You’ll see a half compass with X and Y on it. Just click and drag the “center” grip and move it to the new origin. That’s it. Your group has been updated and any new instance of that group you place will use that origin point.
Every so often, you may still need to get the linework from an AutoCRAPfile to show up in your Revit views. I know. It’s sad, but true.
Design Tech Field Guide 