Modelling Serendipity - Revisiting an Old Post

In July 2009 I wrote about "Modelling Serendipity" when I encountered something that made me ponder my past work. Some recent conversations made me think of it again so I thought I'd put a link here to point at it again.

I recently told somebody, "I don't know what I don't know and I find that I bump into what I don't know in 3D faster than 2D"...that's modelling serendipity.

A RELATED POST (Sept. 2009), related to the notion of 3D shop drawings.

Suppress Spaces Revisited

In Revit 2012 (wrote about this earlier) we had the ability to shrink imperial dimension values a bit.

The upper dimension shows what 2012 did when Suppress Spaces was checked. The bottom shows unchecked. In 2013 we lose that. In my earlier post I missed/forgot that Ryan responded explaining what changed. Rats, I don't like the change, I want my old suppress spaces back by golly! This is what we get now (using my best Craig Ferguson accent, "It makes littul sense tah meee").

Access to Feature Redundancy

When we examine the Revit interface we find that we can change the scale of a view at the bottom of the view on what is called the View Control Shortcut Bar. If you happen to keep your Properties Palette open you've probably noticed you can just change the scale value there too? It's the same situation for Detail Level and Model Graphics Style. In the image below the items highlighted in yellow (even some running off the image) are all represented on the View Control Shortcut Bar too.

This can seem a bit odd or redundant to fresh eyes. If you've been staring at Revit for a number of years you probably remember when it was necessary to open a dialog to see those settings. The View Control Shortcut Bar let us change things without opening a bloody dialog box again. Today it seems a bit unnecessary to have some of the view control shortcuts, unless you close the properties palette.

As I've written before, in Revit there are numerous doors you can open to gain access to features, front, back and side doors...even some secret doors. Maybe they are bit redundant but if your cursor is closer to the bottom of the screen you can take the "side door" to scale or detail level instead of hopping on your scooter and driving up to the top of the Properties Palette. With the serious resolutions available on some monitors these days it could be a long ride.

A Case for User Keynotes

I wrote the following (April 2012) in a reply to a thread at RevitForum.org. It is one example of how a user keynote can be applied effectively to reuse instructions and avoid stating them differently in different places, as is easy to do with regular text elements.

Imagine a data receptacle plan. The data receptacles are essentially all the same (lets pretend they are all 2 drops) except for where they are installed. Some are mounted in a wall, some in a cabinet at a sales desk, some in a kiosk (free standing display), some are available for visitors to use and others are not. As far as a schedule to summarize them, then purchasing and installing them is concerned the faceplates and back boxes are potentially identical. To apply a keynote to define how they are different in use we'd have to consider separate families or separate types so we could get different keynote values.

If we create four or five unique keynote entries we can apply them to the data outlet according to their use as User Keynotes. The keynote legend would display the information for each condition on the sheet and/or in the master keynote legend. The same information could be displayed using a tag showing a custom instance parameter but not summarized in a list on the side of the sheet as easily. Nor could we avoid different values being entered by different people.

An example User Keynote might be:

"Kiosk mounted data receptacles are to be mounted at 12" above counter surface. Provide one extra run of CAT 6 cable without terminations, for future expansion."

The same device could also have a User Keynote that says:

"Data faceplate color selection must be coordinated with interior design final material and color selections with owner."

In the plan view we'd see one device and two keynote tags with different numbers adjacent to each other. If I needed to do the same thing for other receptacles I'd have to create new types every time I needed a keynote to say something even slightly different.

Keynotes as a practice is derived from the desire to reduce clutter on the sheet and reduce the chance of writing instructions differently on different sheets. Using types to control the information is still risky because we could type different information in different types and in different families. If we are going to supply instance parameter values routinely we run the risk of similar mistakes while trying to be consistent. Since User Keynotes are pulled from the same source, as long as we all click on the same keynote the information will be the same everywhere.

Room Separation Lines - Agida for MEP?

Via email the other night, he writes...(edited a little)

We use Revit MEP. I’m doing some research on Room separation lines, as to how and why architects use them, and when is appropriate. The problem I am consistently running into is that room separation lines divide spaces as well. These divisions, while relevant to the architectural model, are ruining the possibilities of creating gbXML files without extensive work on the part of the engineer to remove the room separation lines, and then repair the damage done to the room names and numbers.

For example, imagine open library stacks with dedicated study areas. In the architectural file, they used room separation lines as a rectangle to create rooms and tags for these study areas. They were also used to define a corridor along one side of the stacks (but still in the same open area). For MEP these are really all part of one big room. We won't need to add dedicated air terminals to these areas, nor special lighting just for these areas. So any of the analysis tools in Revit using spaces will be wrong, as most of them use an average over the entire area, (CFM/SF, Average illumination levels/SF etc..). Further, we are unable to accurately or efficiently create a gbXML file for use in Green Building Studio, HAP, Trace, etc. This complication is greatly hampering many of the benefits of using Revit for engineers.

I’m not saying that room separation lines should never be used, there are perfectly good places to use them. Rooms or spaces that are actually going to be treated as a separate room, not a room with in a room.

I initially thought that architects were using these (in addition to the obvious) to check for programming requirements, and code compliance for areas and such but it turns out a lot of architects are using the area tool for those purposes. They were however using them for the room finish schedules.

From a program standpoint, I was surprised to find out that while room separation lines can be assigned to a workset and that workset can be unloaded (through a linked file) from the MEP model. However the Room Separations still existed. We just couldn’t see them. And even if that did work, we engineers would still need to correct/edit the space names and numbers manually now since the spaces wouldn’t match the rooms (Space naming tool wouldn't work).

He closed wondering if I could offer any advice, ideas or a solution.

The essence of my response via email:

HVAC Zones are meant to combine spaces into larger more coherent collections for engineering purposes. The example given above for the library is pretty common place, need to know how much area is dedicated to carrels as well as a corridor within the open space of the library. From the HVAC engineer's perspective irrelevant but not from the client's or the architect trying to satisfy them.

If room separation lines are "off the table" then the architect would end up using something else like actual walls and hiding them. They might end up asking Autodesk to make more elements room defining? Area plans could help document such things but then floor plans would be "ignorant" of what these kinds of "areas" are, no tagging possible, just "dumb text". Not ideal either. My greatest concern about room separation lines is when they are used as "band-aids" to try to fix room area issues, where rooms aren't bounded properly and not generating area values.

Regarding the workset comments. Worksets unload information but that doesn't mean Revit isn't aware of the elements that are assigned to the unloaded workset. When we unload a workset the walls are still there and that means so are Room Separation lines.

Any comments from readers??

The Fat Pen - A Tale Two Lines

Every now and then I read or hear someone say that it is faster (in early design) to just sketch lines to create a quick floor plan for concept design (often as a justification for doing the work outside of Revit as well). I also hear that if we are going to do that (in Revit), we should just use Room Separation lines because we can put rooms in to identify them. I think both notions are "off", use walls.

"But Steve I don't want two lines, I just want a "fat pen" (think Sharpie)."

I say either sketch using really thin walls or use the Coarse Scale Fill Pattern as intended. That's my choice because they aren't any more work than sketching lines (ignoring their height), they provide boundaries for rooms and they can host doors and windows. It's also simple to change them to a better type later. If you use room separation lines first and then need walls you have to recreate stuff that's already there, they just aren't the right "stuff".

Years ago I worked with a guy that I found sketching lines in plan first. I asked why and he said he needed the lines to know where to put the walls. Somewhere deep inside we have this notion "we must draw lines". Everything he was doing was just as easy to do with walls instead...he "needed" lines first. Sometimes we must forget what we know. ~ Try walls, you'll like'em.

Still thinking that those "lines" are better than walls? Can those lines do this? (Please don't be distracted by my clever building design)

Okay, sure they can do that but what adding rooms and doors?

And then a few clicks more...this?

or easily changing to look like this instead (by changing wall types to use "Coarse Scale Fill Pattern")?

Can those lines generate cool shadows? (well, I think they are cool)

or switch to a more construction oriented appearance by changing "Detail Level" (okay, should have turned off the shadows)?

Do I really need to bring up schedules or 3D views or sections/elevations or enlarged views or ceiling plans and so on? I guess I just did. Walls set the stage for everything else downstream ~ I say use'em!

Revit and Drop Box

In the context of Revit and Worksharing (central and local files) and using Drop Box.

Suggestion #1 - Please don't
Suggestion #2 - If you ignore suggestion #1 please be careful and don't get mad when things go badly.

I wrote about an experiment using Drop Box with Revit back in June 2010. Though it technically worked, in my opinion it isn't suitable for a real project with people working concurrently. Why? Because Revit makes element borrowing so easy that someone will inevitably borrow something subtle like a tag or text or a view setting and then not be able to synchronize any of their work.

Companies like Riverbed exist, and it's taken a lot of effort at Autodesk to develop Revit Server, because data integrity (Bits and Bytes/data transfer/latency) between Central and Local files (element permissions) is not trivial. Drop Box (I really like it btw) is really just copying files from one place to many places. It does it quickly but not quick enough for concurrent activity...not all the time, every time, never fail. It does nothing to manage Revit permissions and that's what will burn you, borrowing something at the same time as another person. It comes down to what sort of gambler you are. Comfortable with losing 10,20...30 minutes works?

There is hope...IF you are extremely competent with Revit...AND...the kind of person whose pen and pencils are arranged in a very specific order on your desk and can tell if someone touched your work area in some barely perceptible way...AND...the other person(s) you are going to try this with is your twin in this way...you might be able to pull it off. Might help if you are going about it as if you are playing Halo (WoW or COD) online and communicating (via a headset) with the other person continuously as you work.

It works great to share a project file if you and your teammate are "following the sun", you start working on it when they've finished for the day. The real danger is concurrency, doing stuff at the same time and the very real risk of borrowing the same thing at the same time.

I know there are people that have done this and have had success. There are exceptions to every "rule". There is a thread at RevitForum.org and post this morning at The Revit Kid advocating it works. What I'm most concerned about is people diving into a real project and having a go, then dealing with hours of work that can't be reconciled because they weren't prepared enough for the worst.

As I wrote at the beginning, if you ignore #1, don't be upset with #2. You've been warned. Be careful out there!

Press and Drag

The Autodesk blog "Inside the Factory" is asking about the Press and Drag option. Using this software for as long as I have I'm quite unhappy when the option is off. Maybe it's minor or strange, and to some irksome or even dangerous, but I'm very used to and happy to use it. So far the comments on their post seem to be running in favor of removing or "blunting" it somehow. According to one comment, I'm nuts for using or liking it.

The only time I get frustrated with it is with linked files. Revit's odd preference for "seeing" and therefore selecting linked elements over the native elements is something that ought to be fixed instead. Removing the Press and Drag feature should not come as a result of other issues.

I find it interesting that people who normally count clicks are "happy" to add more clicks for this item. I use press and drag for so many things, dimensions, text, tags, equipment, duct/pipe runs, walls, doors/windows, viewports on sheets, practically everything at some point. When things need to be precise it isn't the correct approach but so much of what we do during design and documentation can be adjusted more readily with it on.

My vote is leave "my" Press and Drag alone.

If people don't want to use it, that's what the check box is for and it can be preset to "off" via the Revit.ini file already. Don't like it, don't use it, please don't make my choice for me.

Revit has a Wblock Feature Too?

Read a post a couple days ago that AutoCAD has WBLOCK to write information out to a new file. It went on to say that Revit does not. Technically true, no Wblock command. It got me thinking that the "Save as Group" feature however does much the same thing, select elements, create group, Application Menu > Save As > Group. This takes your selected items (the group) and writes them to a new .rvt (project) file. In essence the "same" thing as Wblock.

The subject of the post I read was about splitting a project up. The method advocated is to use Save As to create a separate project and then clean out everything you don't want to keep. The Save as Group approach could/would/should work too. Regardless the hard part isn't Save as...it's carefully filtering/selecting everything.

As you were...

To Host or Not Host

This isn't asking about a Xmas party or dinner party. This is a frequent topic with anyone digging into making content seriously.

Usually the bias is toward defining the answers according to architectural needs. No offense intended, whoever is asking the question is going to have some bias. I spend as much or more time these days dealing with the "other" disciplines and this question.

If dealing with the other disciplines, the typical quick answer is usually face-based as well. True if we assume a Revit to Revit consulting relationship. If an engineer wants to use their cool new software (Revit of course) and their architect isn't using it then a face based family will need a face that isn't there. With a solid library RME can be quite effective even without an RAC model (though a bit harder without something to create spaces in). In this situation we can't just put those families on the level's work plane because they won't be oriented correctly. A reasonable argument (I think) can be made for families that are not hosted at all, even if assuming an engineer is dealing with "your" architectural model linked into their project.

To be most flexible, as "crazy" as it might seem, the answer may be starting with non-hosted content. Yes, it is nice to have a family follow "your" walls when they move (face-based will). Yes, with non-hosted content you may have to move (more) things when designs change. Change quite often isn't just a wall sliding left or right, it can also mean a completely new wall or walls or a different layout entirely. When the original host gets deleted the orphaned face-based family ends up "wanting" a new host and resolving that is usually an onerous (not difficult) task too. A family that isn't looking for a host won't move automatically but fixing that situation isn't really any harder, all that different a task or substantially more work when you compare the "doing" of the tasks.

Then there is the notion of "close enough", which freaks people out too. Consider a electrical disconnect (device) can be six inches, eight or twelve inches from the equipment it supplies power to and it is still close enough. If the equipment moves a "little", no harm done...the disconnect is still fine where it was when you put it in originally because the "whip" the electrician installs between them will deal with the difference. Most engineering solutions have room for "slop" at the end of (at least somewhere along) the system. They have to design in something to deal with the construction reality on site. It seems reasonable to me to mimic that where appropriate/possible in our modeling effort.

The perfect answer, the one solution that fits all situations doesn't really exist at least not one that fits every firm or project. We might get close for one firm or discipline but each project brings new conditions to consider. It's more work but it may come down to having complete content libraries for each condition rather than only having one solution focused on one approach.

Family Naming - Don't Worry

Jose Fandos of Andekan posted again in his continuing theme of content related posts. He suggests that worrying about a family naming standard, an all-encompassing one at least, isn't our biggest priority. I agree, I've always preached consistency instead of specifics. Every firm I've met over the years has their own position about file and folder naming for every kind of software they use.

He (Jose) predicts that how we find content in and out of Revit will only get better as we move forward so the actual name of a Revit family may become less important as a means to find one. For example, the add-in Family Browser allows us to organize content logically and the name isn't really the focus (while it, a standard, does help organize the folder the content is in perhaps).

If by some chance everybody could agree on a standard strategy it wouldn't hurt us. I don't think it is a fundamental or major priority over actually having content created. If it gets made with a "bad" name, I can always rename it when it hits "my" library anyway. ;)

Feature Request for the Next Version of Revit

I suggest that Revit be able to respond to yelling, hitting or otherwise becoming angry with the computer. Ideally being able to respond to an epithet like, "stupid software!!" or "darn Rivit!" When a user becomes physical and hits their computer Revit should warn them that this might make things worse and to return to verbally harassing Revit instead.

In the interest of safety if Revit detects the use of a weapon against the computer it should initiate an immediate shut down with the usual messages about syncing with central of course, if possible. If there doesn't appear to be enough time then when Revit is opened the next time it should say, "Sorry about shutting down on you but that [insert weapon observed here] looked ominous and we wanted to protect your data. There wasn't enough time to SwC, so sorry about anything you lost between your last save and the "recent unpleasantness".

Family Types or Type Catalogs

Jose Fandos wrote a post in August titled, The Death of the Family Types. He thinks that the role and or usefulness of built-in family types is over or "dead" as he puts it.

I don't agree entirely. I do agree that for someone who makes content regularly that adding types to the family directly is a task best left for last. Making sure every type is properly defined can be quite tedious inside the family. It isn't a lot of fun making sure every value is correct in the rows of a type catalog either though. At least it IS easier to copy/paste and then adjust values than within the family itself.

While making "my" life easier when making content, Type Catalogs can be perceived as a hassle by the end user because they need to load the family each time they find they don't have the type/size they need. The recommendation of no more than 5 types in a family found within the Autodesk Seek recommendations is one less than the earlier family editor guidelines that suggest no more than six. The text of the Revit Content Standards document that the team used internally said: (David Conant shared it with me in 2005 while preparing a session for AU)

Predefined Types:
• All families should have at least one pre-defined type unless a type catalog is used.
• Where real world examples come in typical sizes, pre-defined types should be generated.
• Where there are to be more than 6 predefined types in a family, use a type catalog to organize the types.

Keep in mind that these rules or standards were coming from the viewpoint that they are generic families meant to be pretty broadly applicable. Obviously the document David shared with me came after the introduction of type catalogs since it makes reference to them. Jose's post shares that Wesley Benn provided him with the text from What's New in Release 4.0 that show when type catalogs were introduced. Regardless, the point at which we choose one over the other family types or a type catalog boils down to preference.

As a daily user I don't enjoy interacting with Type Catalogs as much as I prefer them as a person who also makes content. If there are only five types in the family I'd probably be inclined to load them all to avoid doing it again to get the one I left behind. I also find that once users realize how easy it is to create a new type in their project, they are just as likely or inclined to do that instead of editing the family externally and reloading. If users start doing that the type catalog starts getting out of sync with the library. Keeping track of the flock can be hard on the Family Shepherd at that point, with strange sheep showing up in the fields.

I think that family types have a place and the rumors of their demise are greatly exaggerated.

In Search of a Side Door Managing Links

I wrote about the Manage Links dialog yesterday. Something else has been bugging me about it so here's another post. I'd love a side door to Import a file from the Manage Links dialog!!! It would be nice to be able to click Import File when I've realized that I need to do that instead of closing the dialog and then clicking the front door buttons for the task. Each tab could have its own side door for the appropriate file type. Crazy?

There are other precedents like the Materials browse button in the Edit Assembly dialog for walls, floors, roofs, ceilings. Another precedent, the browse button for accessing Assembly Code data?

See, not so crazy me thinks!!