What I Learned at AU 2018

This is gonna be an atypical post. I think I am still processing this, and not 100% sure what to do with it. And it’s not gonna be a shocker to a lot of you, but it came into sharp focus for me… in Las Vegas of all places.

I really enjoy going to conferences and teaching sessions and having nerdy conversations with folks there. I always pick up new tips and clever workflows that I am really excited to take back and kick around.

I’ve been going to Autodesk University consistently for the last few years now, and have taught at most of them. The first few years was all about learning how to speak in public, craft a message, and wear a jacket because I would get all nervous sweaty. I still have a lot to learn on all those items, but I am at the point where I feel way more comfortable just looking out in the audience and having fun.

I don’t think the audience make-up was any different this year, but when I looked out  at the crowd something clicked and I can’t seem to shake it: wow do we in design technology have a diversity issue… or lack of diversity to be more specific.

It was always a big joke that when you go to AU the men’s room line is way longer than the women’s room line. That was funny for a while, but it doesn’t seem funny any more. Clearly the vast majority of attendees are male, and the vast majority of those male attendees are white; full disclosure – just like me.

Why is this a concern? I have seen it personally, but time and time again, leaders across industries that I respect always say that different people from different backgrounds have different solutions to problems, and as someone in an industry that thrives on fixing problems, the more solutions we have the better off we are.

I’m not sure if this post will end up being more controversial than the Demo Is Not a Phase one I did a while ago, and like I said, I think this won’t be shocking to a lot of you and it probably shouldn’t have taken this long to be shocking to me. But it is.

Sorry this isn’t a technical post like the usual ones. I have another outlet for those these days on my work blog (and this is DEFINITELY a “me” post and not a “work” post). I did want to get it out there just to say I am going to do what I can to try to help fix the diversity issue that the design technology practice has and I am 100% open to any help, tips, pointers, or guidance along the way.

Thanks for listening.

What Revit Needs Now

I’ve been reading Peter Diamandis’s great book, Abundance, and it’s forcing me to stretch my brain more than I am used to. I am nowhere near smart enough to try to think about big world impacting issues like he outlines, so I thought I’d really noodle on Revit as a tool and try to figure out what I think it needs based on what I see as happening in the design and construction industry.

This has led me to two short posts, this being the first one of what Revit needs NOW.

Modular design

I won’t bury the lead: Revit needs a much better way to facilitate modular design. And I am thinking at a high level and I might be using that term in a way that deviates from the usual usage, so I’ll try to break it down a little bit.

Multi-unit design

Multi-unit design has always been a glaring omission in Revit. Have you tried to lay out a hotel or multi unit residence? There is no one way that Revit users have pointed to as “yup, that’s the way to do it”. I’ve seen groups, I’ve seen links, I’ve seen copy/paste from other models. Each process has its pros and cons. I don’t see any of them being the final solution, so Autodesk really needs to come up with a new function to handle this in a clear and sensible manner. These workarounds have gone on long enough, and it’s time to fix it.

Modular elements

This is one I wasn’t really aware of until I started doing some research for this article, but this (sadly) archived Idea points to the limitations of pre-cast/pre-made structural elements that include system families. Obviously, loadable families cannot include system families, so what to do? I can’t think of any great solution, just some workarounds like our friends trying to tackle multi-unit design.

Image from theconstructor.org

Pre-fabricated construction

This is also happening right now – elements and entire sections of a building are being made off site in a warehouse and then shipped to the construction site. Revit cannot support this workflow without, again, some weird workarounds. When I used to work in design I did a lot of jails and prisons, and we had several projects where the entire cell was being made offsite and shipped in by trailer. We went round and round trying to figure out how to get Revit to let us make these Lego pieces of our model and snap them in, with no good solution. And this was YEARS ago. This isn’t something new.

How to fix it

I feel like (and I could be totally wrong here) the above issues are really the same issue, and it feels related to the inability to identify system families outside of a project file. Yes I can link them in, but that’s a lot of overhead. Sure I can use groups, but there is always something buggy about groups and they have burned me more than once. When assemblies showed up I was excited that they were going to fix all of this, but they have their own issues.

We need something like a module category that you can open and tweak the module in the family editor or even a module editor. Walls, floors, rooms, spaces, loadable components; all are fair game in a module. And I can then save them out to my library for use across projects.

I am certainly not the first one to come to this conclusion (here, here, here, and probably others I just didn’t find), but I think it’s a huge oversight from Autodesk. This is a design and construction technique being used RIGHT NOW and with the growth in 3d printing technology, the use of pre-fabrication and modular design is just going to grow.

This isn’t a design and construction feature that can be or SHOULD be shoehorned into a current Revit function or workflow. It needs its own space and needs to be smartly figured out and implemented.

Tiny Windows and Graphics Cards

Recently saw a Tweet from Tom Whitehead concerning a teeny tiny window that showed up in his Revit. While it wasn’t EXACTLY like a problem that has been occurring over the last few years, it looked awful close to a problem that has come up with Revit and desktop management software like nView and Hyrdavision.

.@AutodeskHelp Any ideas on this? 2016 r2 UR12 pic.twitter.com/nwPbRKjDLR

— Crusty McFussypants (@swittersTX) February 9, 2016

I dropped Tom a quick note to test out my hunch, and it turns out that yes, nView was the culprit.

So what exactly is going on here? Honestly, I’m not really sure, and there hasn’t been an official fix from Autodesk; they have a page that outlines a less destructive fix than I do, but if I can take a hammer to something, I’m gonna take a hammer to it. But if you are using Hyrdavision or nView, you might see these random tiny windows. Traditionally, they have been the size of a postage stamp, with mainly just the X close button, and the tiny window is usually sitting in the middle of Revit.

Disabling nView or Hydravision seems to alleviate the tiny window syndrome (T.W.S. for short). When installing new graphics drivers, I will typically go the “custom” route and just not install either of those features and skip the hassle of having to disable them later on.

The earliest I have seen mention of this issue online is 2009, and that is probably close to when I first saw it as well. It’s stupid, and it’s annoying, but at least it’s easy to fix.

Quick Tip – Clean Up After Yourself

After you import a view from another model, clean it up. There is a chance that it brought in some new annotation styles, or detail items. Change them all to corresponding elements already existing in your model, and then delete the newly unused ones that just came in.

One of our most notorious examples is the infamous Break Line. Each drafting view we imported had a copy of the break line family. By the time anyone noticed, the project model had “Break Line (1)” through “Break Line (22)”. We have since updated our details to avoid detail components and be exclusively linework, but something always seems to slip by.

A clean model is a happy model!

My Wishlist – Parameter Concatenation

“Concatenation”… That is a really long word, and full disclosure, I had to Google how to spell it.

The opening of the Revit API has done a great job of filling in gaps in Revit with some fantastic solutions. I am all for letting some features be done by third party developers; often they are closer to the problem and have a very unique approach to a solution that is clean and effective. Unfortunately, there are some fundamental things that Revit cannot do properly that an add-in only halfway solves.

Combining of different parameter values into a single parameter is one of those things that there have been some great solutions for with macros or Dynamo or add-ins, but they are all just stop gaps; they need to be run periodically to properly fill in that final parameter. They are not “automagic” and won’t keep an active eye on the parameters that they are combining.

It is past time for Revit to be able to do this natively and actively and consistently. I would imagine the easiest would be to have a calculated value, but that of course would not be ideal with the limitations around lack of tagging, etc. Some syntax for a shared or project parameter that allowed combining other parameters and they would stay up to date all the time, that would be the ideal solution.

This is a huge addition that I would love to see in a future release, and I am confident I am not alone. Until that time, unfortunately, we will have to keep rolling with band-aid solutions.

Quick Tip – WARNING WARNING WARNING

Revit has two types of issues that it tries to make you aware of and deal with, the ERROR and the WARNING.

You cannot ignore an Error.  It just won’t let you finish the task you are working on.  You have to deal with it right then and there.

Warnings will actually tell you in the box that they “can be ignored”.  Even though it says that, try not to ignore it.  Try to remedy the problem right then and there.  Why?  Certain types of Warnings can REALLY slow down a model.

And if you “accidentally” skipped one, you can go back and find all your warnings by clicking the Review Warnings button on the Manage Tab.

Quick Tip – LINK vs IMPORT

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!

Giant PDFs

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 PDF

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

Weird Walls: Depth, Height, and Function

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.

Revit 2015 Update 2 – This Isn’t Confusing At All

Autodesk recently released Revit 2015 “R2” for subscription customers (sorry people who don’t like to write a check every year!) and while it has some nice features that I am looking forward to, the versioning of Revit 2015 to this point has become almost labyrinthine.

In the beginning…

First, there was Revit 2015. Makes sense, easy to remember.

Then we had Update Release 1. OK, I’m with you. Then Update Release 2, which was the “Security Update” because of Heartbleed.

It’s usually around this time that I start looking at creating my deployment. Hooray! Update Release 3! But when I add it to the deployment under Service Packs, it’s called “Revit 2015 Version 4” there. Um, OK. I’ll play along.

And now we have R2 (their words). And when I apply that to the deployment, it’s called “Revit 2015 Version 5” and after it gets installed, if you look at HELP > ABOUT, the version says “Update Release 4”.

Nice and consistent.