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.
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.
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.
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.
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.