Revit, Linking, Scalability, and Nuclear Families (not the Revit kind...)

Not in the sense of a family, anyway. :)

So by now, everyone has read the press release on features coming in Revit 2009. I'm happy to say i've had the opportunity to play with it a bit, but rather than cover features already covered, id rather wax philosophical on what ONE of the features might mean. I say MIGHT, because this post was coming before i found the feature, because for me... It is a necessity. There are a lot of plusses, RE: revit and scalability. There are some Negs too. Ill try to point them out as i go.

(I may break this up in to several posts over the week, as there is a lot i personally want to cover on the subject of Revit, large projects, and linking.)

Background: Revit, being a large database of objects, is capable of fantastic feats of documentation. In one model, of a 230,000 SF facility, we have 2 sets of full Construction Docs (with two demolition packages), about 60 sets of leasing package documents (6 sheets each), and as many working views and worksets as we felt was necessary to break it apart.

Problem being, a 280 MB file is still 280MB's, and its still slower than all hell on some of our lesser workstations. Even opening with specify worksets, and only turning on pertinent Bldg locations, its slooooooow. File linking presented an opportunity to skirt the issue.

On my current project, we were heading for links, regardless of the 2009 features. At roughly 540k Square Ft, with the amount of documentation we do, it just wasn't appropriate for one file and worksetting. Especially considering the campus style set up seen at left.

My original plan was to meticulously outline the project necessities, and have the pertinent documentation for each building in that buildings files, with the Generic Documentation in a "main" file. This was necessary, circa RAC08, as there was no clean way to document Wall Sections for a linked Building.

Reasons:

1. Edit Cut Profile doesn't work with linked elements.

2. Tags do not work with linked elements (Category or Material)

Regardless of the above two, even if they did, since we had to go in the links to edit the geometry, it only made sense to Document there. BUT, then i read the Press release, and discovered that LINKED VIEWS were now available for wall sections and elevations. (Positive Item 1) At right, a Plan with Linked View, which we've had in previous releases. Document your plan in the link, and in the VG dialogue of the "parent" file, set the "child" file to "By linked view" and select the view you annotated in the link.

Now that i heard i could do this with my sections and my elevations, i put on my Pinky and the Brain even sinister smile, and got in to it. So i hashed it out, and it DOES work every bit as great as it should, in my humble opinion. Now, there ARE some shortcomings, but they are completely subjective, as many people may not WANT revit to behave in the way I'm about to complain about.
So there it is, and it works great. The first shortcoming I've found is pretty obvious in a model centric environment: (Negative 1) You need to place a Live Section in BOTH projects. This doesn't seem like a huge deal, but consider: If you use intelligent Material/Category tags (hell, even if you use text notes), if a section shifts an inch or two, and a sloping roof or a pitched object is cut, now your live geometry is in the wrong place, and your tags turn to question

marks.

On the surface, not a huge issue. But it makes me wonder: Why cant we USE the view from the link, instead of using a linked view IN a view. I know the arguments: View annotations cant show through links, because the potential exists for view "2/a3.1" or sheet "a3.1" to exist in both projects. Herein lies my nuclear family theme: i want to be able to link files, but also get the option to call one a "Parent" of SEVERAL "children" files. Parents can include sheets of children, views of children, etc. ANNNND..... Children have to follow Parents rules.

What in hell do i mean by that? Well, I'm REALLY loving the file linking, but here was my second negatory in this ordeal, and it was one i expected, it just keeps tripping me up.

I'm sure we all have different strategies for modeling, and i wont presume mine is the best. Actually, i will. But it goes like this: I model with generic walls, and then as the project progresses, i create actual walls with the correct materials, thicknesses, coping, etc, as the project documents develop. We also use Model Groups extensively. With things like Wall Types, this gets cumbersome.

Both towers at right are identical Model Groups, but they've been placed in two links. The building on the right has been progressed farther, so the roof is now the actual materials, as are the walls in the model group. Both the roof and tower at left are still generic. So, whats a man to do? I can technically save the group out, and reload it in to the other link, but the roof and wall types too? perhaps, if i make a model group with my entire bunch of *typical parts*, but this doesn't hold very well. I had trouble with reloading a wall type with the same name (exactly) and different compositions. No lie, i could set the walls next to each other, but only one was in the drop down menu.

My point being, what if i want the PARENT file to have control over the CHILDREN files Groups, Wall Types, Elements, Families, etc? One of Revit's selling points over ArchiCAD (to me, when i started) was that once an object is LOADED, its IN the model. It doesn't HAVE to reference the library. This is great, as libraries move, and old models were getting KILLED back when i used archiCAD. But.... But what if i WANT it to reference a library, a la the parent file?

At the risk of being taboo, i always want to imagine my Wall Type Dialogue is an AutoCAD Layer Manager. My list of walls native to this project on top, then underneath it, the list of Wall Types from the PARENT project. So if i draw with a wall type from the parent project, and it gets edited in the parent project, it edits in the Child project. Now, obviously there are hardships there: Warnings generated sporadically when elements join/overlap/whatever, but cest la vie, yes? Organize the project team! And what happens if someone purges it from the Parent? Maybe it the Parent has Children, purge gets more complex, i don't know. But i can DEFINITELY see a desire for this in all things type cataloged. We already know such types can be read, as an element in a linked file can be selected and have its properties listed in a project.

Also, don't we already KIND OF get this with Shared Families? Nest a shared family in to a family, then load it in to a project; edit and repeat... And it WARNS you: The families are different. Which should i use? If it would do that with wall types, materials, and elements, Revit would be unstoppable, scale wise. I mention materials and elements, because the Material tags have been killing my inner child.

I respect their right to not be tied to one another, but they don't respect my right to WANT them to be, haha. Granted, I'll only have to type "STANDING SEAM MTL ROOF" once in every model... But then if i want to change that note, i need to change it SEVEN times. Hmm... Parent/Child would handle this.

And on that subject... I have to believe its getting close. Sheets and RVT link locations already show up in the drawing list... But view annotations and views themselves wont come across for reasons of possible mis-coordination. BUT, this gives me hope that one or two iterations away, its going to be there.

There are more improvements, and more things i want to see pushed further... Ala tagging, Rooms/Areas, and all that those things imply. This was the first layer of the cake though.

What are your thoughts? Currently, all 7 of these models are still flying, because they're much smaller than their predecessors, which ran all in one file, with a bunch of worksets. BUT, its got a price. Training for linking views, training for meticulousness in assuring that whatever you load in ONE model is loaded in SEVEN, etc... And.....

Then there is Model Sharing and coordinating with consultants. I'm touching that one tomorrow... :)

Share your thoughts on this, i'm curious what other end users and developers alike are seeing this as...