Cannot Create a Local File

I read about a couple items in a thread at RFO that could affect creating a Local File in addition to to what I've mentioned in the past.

Revit appends our username to the local file it creates for us. That addition could cause a local file's name to exceed the maximum number of characters, which is 260 (file name and path). That's 256 plus the four characters associated with the drive letter, for example C:\ (space/null after the back slash).

The other possibility mentioned is having Auto Off-line Access enabled.

Gosh computers and software are fussy buggers!

Shared Parameters are Shared Definitions

We tend to think of Shared Parameters as a thing, equal to Family and Project parameters. I've even described them as such in past posts on the subject. If I'm very picky and technical they are not a thing, they are a device, a parameter definition, shared to either create a family parameter or project parameter or both.

Yes, they help us create a Family or Project parameter, but on their own they are nothing, they only exist in a text file. That text file only defines their name and data type, nothing else. Okay technically the file has a little more data in it than that but it's only used internally by Revit. It doesn't mean they have standing or truly exist on their own. We have to apply them to Family/Project parameters for them to mean something, be something, be useful.

Written another way, a family parameter (either component or system) can be created from a shared parameter and a project parameter likewise but there are no shared parameters that aren't one or the other.

This is why I regard them as a definition stored in a dictionary, the Shared Parameter file.

Toposurface from a Text File

I responded to a thread at the Autodesk Community Revit Forums back in May. They described having a survey file and a points file that could be used to create a toposurface. My initial reply focused on resolving this warning, "Imported Toposurface Points are located a large distance from the model and might not display properly. Points will be centered on the model instead".

I offered this advice.

• Import the survey (a DWG file) first using Auto - Center to Center
• Move it so the relevant portion of the site is roughly centered on the Project Base Point/Survey Point
• Select the Survey Point and Unclip it (this prevents it from moving to the 0,0,0 location of the DWG file in the next step, which is far away)
• Acquire Coordinates from the DWG survey file

This resolves the real world coordinates based on the survey data. I felt they'd be able to create the toposurface successfully. Instead, they responded that the toposurface was not created in the correct location. I took another look and experimented with the points file they posted (in the thread) and offered these steps.

• Add a new set of point coordinates to your text file at 0,0,0, on the first line.
• Use this version of the points file to create the surface.

I then commented, "If you followed my directions earlier about acquiring coordinates you should see the coordinate values of the survey file when you select the Survey Point.". Then I recommended the following steps.

• Unclip the Survey Point > Enter E/W: 0' and N/S: 0'
• The Survey Point should jump to the 0,0,0 location of the survey file, far from the project origin.
• Make sure your View Range is set high enough to see all the points of the surface
• Now create your toposurface
• When the points are visible you'll see one point at 0,0,0 but it will be at the Internal Origin (>R2020, Project Base Point in older versions)
• Select all the (toposurface) points > move using the Internal Origin/Project Base Point location as your first pick and the Survey Point as your second pick (see image below).
• This will move all the points down so the toposurface is located properly relative to the survey
• Before finishing the surface > Delete the one toposurface point at 0,0,0
• Finish Surface

I found that adding the extra point at 0,0,0 silences the warning about the distance from origin and it gives us a known location within the point data to select and move the entire surface accurately.

Then another member asked about doing something similar but wanted to report a project elevation of 100'-0" instead of 0'-0". I replied with the following.

In order to show the Project Elevation as 100'-0" you'll need to model your building at that project elevation instead of 0'-0". Then when you establish shared coordinates you can show the true elevation. If I was tackling this I'd create a building model at 100' and a separate "site" model.

I'd import the site data in the site model and create a toposurface. It should be at the real elevation and report the relevant coordinates you expect. Then I'd import the building into the site model, move it into position X/Y, rotate it if necessary into alignment with the site conditions and finally move it up to the intended ground floor elevation. Then I'd use Publish Coordinates to pass the building position information out to the building file.

When you open the building model you can edit the Level parameter Elevation Base to use Survey Point (versus Project Base Point) and it will show the True site elevation values instead.

Just a couple days in the life of a thread at an online user forum (spanning nine months).

Need a Ceiling Tool

Revit Workflows and Auto Floors Builder are two 3rd party applications that tackle the task of creating floors more efficiently. Revit Workflows is focused on finish floors and Auto Floors Builder has a more structural focus. While I think Autodesk ought to tackle this sort of refinement directly it is great that there are some options.

Where are equivalent tools for creating ceilings? Is the API holding development back or are they just still on the drawing board? My inquiring mind is curious...

View Range Help Doc Image

I was pointing out the View Range help documentation earlier and noticed that the plan view seems to have Thin Lines on, no particular difference in the lineweights depicted. At the very least it is a bit anemic looking. I think it would be a little more helpful to be more obvious which lines are affected by the Cut Plane by showing the Cut lineweight, like for the walls.

Fwiw, I think View Depth should be moved above the Primary Range when the View Range dialog is opened for Ceiling Plan Views...and maybe called View Upth? :)

Revit MEP - Electrical Wire Size

Revit mEp is very American because it is hard-wired to do its calculations based on the AWG based wire sizes that are defined in the templates Autodesk provides to us. When you need to reference metric sizes/standards instead there is no place to change this bias and if you attempt to change wire sizes to metric equivalent (CSA or Sq. mm) values you'll find calculations, like Voltage Drop, either cease to work or you get strange results.

Working through this issue with a client recently they decided (or at least hoped) it would be acceptable to provide a chart that allowed the reader to cross reference the AWG size against the locally relevant size. This firm is based here in the USA but working on a project outside the USA. Perhaps in that context this could be forgiven by the client. I don't know how well that approach will work for firms that are working at home, outside the USA.

Fwiw, Autodesk IS aware of this bias. Providing more flexibility is among the many things they have to find time to include in future releases.

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.

Comments Deleted - Oops

Tonight I deleted three comments by mistake. I selected them to publish but when I moved my cursor to do so my sleeve caught and I clicked over the Delete button instead. Moving too clickly... very sorry. If you don't see your comment please feel free to do so again, if you feel motivated to do it, sorry.

Import CAD - Orient to View

This is what the Autodesk Help documentation says about this feature at the moment.

Orient to View - This option is useful if True North and Project North are not aligned in your Revit project. If True North and Project North are defined identically in the project, then this option will not affect the way the import/link is oriented. The World Coordinate System (WCS) is used to orient the CAD file in the view.

If the current view is set to True North and True North is rotated away from Project North, then clear this option to align the CAD file with True North. If you select this option, the CAD file will align with Project North regardless of the view orientation. Note: CAD files are always imported into the current view from the top view direction. The CAD file is brought into the view assuming that the current view is a top view.

It also does something important or relevant when importing into elevation or section views. When people draw sections and elevations in CAD they are often doing so in the plan orientation of the file. It isn't all that common to see people reorienting their view in AutoCAD and then drawing those views oriented to Front or Back etc.

When we select this option and import such a file into a Revit elevation or section view it will rotate the plan of the CAD file into alignment with the section or elevation view. If not then the imported CAD file is aligned with the plan orientation of plan views and we only see the edge of the files lines in the elevation or section view.

If the option Current View Only is chosen then this On by default

Video Settings and DPI

Be aware that Revit does not support increasing a computer's DPI (dot per square inch) video/graphics settings beyond 150%, assuming your computer permits it all. There are numerous cases where doing so causes either instability (crashing) or just poor graphic display quality.

Copy Monitor - What Elements are in a Relationship?

A friend recently asked if there is an easy way to find out what elements are currently involved in a Copy/Monitor relationship. Good question! No easy button exists for this that I'm aware of. Sure we can select all grids and looks for C/M monitoring icons. That's not too hard for levels and grids. It's much less fun for walls, columns, floors or any of the MEP related categories that can be involved.

It might be an interesting question/problem for enterprising Dynamo aficionados or API programmers?

It would be nice to generate a report of the elements in a relationship and with which model and elements their relationship is based upon. I think it is just another example of the kind of refinement that Revit's collaboration tools ought to have.

Starting View

I was reviewing old posts for something I thought I wrote about Starting Views. I was befuddled when I didn't find anything. I guess that's to be expected when I write things here and on several other webs sites like AUGI, RevitForum, and Autodesk Newsgroups. Enough about my confusion. Since I don't seem to have one already, here's one now.

Revit developers observed that users were creating simple drafting views that contained some project information and then encouraging or insisting users remember to open this particular view when they saved and closed their projects. This way when someone opened a project for the first time they'd always be greeted by this special view. It also takes Revit less time to open a simple view with no model representation involved. In response they introduced the Starting View as a feature. This special view can be assigned to any view including a sheet view.

Initially people were pleased and just referenced the view they were already using. Then some began experimenting with other view types. The Sheet View is particularly useful because it can use a custom title block family to provide the framework we might want for our Starting View, imagine the office bulletin board with a variety of important and often timely info about office parties and upcoming events. In the context of a project that means we can reference actual project information through labels/parameters instead of having people type some of this same information into text. This connection to live data is a natural progression, even expectation.

More recently Andre Carvalho shared (at RevitForum, see link below) how he uses a linked project file to manage project notes that need to be visible to projects that have several or many models or even expand beyond one project to all projects in the office. He can update the master project file and since all the related projects have this file linked into them the information is updated automatically for him each time any project file is opened. Pretty clever stuff, working within the confines of the tools we've got. If you'd like to read more CHECK IT OUT.

If you aren't taking advantage of Starting Views, let me encourage you to consider doing so.

Dimension Style Type

That parameter name seems a bit like the Department of Redundancy Department. It lets us choose between three kinds of dimension behaviors: Continuous, Baseline and Ordinate. We are all pretty familiar with Continuous. I've spent time doing mechanical drafting (aka shop drawings) in the past and it wasn't uncommon to use some form of the other two types of dimensions. This is what the three of them look like together.

The Baseline dimension you see in the image is a single element, the entire collection of dimension lines you see. Each dimension line is offset from the others by the Dimension Line Snap Distance parameter's value.

Reload From with Images

Luke mentioned the Reload From button in the Manage Images dialog in his post the other day.

While preparing for my What's New in Revit 2015 session at the Revit Technology Conference in Melbourne last year (image above is from the session's handout) I found that it didn't work well. The Reload From button didn't replace the image when it is referenced in system and component families. It only seemed to affect images placed on their own within the project. It only seemed reliable when I used the browse button for the image through the image parameters in the properties palette (or schedule).

After reading Luke's post I went back to test it again, since we've had six web updates since then, and I was pleased to find that Reload From and Reload worked as I'd expect it to!

I then thought it odd that there is no way to just Place an Image, to place another copy of an image somewhere else in the project. By that I mean, the Manage Images dialog offers an Add button to load an image. If we've just or already loaded an image, the Manage Images dialog also indicates when there is more than one instance of an image in use. It would seem useful, to me at least, to have a Place Image button.

We do have Decals but they are really intended for a different purpose. We also manage the related images for them separately from the Manage Images dialog. I suppose it is easy enough to select an existing image and paste another copy elsewhere. If I'm not sure where to find it (which means I may not realize there is one) a Place Image button would be handy though. The available images ought to show up in the Type Selector?

Regardless the Reload and Reload From buttons in the Manage Images dialog makes it easier to revise an image and then show that revised version in our project. It's almost like an external reference. Almost, except for the automatic reloading when a project opens.

Schedule Text and Width Factor Fidelity

Schedules in Revit 2015 are able to use any of the text styles defined for a project. Text styles have supported the use of a Width Factor for several years. In schedules however this width factor is not observed so there is a loss of fidelity when comparing text elements and text that appears in schedules. The text above and below the schedule lines are using a width factor of 0.75 but the schedule rows do not look that same despite using the same text style.

Log this under Fit and Finish?

Text Formatting with Bold and Underline

Text is a common source of frustration in Revit. Replacing, improving the text editor remains a top rated wishlist item. Jean-Marc wrote to me the other day to mention something that I can assign to the Dept. of Subtle. If you use Bold and Underline on a portion of text and then transition to normal but still underlined Revit text doesn't deal with the underline transition well. Here's a comparison between what happens in Revit and Word.

I don't often use text but when I do I'm always wishing for that new text editor.

Revising Keynote Data

When you use keynotes and realize you need to revise existing keynote information it easy to change what the keynote text value is. We just need to edit the existing information and reload the keynote file.

It's a little different situation when you decide you need to change the numbering that is already in play. It's no problem if you are just shuffling note information around so you get the numbering sequence you prefer. As long as the keynote value remains in the list Revit will find it. You just need to make sure that any elements that are supposed to carry a certain keynote value still do after you shuffle them.

However, if you revise things and introduce a new numbering scheme and reload the file you'll find the keynotes will get confused. They stop displaying the correct information. For example let's say the keynote that was number 1 is now the letter A. There isn't a separate GUID that is guiding this alignment of data, Revit is relying on the information in the text file entirely. So Revit doesn't find the number 1 anymore and can't pair up the keynote value and keynote text anymore. The tag just reports 1 since that's what was stored to begin with.

The best place to check and revise the keynote assignment after revising numbers is in the keynote legend. You'll be able to review each keynote and activate the keynote table via the Keynote Value parameter, the little browse button that appears when you click on the value in the schedule.

You can select each confused keynote and map it to the correct keynote value. Once you've revisited all of the affected keynotes in the legend you'll find that the keynote tags throughout the documentation will show the correct information again.

Visibility of Floors and their Parts

Floors are unique in that Revit will show them even if they are below the view range settings of the view (floor plan). They'll be visible until they exceed 4' (1200mm) below the level. Parts that are created from floors won't. In fact parts created from a floor that is at the level of the view (in other words, normal) won't show up either.

It is necessary to adjust the View Range to permit the parts to be visible. It would be more consistent with floors if their parts assumed the same quirk capability.

Sorting Parameters - Shared Parameters and Projects

With 2015 it became possible to move parameters into more desirable positions within the properties of the family. In the family editor we see a Move Up and Move Down button to make this possible.

In projects however there are circumstances where taking the trouble to do this in the family doesn't have the same result in a project. A thread started at Autodesk's Revit Newsgroups where a product support specialist (Alaaeldin_Alsahil) responded with the following:

Shared parameters are shared between families in the project. The first family to load a shared parameter definition into the project defines the behavior of the parameter (in other words when loading a family into the project the description stored in the document is the one that is used). In this case, there was probably a family that was loaded with these parameters defined as "Other than the one from the family".

He then added:

The biggest problem is the shared parameter definition in the document cannot be edited (or deleted!) from the project. Purge unused also does not clear these definitions. There is no way for the customer to fix their file.

He suggested a workaround of creating a brand new shared parameter definition (new parameter in the shared parameter file), so that the definition in the project can be redefined. That's not always possible, in fact more than likely not acceptable either. For this project we'll have to live with the sorting condition as is. He did mention that loading content into project template files don't seem to suffer the same fate. That's good at least from a template standpoint.

Revit MEP - Detail Callout Bias or Gotcha

Many of Revit mEp families use a nested annotation symbol to provide the standard graphics we are used to seeing in electrical documentation. Here's a little example of a few of these families.

If you created a Callout view and these symbols vanish my bet is that you've used a Detail Callout. Here's what a Detail Callout view of the same families looks like.

It's definitely a quirky thing, but these nested annotations in outlets don't show up in Detail Callout view. Feel free to start trying adjustments to Visibility/Graphics, Detail Level, Discipline and more...I've been down the road already. I'm pretty sure we're looking at a bug, or at least a conundrum brought about by the way these nested annotations work.

This view type is also fussy about creating other elements, like a room/space for example. As such I understand that this view type is intended as the last stop or end of the road with regard to drafting up a detail, for detailing not modeling with. It's just odd that these annotation elements won't appear in the view.

If you want an enlarged plan to show these annotation then avoid the Detail Callout, use the Floor Plan type instead.