Google Analytics (Hidden)

Monday, August 27, 2012

How to deal with Legends in Revit

Edited due to remarks made by Forum users. Some pitfalls for the use of Assemblies added in light of honest comparison between the different options.

First of all:


And breathe...
But seriously: It's an insult to all of us working on real projects needing to do real documentation. I have been on Revit since version 5.1 and it has been useless as long as I can remember (don't even know if there were Legends on that version, but if there were: they sucked back then too).

Why are legends bad?
1. You can only have a few different views: plan view, front and back elevation. How about sections? How about 3D views?
2. No tagging, no way to extract data from the elements (THAT is the freaking purpose!!!)
3. NO connection to the elements actually used in the model. If an element is deleted, it will remain in the Legend. No way of counting elements.
See image 1.

Image1: Useless crap

So: useless crap it is... The question is: what should it be like then? There are a few options, listed in order of usability:

1. Phases

The easiest to set up, but also the hardest to manage and check for model compliance.

Image2: Adding Legend Phases

Image3: Creating Legend Views and setting component Phases

Image4: Creating a coordination schedule
- Create two extra Phases: Legend and Demo Legend. Place them before the regular Phases, see image 2.
- Duplicate a Plan View, set Phase to Legend and place your Legend components. Select all Legend components and set the options to Demolish in phase Demo Legend, see image 3.
- Create all Legend views you want and Tag away happily.
- Create a Door schedule with 3 columns: Family and Type and Count. In the Properties screen, Sorting tab, sort by Family and Type. Check off "Itemize every instance". You now have a overview of all types in the model. Now duplicate that schedule and set the Phase to "Legend". You can now compare both schedules side by side to see if all elements are accounted for see image 4.


- Total control over Legend views, tagging, and so on.
- No influence over the model, no need to hide things in regular model views
- It's possible to create schedules to check whether all types are accounted for in the schedule.

- Lot of work to set up views.
- No way of distinguishing different instances, there's only a limited amount of parameters that can be used to sort the schedule.
- Needs working knowledge of Phasing
- Needs two schedules and the ability to check them side by side. This could get difficult in large models with lots of types.
- Needs extra "space" in the model to place the Legend components.
- Not very suited for Legend views of multiple components (for instance a room layout, windows with ornaments, window sills and such).

2. Design options

Image5: Adding Design Options

Image6: Adding elements to a Design Option

Image7: Setting up coordination schedule

Image8: Coordination schedule
A bit harder to set up, but has better ways of checking for Legend-Model consistency:

- Set a Design Option Set called "Legend". Add 2 Options: "Model" and "Legend". See image 5.
- Duplicate a Plan View and place all elements you want to create Legends view from, somewhere outside the model's extents. Due to the setup of the Design Options, they will not be visible in the "normal" model views. See image 6.
- Create all Legend views you want and Tag away happily.
- Create a Door schedule with 3 columns: Family and Type, Mark (or any other text instance parameter) and Count. In the Properties screen, Sorting tab, sort by Family and Type and then by Mark. Check off "Itemize every instance". You now have a overview of all types in the model, see image 7.
- Go to the Legend door, select it, fill out the Mark value as shown in image 8. All the "normal" doors have a blank value.

Image 7 shows us that there is one type in the model that does NOT have a Legend component... This is a fast and reliable way to check whether all TYPES have Legend components. It does not help with instance based deviations...

- Total control over Legend views, tagging, and so on.
- No influence over the model, no need to hide things in regular model views
- It's possible to create schedules to check whether all types are accounted for in the schedule.

- Lot of work to set up views.
- No way of distinguishing different instances, there's only a limited amount of parameters that can be used to sort the schedule.
- Needs working knowledge of Design Options
- Needs extra "space" in the model to place the Legend components.
- Not very suited for Legend views of multiple components (for instance a room layout, windows with ornaments, window sills and such).


3. Assemblies

My new favourite, and very close to what the Legend feature should be:

Image9: Creating an Assembly
- Place your components in the Model. Select a component and choose "Create Assembly" from the contextual tab. Choose an appropriate naming strategy (I use the family + typename which can expand dramatically when you're creating Assemblies from multiple elements), see image 9.
Image10: Selecting Assembly Views
- Select the Assembly and choose "Create Views" from the contextual tab. Select which views you want, and if they should be placed on a sheet, see image 10. Tag away happily. 
- Select next item, repeat the steps above. IF your element matches an existing assembly, it will turn into the same one, see image 11. Best part: this is on instance level! So if you have different instance parameters, it will be a new Assembly. Only problem: when using a unique Mark value to differentiate between different elements of the same kind.
Image11: Duplicate Assemblies are recognised
- You can tag the Assembly in the model to refer to these Assembly views. Which solves the Mark problem...
- Create a Door schedule as shown in option 1 and 2. Add an extra field "Assembly Name" to check whether all components have been added to an Assembly.

- Legend Views with the click of a mouse button.
- Total control over Legend views, tagging, and so on. Crop Regions can be rotated to meet specific needs
- No influence over the model, no need to hide things in regular model views
- Simply add a column to your object schedules to check whether all types are accounted for in the schedule.
- Recognizes differences on an Instance Level.
- No extra "space" needed in the model to place Legend components
- Suited for Legend Views of multiple components.
- Easy to use workflow.
- (Shared) parameters can be added to assemblies to allow tagging and scheduling.

- Instance parameter awareness can be a problem, however this is manageable by adding those parameters to the Assembly itself.
- There's no way to port parameter values from the objects inside an Assembly to the Assembly itself without using the API
- It would be nice to be able to create Embedded Schedules for Assemblies to have both the Assembly AND the underlying objects in one schedule.
- Most annoying one: you need to manually place all elements in an Assembly one by one. No way to batch-create an Assembly. No way to properly place an Assembly when it's (wall) hosted (try placing an Assembly door...)
- MAJOR BIGGIE: Assemblies do NOT update when changes are applied to instance parameters. WTF??? It recognises differences in instance parameters upon creation, but not when changing them? I thought Revit ALWAYS updated modelled stuff? What the hell kind of cad solution is this?
- Adding objects to an Assembly (for instance, adding a windowsill to a window) creates a new Assembly type. Which is in some ways logical, but also a shame. Verdict on this one is still out...
- Groups cannot be Assembled (is that the correct term?). I get this, I think, because Groups are in many ways similar to Assemblies. I can imagine that these two might collide, but it's not perfect.


Legends suck. They suck for text notes, they suck for diagrams, and they suck big time for building components. The first two options described here are at best mediocre workarounds with lots of pitfalls and tons of extra work.

Then there were Assemblies... And all was better.
Provided Autodesk fixes a few minor bugs, it is the documenting feature we have been waiting for, for a LONG LONG time.
As far as I'm concerned, Autodesk can delete the Legend tool all together. I will be sticking with Assemblies for Building components from now on (and Generic Annotations for anything else).

HOWEVER: when you're on big projects with lots and lots of types, this solution might not work for you. Because whenever an INSTANCE parameter changes, you'll need to update all Assembly instances in the project. Which sucks big time. It's doable on smaller projects, and it works well when you're changing type parameters. But not when changing INSTANCE parameters. And that is a shortcoming well worth noting. (off course, you could do a "select all instances" > change, but it's the principal of things)

O, I added my sample files to this thread on

Happy Reviting,
Mark Twain

Wednesday, August 22, 2012

IPD: Curse or Blessing?

Social media debates...

Read an interesting discussion on Twitter yesterday, followed by two blogposts. The first one was from Antony McPhee, the response came from Liz O'Sullivan. Both put severe questionmarks at the use of IPD.

I must say I wholeheartidly disagree with their statements. And, for the sake of a nice debate, I will try to counter their statements in this blog. Keep in mind though: even when disagreeing with everything a person says or writes, I do so while fully respecting their opinion. This is just my opinion, and it's different. Not better or worse. I very much liked to read their blogs, I found them both well written with properly formulated arguments. I just see things differently, without adding ANY judgement to that...

To start in alphabetical order, with Antony McPhee...
I'm not debating the intents and purposes of the AIA document Andy discusses. I see them somewhat more on the positive side, but that's probably why we have a different opinion. The main question in Andy's blog is: why should architects work with IPD?
Is it money? IPD isn't profitable for architects. Why shouldn't it be? BIM requires an investment from architects in the early stages of design, that much is true. And they are only compensated when the architect is also responsible for construction documents. That's where they're supposed to pay off... But traditional contracts do not by definition ensure the architects involvement in this stage. IPD does, everyone is in it from beginning to end.
Is it influence? The architects influence of the design process decreases. The architects influence may be smaller yes. Is that a problem? Where I come from we have a saying: if you're liable, you get to make the descisions. Period. So I don't see why the architect would give up on influence over architectural matters. As for all other matters: how many architects are walking this earth that NEVER had to alter their design and make it suboptimal, basically cause they found out it was too expensive? It happens all the time. Upside with IPD: it happens while you're sitting at the table, doing your thing. Not AFTER you finished a worldclass design. In my opinion, budgetcuts during design, opposed to fumbling after it's finished, lead to a better endresult 99% of the time.
Is it control? Architects will lose the control of the model. I don't get this argument. Either you're controlling the model (WITH all encompassing liabilities and responsibilities) or you're not. That's something you define in your contract and never look back at. No change there except the fact that a more integrated workflow will ask more capabilities from the people managing it. Architects SHOULD ask themselves whether they want that or not. It's not something you do on the side, not even with smaller, less demanding projects.
Is it market share? The need for architects will diminish when using IPD. Also not getting this... A contractor by definition wants to fill the world with grey boxes? An owner by definition doesn't give a crap about estheatics? Not in my book. Sure, some don't. But those are the same as the ones delivering grey, non-architectural boxes now. Let's not kid ourselves: even in the time of pencils on paper butt-ugly architecture was around. It will always be...
Is it industry leadership? Why should architects push this if others aren't interested? Well, I guess they shouldn't. In Holland, much like Australia (and probably the US too), the vast majority of owners and contractors don't even give a crap about BIM, let alone IPD. But they will NOT be the ones asking for it. IPD requires some serious investments from both contractors and owners too. So let's just assume that if an owner specifically asks for IPD, and commits himself to the investments in time and perhaps even increased design costs, they mean business.
Is it benevolence? Should architect push something that will eventually only benefit owners?
Yes, they should.
Did I miss the memo stating architects no longer provide a service and therefor BY DEFINITION do what's in the best interest of the owner, their client?
Is it fear? Fear of being left behind, fear of being irrelevant.
You bet! And it is the owners proper right to find someone who will bring his project to the best end possible. If architects refuse to embrace IPD, chances are that in a not to distant future, they will lose  a significant portion of the market. Is that a bad thing? No, it's called innovation. It happens all around you, why should architects be different?

Now Liz agrees with him in a lot of ways. Which off course in return means I disagree with her too in a lot of ways... Not wanting to repeat myself I'll just restrict this to her "unique" comments:

Architects can get the same input and quality when it comes to actual construction elsewhere. No they can't. It's been proven time and time again. A cost estimator looks at a design as is and calculates what it should approximately cost. I rarely see cost estimators putting alternative methods of construction on the table. That's not their job. Besides that, he/she has no knowledge about the contractor, their strong points, weak points, and preferred methods (which will be cheaper). A vast majority of construction changes are based on this fact: not that the design is wrong, it just doesn't "fit" the contractor or the preferred methods of construction.

Example & my take on things:

I'm working with a few of the largest dutch firms in various disciplines to come to an IPD Protocol. Architect and GC have done previous projects. When I asked why they wanted to go to IPD, one of their answers was:
"We recently did a traditional project. Once the design was finished and the GC's bid was accepted we had to do all kinds of changes. Nothing architecturally important, but one eye-catcher was that we lowered the level-to-level height with 8cm. Why? Cause then the entire facade could be prefabricated. Initial design didn't fit in the subcontractors workshop, nor did it meat traffic regulations. With this change we saved a LOT of money".

This for me is the essence of IPD. The architect never made any mistakes. The contractor is not out to destroy the design. This could not have been prevented in any way UNLESS you already know who the GC will be and use their specific knowledge about construction. In fact, with the money saved some previously architectural budget cuts could be restored. But at a cost. It wiped out most of the architects profits (which they were compensated for by the GC) and a substantial part of the GC's profits (which they still did cause it made the building better and helped them stay within construction budget). And those expenses could have been saved when the GC had been participating from the start.

In my humble opinion, every IPD contract should have a few parts (besides the legal and technical mumbo-jumbo):
1. Define the design question, both in quantity (Square Footage, cost of ownership, and so on) as is quality (LEED certification, Facility Management demands)
2. Define budget from earliest of design until the building is delivered to it's owner. Construction funds AND design fees. Define what happens with profits and losses.
3. Define who does what, where, when and how. And which part of the total fee is involved. If you're granted a task, you are primary liable and therefor have a right to veto. But you're also bound by budgets and design specifications.
4. Give and take. ALL participants are responsible for the endresult as a whole. That means you cannot have your way
And that's that. In my, probably overly naive, point of view this should be enough. Yes, maybe as an architect you will be marginalised. But it will be done in the contract, before you even start working. To put it in simple terms: if you get screwed, at least it's all in writing and you were there when it happened. But in most cases GC's are very aware of the fact they need an architect to make the building rise above mediocracy. And owners are happy to spend their full budget to get the best possible design. Most of the times I participated in IPD projects any and all design changes in favor of the GC were done in harmony and the profits re-invested in making the design better.
If that's not a win-win-win I don't know what is...

Friday, August 17, 2012

How to work with large (linked) files

Very interesting discussion in RFO taking place. The thread started with a question about best practises for sharing models with consultants. For me, it became very interesting when the discussion wondered around post #16 to purging models before linking them in. A post from a Curtain Wall detailer (important detail, no pun intended), let's call him Dave, set the debate on fire: his current project had a few links in them, six to be exact. Largest: 517mb, and a few 300+ mb files.
Quick calculation adds up to a staggering 1.5GB of linked Revit models (no pointclouds to my knowledge).

Naturally his performance was lagging so he had been looking into purging the models. I, amongst others, don't think that's a very good idea. Why not?

1. Revit works with a database. That means that all families you load are stored inside that database once and then referenced from the model. Different types get separate additional info or something. Don't quite know how it works, what I DO know is that you can put window A one time or 100 times in your project, it's not going to make a difference in size. It does make a difference in regeneration time off course. Same goes for views: the settings (what kind of view, where is it at, what are we showing) are stored somewhere inside the database but only utilized when called upon.

BUT: logically this means that families inside your project that are not being used do NOT affect the responsetime when working on the project. They're in the database but they are not referenced. So they are dead weight. Same goes for views, sheets and all other stuff floating around in the link: as long as it's not referenced, it's of no importance to the model's performance.

2. Dave tried purging all his links. Which cost him more then a day from the looks of it. I mean, if it costs you 3 hours to LOAD the purge screen, how long will it have taken to actually delete all that stuff. And that times 6! What did it get him?
- The architects model went down in size from 517 to 397mb
- A structural file went down from 381mb to 325mb.
With that he reported a significant increase of responsiveness (if that's even a word) of the model. In plain english: it worked better, more smoothly, with lots less regeneration time and so on.
Which, according to my statement above, shouldn't be possible... So who is right here?

I think that this is a big numbers thing. With every action you tike while modelling, Revit needs to search it's database for the corresponding elements. That takes time. If you cut down a 1.5GB model to 1GB, this is going to affect search time. Simple as that.
HOWEVER: this effect is limited. You can purge only so much and let's face it: if modelled and delivered to you right, you shouldn't be able to purge out 25% of the filesize anyway.

3. Dave decided to skip weekly updates of the links because that would mean going through this entire process again. Which in my very humble opinion is a logical but very dangerous complication.

So what IS a working solution?
Let's assume the model has worksets in it. If there weren't any, my advice wouldn't be much different. Just skip step one:

1. Open the link. If needed, purge all worksets. To do so, see image 1 to 4.
2. Re-enable worksets, move all items to the default "Workset1" when prompted.
3. Add 1 workset. Call it "Load" or something, see image 5.
4. Move all items you wish to work on/with to this workset. To do this, select them in your model and go to the Properties window. Change the Workset from Workset1 to Load, see image6.
5. Open the Workset Dialogue Box and set Workset1 to be not-loaded, just to check whether you got all the elements you need, see image7.
6. Link the file into your own project and presto...

Image1: Select file you want to Link and click Detach from central
Image2: Disregard the warning (if prompted)

Image3: Select all worksets to load

Image4: The money shot, delete all worksets present
Image5: add your own worksets

Image6: Add desired elements to your workset

Image7: check if all is well

WAIT A SEC...!!! (got ya)

Still seeing the entire model? That might be correct. When linking a model you need to specify the worksets you want to load. When selecting the link you need to set the options for "Open" to "Specify", see image 8. Then in the next window select Workset1 and hit Close, see image9.

Image8: Selecting the option to specify Worksets

Image9:  Specifying worksets to load

I did this with an 80mb file.
The full link took about 55sec to load  in the first place and after that 10-15sec on actions like
- selecting the link
- creating a section view
- switching views.

When testing the workflow I took one elevation and placed the Curtain Walls in a workset. Needless to say that the reload, selecting, sectioning and all that stuff was pretty much instantly.

Now as you might have noticed I used a project which already had worksets in them. So why not use those? Well, because they didn't meet my needs. By discarding the original worksets and creating my own I could handpick all items I needed to work on for this elevation. In this case, worksets were made for ALL elevations, structure, interior, and that sort of thing. I figured that if I was Dave, I would be working on one elevation at a time. So by handselecting the elements needed for a specific (set of) tasks I could minimize the dead weight in my project file even more.

Another great thing about this workflow:
I could also use a naming strategy and create predefined worksets for all elevations separately. Now, when reloading the link in my project I can very quickly switch between building parts I need to see and/or work with by Closing and Opening Worksets through the Manage Links window.

In conclusion:
You will need to do this with every new set of consultant files you get. But in my opinion it will go way faster then purging. AND it gives you more flexibility and better results.

Happy Reviting!
Mark Twain

Monday, August 13, 2012

How to create a timber framed wall with base extended cladding

First of all I want to apologise for staying away so long. Frequent users of might have missed me there too... Let's just say that I've been insanely busy with some major projects and had to severly cut back on all other activities.
Also, my doctor made me step down a notch due to some developing signs of a serious Revit addiction. Having established that there's more in life then my laptop I can now safely return to action and make up for lost time!

Wait, that doesn't sound quite right...

Anyway: since my return on RFO I've been starting to stick my nose into some threads and found this one which sounded nice.
Especially liked question number 3 since that's one I deal with o a regular base too.

It boils down to this: how can I create a wall with two differents base heights. Usually one for structural part (sitting on the floor) and one for the finish part, extending downwards.
Now there is a tool in the Wall function that let's you "unlock" wall layers and extend them seperately. I don't like it, too much manual labor involved.
Off course, we could also use Parts (NOT!!!)

My favourite solution is seen in image 1 and 2:

image 1

image 2

1. Select the Wall, and change the Base offset to the desired extent.
2. Click on Attach Top/Bottom in the Modify Tab
3. Select Base and then select the Floor.

Why use this one and not just Join?
Well, basically because this option will keep the floor attached even if it's shifts beyond the extents of the Wall. Set the Floor offset from Level to -500 and see what happens. With the Join tool, you get a lot of pesky error messages and the connection breaks. With the Attach-tool, it doesn't.

Now to make matters somewhat more interesting, the follow-up question was this:
I didn't realise that worked with walls. With cursory examination it seems to also resolve an Issue I was having with the 'timber framed walls' extension which would frame to the lower extension lavel, not the bottom of the framing. The one thing it breaks though is that in NZ, timber framing must overhang your floor by 10mm, and your cladding extend 50mm down. Your method has a 10mm strip of framing down the edge of the floor....

If I get this guy right, his problem is as shown in image 3.But this too is easily fixed by adding a reveal to your wall.

image 3

First, create a profile family as shown in image 4. 

image 4

Use the Profile - Reveal template for this. Make it parametric so you can use it on multiple occasions. Make the parameters Type Paramaters so you can edit them through the Project Browser (find the family in the PB > expand > select type > rightclick > type properties)

Second, select the Wall > Edit Type > Edit (structure) > Open the Section Preview. Now add a reveal to the Wall, shown in image 5. I don't use the setback values inside the Wall. Don't know why, I just like to control the size and placement of the reveal inside the reveal family. But YMMV.
Whatever preference you have: image 6 shows a perfect solution...

image 5

image 6

Happy Reviting
Mark Twain