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.
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 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.
When we first started looking at Revit, it was strongly recommended that we AVOID the Keynotes. And after reading the workflow, we decided that was good advice.
But I never tried it out myself. I’m kind of scared at this point.
And now, years later, I still have never used it. I understand they have made some improvements over the years, and have decided it is now time to dive in and try it out for myself.
There are many things that I have trouble doing (touching my toes, for instance) and forcing myself out of my fear-based practices is one of them.
We have been told that it is a MUCH better experience when you get a keynote manager add-in. Although a 10 second Google search shows there is mainly only one player in that space. Oh! Maybe it’s time to dust off the old API and write something! Nah. Probably not.
So, wish me luck! I might come out the other side with a new found appreciation of an unused tool, or I might just get angry because I wasted two hours on something that still sucks!
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.
Let’s say you need to align something to the center of a circle or arc or ellipse, or vice-versa, you need to align the center of a circle or arc or ellipse to something. When you are in the ALIGN tool and try mousing around the center, nothing shows up. You also cannot override your snaps to find it!
Calm down! It’s gonna be OK. Select that circle (or arc or ellipse) and check out its Properties. See that parameter? CENTER MARK VISIBLE.
Put this in the category of “The Missing Revit Manual” in the same chapter as “View Discipline“.
Turns out, Wall Function isn’t just an extra parameter to filter by. We just came across this one. When you change the Wall Function to FOUNDATION, it forces the placement of those wall types to be “Depth” and not “Height”.
Did you even know that was a thing? I would say that 99.99% of the time when a wall is placed, it is assumed to go in the positive Z direction, or in other terms, “up”. The good old Options Bar lets you change the placement from “Height” to “Depth” meaning you can make your wall go “down”. Who changes this? Does anyone ever change this?
You didn’t even know it was there, did you?
Anyway, if you change your Wall Function to “Foundation”, you can ONLY use “Depth” which can cause some hilarious errors as you place a wall.
I am confident some of you knew this already, but it’s news to me and it was news to everyone who I talked to in real life (or “offline” as the kids say… they don’t really say that).
The HELP file has nothing that lays out what specifically happens when you change the Wall Function. I guess it’s time to dive in and see what else might change when we adjust that previously-thought-innocuous parameter.
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 