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!

Oh Where Art Thou Camera?

I wrote a post in March 2008 about this, still waiting. It would be excellent if in plan we could document where a camera is placed. Sure we can create a family to document where they are but that doesn't provide the automatic view reference that other view annotation enjoys. Seems kind of un-Revity to me, you?

If you decide to create a camera annotation how do you know exactly where it is after you place the camera? Good old "right click" will help, just select the view in the Project Browser, Right Click and choose Show Camera. Make a note of where it is and drop your annotation there.

Shared Parameter Article at AEC Bytes

Since I recently wrote a series of posts about them I thought I'd mention yet another source of information about them. Daniel Stine wrote an article recently for AECbytes. Check it out!

Nano Copters

I imagine this video is going viral to some degree by now. First thing I though of was how CGI and movies could harness these things to create even more realistic flight sequences like in Star Wars for example. I particularly like how the one copter can flip. I started imagining our own flying saucers one day. Or...one night, as a prank, these guys head for farm country, hook LED lights up and fly over Old MacDonald's farm and generate some UFO sightings? Cool and fun!

Scope Boxes

Dave Baldacchino wrote a post at his blog the other day focusing some attention on these so I dug this information up.

I wrote the following documents in 2004 while I worked for Wimberly Allison Tong & Goo (WATG). It's still relevant today though some improvements in visibility control (such as using filters for managing grids instead for example) have reduced the necessity for using them, somewhat. Their facility at managing consistent views of the model for multi/many story projects probably remains the most compelling reason to use them.

Ironically I didn't focus on that in this document, I guess I took that bit for granted. What I did do is focus on their role managing the visibility of datum in views. There is a sample project file on my site. Below this first embedded document is another that is a guide to experimenting with the file.

Basic Worksharing Guidelines

I wrote this document five years ago (I should revisit some of it). I posted it primarily because I wanted to play around with the Box feature to embed hosted documents after seeing it used on Jay's blog yesterday, he posted a 13 page document on organizing the project browser. I remember reading when Box added it a year or so ago and thought it was cool. I promptly forgot about it afterward. Naturally seeing it on his blog was a strong reminder!

Decided to add a few comments, until I get around to rewriting it:

The recommendation to add the word "central" to a central file name is outdated, it isn't really necessary anymore. The same thing is true for the recommendation to use Copy/Paste to create a local file. Revit has adjusted the process to make this fragile process a bit more obvious and easy. Recent releases have seen the addition of better alerts to each other regarding file status and borrowing elements, through Worksharing Monitor and new graphical workset display options. Last, for now, the language has changed from Saving to Central to the more obvious Synchronize with Central.

Autodesk's Thirtieth Birthday

Shaan Hurley posts about Autodesk's latest milestone...time flies. I stole this picture from his post...founders "floating" in air.

Happy Birthday Autodesker's, don't eat too much cake!