My Kingdom for a Dimension...or Two...Three

A Friday thought...

I've spent the last couple years doing a lot more modelling work than I expected to do. If you asked me in years before I'd have told you 80-90% percent of my time was dedicated to training and implementation activities.

Much of the modelling I do these days is from the contractor's point of view, for them. I quite enjoy it. I learn a lot and it keeps me on my toes.

This work is requested often because the documents they are using are not created from models to begin with. Sometimes they are but they (the contractor) have to build based on drawings so they find it informative to attempt to build things in the computer before doing it in the field. Where have I heard that notion before?

Chief among the things that trouble me doing so is the lack of dimensions. If there are lots of dimensions then the issue is their message or rather the lack of clear intent.

All too often I find a slab edge plan is lacking that one dimension, between adjacent slabs for example, that I could really use. In other instances the decision to start plotting the dimensions is based on a datum that involves a fussy site related angle (like based on a property line); when other orthogonal options are available.

I've also seen far more effort and devotion applied to dimensions for parking stripes in a parking garage than for the structural elements that make it possible to paint those stripes eventually. Then you have the dimension value bust. Such as, setting out the building grids reveals a subtle mathematical inconsistency or outright typographical error or override.

Then there are the dimensions that describe how to place something relative to other elements that get installed later during construction. How do we place a concrete column by referencing interior partitions...when those dimensions don't relate back to grids or structural elements? That issue is both missing dimensions and logical progression.

Often I have to endure the game of look over there, as if a hockey puck is getting smacked back and forth, when one says look at those guy's drawing for more information and then the other says the reverse. Slab edges that are required to overlap (per nearly matching details) are a real chore to sort out when you have to flip back and forth constantly and double check against the reflected ceiling plans...oops they're inconsistent with the plans...note to generate an email...

Then there are arcs. Thanks for all the radius and diameter information. Could I get dimensions for their endpoint locations and chord height/width? Better still, could I get something that tells me where their origins are supposed to be? Yes I do realize that one or two might be located somewhere on the outskirts of town. Then again if doing so exposes that issue up front when they are sketched, maybe we could get some other localized notion of how to place them on site too?

Though I've rarely encountered it in real life, I've really learned to appreciate the my documents stand on their own philosophy. In other words, a structural set of documents could be used in isolation to build all the the structural elements required, correctly, even if the rest of the work never got funded. It IS harder to do because it requires concerted effort to coordinate the disciplines well.

Yes I know, it's complicated, building stuff is messy. Now that I mention it, have you noticed, like me, that those ugly fractions people don't like seeing on drawings still crop up everywhere in real life.

Ah well, enough complaining. I've got some slab edges to reconcile. Back to grumbling to myself again. May we all enjoy a dimensionally accurate weekend!

Clipped or Un-clipped - That is the Question

The question asked: "Steve, should we leave our coordinate system icons clipped or un-clipped?"

My Answer: As we know, the Project Base Point (PBP) and Survey Point (SP) can be un-clipped. If they are untouched we'll find them clipped.

When these are clipped the symbols for each of these are attached to the coordinate systems they belong to. That means moving either while clipped will alter the coordinate system. If this is done unintentionally, or by someone who does not realize they have been adjusted intentionally already, the coordinate system(s) will be changed.

Therefore I'd say it is not unreasonable to leave these in their NOT clipped or un-clipped state at all times, especially after they have been adjusted intentionally to align models or survey data. If they are not clipped then accidental movement of these icons do not alter their related coordinate systems. It merely changes the symbol's position relative to their coordinate systems.

I regard these symbols as markers or annotation when they are not clipped. In this state they are harmless to our coordinate machinations. Clipped they pose a danger to our careful adjustments to align models and site information.

My opinion: Keep them Not clipped, un-clipped.

View Reference User Experience Inequality

The View Reference feature reveals information differently according to how you access the feature. A post at RFO yesterday, and subsequent reply by pivoarch, made me see this subtlety finally.

When you create a new view and choose the Reference Other View option you get the sheet and detail number value (when the view is on a sheet) in the description in addition to the view name, like this.

When you want to fix or change a View Reference the sheet and detail number values are not presented to us, like this.

It would be very helpful to include the sheet and detail number values in every instance that it is displayed to us.

Add a Comment using Synchronize and Modify Settings

Whenever we need to use Synchronize with Central (SwC) I advocate for using the button for Synchronize and Modify Settings every time.

Doing so allows Revit to present us with the Synchronize with Central dialog.

I encourage everyone to take a moment and type a brief description in the Comment field provided. What motivated you to use SwC just now? That's the gist of what should be recorded there. I find that people are more receptive to making a habit of it once they see it can prove to be very useful to just about everyone working on the project.

We can review the comments anytime we choose to, even if we don't have a project open yet. That means that anyone who can at least fire up Revit can review project comments even if they don't really need to do any work in Revit.

Yes, the Show History button on Collaborate ribbon is awake even if no project is open. Click Show History, browse to the location of the relevant Central File and click Open. The comments are presented to us like this.

I doubt it is hard to imagine how having everyone on the project team recording comments (time stamp and username are stored automatically too) can be helpful for diagnosing issues, checking the status of tasks, and even a quick review of user activity on a given project file. It will also become obvious who isn't playing along pretty quickly.

I also recommend that we never use the other button for Synchronize Now (that's why I put the red X on it in the image above). It doesn't present the dialog so there is no opportunity to store a comment and equally important is that is does not relinquish User Created worksets automatically.

If you pay close attention you'll notice that all of the other kinds of worksets are automatically checked when the Synchronize and Modify Settings dialog is open. Those other worksets are relinquished with Synchronize Now, not User Created worksets though. If you use Synchronize Now and you've ever been accused of retaining ownership of these worksets...that's likely why.

If it helps:

Green Arrows in Circle SwC = Good!!
Lighting Bolt SwC = Not Good!!

If you're interested in taking a peek at Kinship's features you'll find that these comments can be reviewed at will with just a browser.

Autodesk Desktop Application - Again

Boy this app doesn't get much love. I've read a couple of posts elsewhere that are far less charitable than I've been. As I mentioned in the podcast I did with Bill (Grumpy Steve) I think it had a better name before when it was called Autodesk Application Manager. At least then the name suggested what it was meant to accomplish. Now its name is ambiguous at best and meaningless at worst.

A couple comments in response to my last whiny post pointed out that if I'd read the readme file for each update I would have realized that it would be necessary to uninstall the existing versions first.

My reaction? Okay my bad ... but then I thought that's not much of a application manager is it? Tell me there is an update but you need me to go elsewhere to read a document and uninstall the software so I can come back and run the update. I'm imagining that the user experience of applying an update to an app ought to be just a little bit like doing that for an app from the iTunes store?

Then again with its new name...it's not a manager anymore.

This morning a little progress though because I see AdA has started up AND there is another update indicated by the icon in my system tray.

I've already been told this application has an Update quite a few times now. Each time I've attempted to apply it, no success. It just shows up as available again the next time around.

This time I thought I'd listen to the advice offered in the comments I mentioned earlier. I clicked on the Readme link (blue text in the update listing). Instead of taking me to the readme document or the page that has it I find myself looking at the primary BIM 360 product page.

That's not what I expected (implied by the term Readme), nor is it helpful. Okay, I can deal with this. I'm reasonably resourceful (I think). I'll just go chasing after the update via the Knowlege Base. I run a search against each of the four BIM 360 applications listed ... nothing found. Okay?! Since it is for Revit 2015 maybe it's an update that is hiding under Revit 2015? Run a new search against that criteria instead ... yeah, you guessed it ... nothing found.

Yes, I submitted feedback through the built-in comment dialog that AdA has. That it has one built-in should be a clue I suppose.

I think, if AdA is going to tell me there is an update and make it worthwhile, it should do everything necessary to help me actually apply the update. For example, I was told (via comments) that it was necessary to un-install the existing versions of the other apps I was trying to apply an update for. I've since done that and applied the updates, great! The update item in AdA should have been formatted like this for example.

Better still the update should be smart enough to un-install the precedent software first, if it is required. It's not like there isn't a precedent of software updates doing that.

Since my most recent attempt to use the readme link ended with no joy, most likely just the victim of being assigned the wrong URL, it seems reasonable to provide the most important warning related to succeeding with an update, that it will be necessary to take separate action to remove the existing version first. Seems easy enough?

For now I'll just ignore the update since I won't be needing Revit 2015 this week. I'll see if it factors into my situation later, if it ever does.

Create a Local File - How Often

Every time...

I no longer reuse Local Files. My attitude and habits have changed a little over the years. I wrote this POST in 2008 and then THIS on in 2011. I've touched on the subject many times within the context of other workset related posts.

I treat my Local File as ephemeral...temporary... I make use of the Open File option Create New Local each and every time I start working on a project again; yes even if I just stopped working earlier to have lunch or join a conference call.

Pre-Selection and Selection Color

I always change the default color that Revit uses for selected elements. I use Red.

The default setting is the same blue that is assigned to Pre-selection. I don't recall when that changed but somewhere in the fog of time it used to be assigned to red. I happen to like the visual confirmation, the difference between what is highlighted and what is selected. To each their own.

If you want to change it too: Application menu (Big R) > Options > Graphics page

Stretching Schedule Properties Dialog

When we stretch the schedule properties dialog only the Available Fields list gets wider. The side dedicated to the parameters assigned to the schedule gets no love.

It's been this way for quite awhile but it still seems strange to me...

Saving Backward

It is a common question and the answer is no, Revit does not save backward, to an older version. 

People often regard saving a file from one format to another as a trivial matter. As software evolves and new features are introduced these new things have no equivalent representation in the older format. Even Microsoft Word or Excel warns us when we save a file to an older version and those are much simpler elements.

For example, when Revit Parts were introduced. If we could save to an older version that did not know what Parts are how should that transition be handled? What should the developers decide to do with them? What can they become and retain some usefulness?

With AutoCAD there are new features that can survive a trip backward, like Tables can be reduced to text and lines so it still looks like a table but is really less elegant than the Tables they came from. If the file is then saved in the most current version there is no "make me back into a table assumption" so fidelity is lost.

It is difficult to allow for forward saving (upgrading) too. Nobody is very pleased if they upgrade a file and something breaks. Saving backward is most assuredly going to break elements the more object oriented our design tools become and evolve.

Revit's founders chose to eliminate the complexity and development distraction of saving backward at the outset. Most software like Revit does too even if they don't acknowledge it outright. They may allow saving backward in concept but there is always some loss of fidelity or utility in the process.

Revit does permit exporting data to other formats to permit it being referenced in some way by other tools but it remains impractical to expect casual backward and forward file translation.

When Revit was introduced in 2000 it was a rental, we paid monthly and internet access was required. Using the latest version was expected, required. That's never changed even when Autodesk purchased Revit Technology Corporation in 2002. They just made it possible to buy a perpetual license like their other software. Conceptually though nothing has changed.

Autodesk has a legacy of customers who transition from AutoCAD where it is normal to ignore a new release for several years before upgrading. That is possible because the rate of change for AutoCAD has generally been much less aggressive than with Revit which is much younger and has different objectives. 

It is easy to have access to the latest version at all times, via subscription. Fwiw Autodesk recently announced that new licenses will soon be all subscription based (rental) going forward so the concept that Revit embraced in 2000 has come full circle.

I'm not always pleased with Autodesk's choices and how they affect me as a customer but no company is perfect. For example, I'm writing this post on an iPad that can't just give me bloody arrow keys (without an external keyboard). Instead I have to use a goofy fussy magnifying glass to reposition the cursor.

Importing CAD Files and Invert Colors

Autodesk help documentation offers this explanation for what happens when we use the Invert option for interpreting the colors in a CAD file when we import/link them (my emphasis added).

Inverts the colors of all line and text objects from the imported file to Revit-specific colors. Dark colors become lighter, and light colors become darker. This can improve readability when the file is in Revit. This option is set by default.

The following image is a small sample of what occurs. The top row of lines, imported using Preserve, have been assigned to the basic color palette and a couple extended colors, such as Red, Yellow, Blue and #10 (red) and #30 (amber). The bottom row of lines, imported using Invert, are how they are changed from the colors assigned in the CAD file once they are represented in Revit.

Looking closely, red becomes cyan. If you examine #10, a red also, you'll see that the Inverted color is also cyan or at least cyanish. Shades of red will be converted to shades of cyan. Compare the others and you'll see similar logic.

I don't use Invert, or recommend doing so, because the results are rarely meaningful or useful. You don't know why something is assigned to a given color. The simplistic goal is to just reverse (invert) the intensity of the color once it is imported, to make it easier to see on a white background or balance their appearance in this way.

If we really want to retain or use the color in some way then I believe it is better to keep (preserve) the colors we may already be familiar with, at least if we are responsible for creating that data too. That's my two pence worth.

Using Shared Coordinates - Do Not Remove the Link

I hear and read quite often these days that people will use Acquire Coordinates on an imported file and then remove the link. They import the source file again but use Positioning: Auto by Shared Coordinates. The reason offered is usually that they are doing it because they want to prove to themselves that the file IS sharing coordinates.

It is NOT a necessary step. Don't bother to do it. It won't harm your project if you do, it's just pointless.

Guide Grid and Pin

We can assign a Guide Grid to sheets which provides a way to make sure selected views are lined up from one sheet to another. If you aren't familiar with this tool then have a look at this older post for an overview.

If we're concerned about someone moving the guide grid we can use the Pin tool to make it a little harder to move it accidentally. Then we can make it even harder if we un-check the Selection tool Select pinned elements.

Just keep in mind the Pin tool does not prevent the Guide Grid spacing from being changed. Methinks it should.

Including a Sheet File Name and Path

Ever since we started using computers to generate architectural and engineering drawings we've been inclined to provide a place on a title block to help people find the file. Sometimes it is just the file name and other times it is necessary to have both the file name and path to the folder it is in.

The path is useful to the team working on the files but if those files are passed along to someone else it may be meaningless to them, or confusing at the very least. The file name is useful to anyone who happens to be looking at the drawings as long as they are in a position to access the digital version of the file too.

In a Revit model, which usually contains all the sheets for a project, the file name doesn't have the same usefulness when compared to a file based system like AutoCAD. That's true unless you are printing multiple layouts from a single DWG file, then it's not all that different than Revit. When someone is looking at a printed sheet and sees the file name and path it doesn't help them find the digital version, like a PDF file for Sheet A100 for example, because the file name is the Revit model, not the resulting PDF export.

As such Revit misses the mark in helping us carrying on that tradition. Since there are a number of ways our sheets can end up as individual files it is hard for Revit to anticipate or provide a suitable way to plug in a unique value until the data is exported outside of Revit. I'm sure there are some things that they could do to help us with this but it hasn't happened yet.

Revit's API could be used to capture the sheet information and store a contrived file name in a parameter for each sheet. When we print or export we might end up with the correct file names matching the resulting files or bearing a slight difference. I don't recall an existing application that deals with this specifically but one might exist, like Xrev Tools for example.

If we forget limitations within Revit for the moment, since the output format of a set of documents is where the appropriate file data is really needed it might make sense to consider focusing on how we handle the output files instead, at least for now. For example, the company Bluebeam offers software to process, review, and markup PDF documents. It includes the ability to add custom headers and footers, which can be the file name (among other things). It can also Batch Process files to include the file name. The file path is another available choice to put in a header or footer so we can combine them if we want to include both.

If it is necessary to provide the specific file name (and path) for exports to DWG it is probably best to add it those files after exporting, this way they'll point to an actual file instead of the Revit project file. Again some customization could add the necessary fields pretty effectively.

It seems like post processing this information is probably as effective as trying to come up with a way to deal with it internally in Revit.

Workset Names

Via email I was asked,

"We are probably all familiar with names like Core, Shell; or Core-Wing1, Shell-Wing1 for example. We have been discussing using the Omni-class table 21 with 7 categories and 3 levels. For example a workset name would look like this: 01 10 00 Foundations. Would you agree with taking this approach?"

My fear, whenever we start talking about using coded naming, is that we are going to have too many worksets and create additional bureaucracy. I wrote a post called How Many Worksets do I Need. I described one warning sign as having to scroll the list of worksets.

I don't have any objection to being organized. I do caution against creating extra work for each of us by getting too granular with worksets. Using OmniClass numbering might work well if the highest levels are sufficiently distinct to be useful.

My measure is, "Are we are better off for taking the trouble to do it?" That's a vague answer I suppose. I know enough to know I don't know everything. That means there probably are projects that would benefit from using that approach.

I'd know it is the right choice if we are going to be better off afterward.

Tagging Elements and their Area

Revit allows us to tag rooms and spaces to display their area. If I'm tempted to do the same for Walls, Floors, Ceilings or Roofs the list of available system parameters (built into Revit) does not offer Area. Revit MEP users can tag a Duct's area.

It seems to me a bit arbitrary to disallow the tagging of data that is part of the element. We can see it in the element properties and include it in schedules. While a schedule is an ideal way to summarize data a floor plan is useful to provide context AND display a variety of information, like area.

It would be excellent to see more parameters unshackled.

Soffit Conditions

I received an email the other day asking for my opinion about modelling soffit conditions. In this particular case they used a thick wall to wrap a steel beam but then worried about the results when using clash detection later between the wall and beam. Since they overlap one another it would be a clash. Determining what constitutes a valid clash when modelling and who is modelling and then doing the clash detection is a deserving topic on its own.

My response is that I prefer to "model it like we build it" as much as is reasonable or possible. In this case I'd take this approach. I'd model the ceilings, one type on either side of the beam and another for under the beam (assuming "hat" channels for structure). I'd use a separate wall type (also assuming "hat" channels for structure) for the soffit "wall" so I could adjust where the gypsum wall board started and stopped.

Here's a section view.

And a 3D view.

In early design I could probably just get away with creating the ceilings and add the walls later when sections were needed.

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.