Dept. of Wishes - Center Options Bar Options

I've often thought about this but don't recall complaining about it before. I "wish" that the options offered on the Options Bar were closer to the work at hand. Perhaps "center" all the options being offered by default, at least? Here's the Option for "Copy" when using the Mirror tool. It's soooo faaaar awaaaay from the work at hand. With the mirror tool I can use the CTRL key to toggle it on (if off) and off (if on). Still, if the options themselves were closer to the "action" that would be nice, no?

Work Plane Based Families and Rotate w Copy

I participated in a thread at Autodesk's Revit forum and it took me far too long to catch on to the issue described at the outset. I should have retraced the thread sooner, but I did get there eventually.

I'm referring to the Rotate tool and its Copy option, this...

The issue boils down to this: the Rotate with Copy option works/affects a Work Plane-Based (and face-based) family differently than when a family is merely hosted by a Level (all non "based" families). Let's start here, imagine I want two screens on my desk like this.

These are stock families: TV - Flat Screen.rfa and Desk.rfa The desk has a top surface that isn't visible in plan view so it can't act as a face to host the TV. I changed that. The TV isn't a work plane-based family. In a plan view, when I place it on the desk it ends up eaten by the desk because it looks like this in a 3D view.

Sure, I can use its Elevation from Level parameter to put it on the desk (an illusion of a relationship). When I move the desk I need to remember to select the TV too (or make a group...or...I digress). I get the clever idea, "Make this family Work Plane-Based, that's easy!"

Using Rotate with Copy should give me the result I want in the first image and it does until I check the box for Work Plane-Based. The angle I decide I want between the screens is 22.5 degrees. I added a couple reference planes for the images to help see what happens, the desired result.

That's what I want except that they should be hosted by the desk, not relying on using the Elevation from Level parameter. When I use Rotate with the Copy option after editing the TV family to make it Work Plane-Based (also Always Vertical is checked) I get this result.

Notice the TV angle itself is correct but it's location is wrong...and a warning message appeared to help me notice... It's been moved/copied by double the input value of 22.5 degrees using the origin of rotation correctly and managed to maintain the angle I wanted. This next image summarizes what happened.

That's weird enough on its own but I can go weird by one more, un-check the TV's Always Vertical parameter. After running through the exercise again I get this outcome.

This time it applied the rotation input angle of 22.5 degrees x 2 = 45 degrees to both rotating the family and its position. This time it did it fully wrong while the previous time it only did it half wrong.

Introduce a Floor, instead of a desk family, into the mix and place the TV family before it is Work Plane-Base with Always Vertical and this happens. No rotation, just copy and in the same place no less.

When the TV family is Work Plane-Based and Always Vertical is used then it works wrong in the same way as relying on the desk's face as the host did.

I imagine Revit is attempting to relate the rotation and copy actions to the family's host, since that is the work plane the family is hosted by. Clearly it is unable to do so properly. I think it is reasonable to expect to get the same result whether level based or work plane-based. This post and the images are from using Revit 2020.2 but I did the same things in Revit 2016 with the same results. This has been around for quite awhile now.

If it is any consolation, the Mirror and Polar Array tools don't suffer from this malady but each have their own prep work required to make them a ready replacement.

The Family has been Renamed

This warning message is probably familiar, troublesome and annoying.

I was reading a couple threads at RFO; THIS ONE and THAT ONE.

Apart from workset related issues I've written about before, I believe the underlying cause of renaming is that Revit perceives a family as different. That's not very surprising but I think that the actual difference is the result of different versions (2016 vs 2017) or having Save As used on the family (to put it in a different folder)...AND any operation that involves Copy/Paste, which includes the Insert from File tools.

When Load from Library > Load Family is used I only see it occur when worksets are being used (see the links at end of this post). The families merely having some different parameters (either instance or type) generates the dialog asking how we want to deal with the existing definition.

Using Revit 2017.1 and passing a family from one project to another I observed the following:

Family is renamed but no warning message:
If the family being introduced is an older version (upgraded) of one already in the model
If the family is same version but has had Save As used on it, i.e., to put it in a new folder location

Family is renamed and the warning appears:
If the family is an older version or Save As version AND Insert from File is used

Family is not renamed:
If the Family is copied from same library folder to a new folder
If the Family is from the same library folder
If the Family (existing) is reloaded from older version before using Copy/Paste or Insert from File.

The issue can be avoided if we are meticulous about using families from the same library and version. If we load office details from a detail library project file using Insert from File and the families (some or all) involved are based on older versions while newer versions are already present in the project we'll incur the renaming penalty.

The detail library should be updated, have the newer versions loaded first so they will be the same as those in the active project. If we need to keep the detail library in more than one version then we'll have to decide how to manage that and for how long. Merely upgrading the detail library model does not appear to be sufficient to avoid the issue.

I ought to mention that I can load a family and let it upgrade. Then if I use Copy/Paste to pass it along to another project file it does not get renamed unless the existing family in that project is based on a different version than the one I just upgraded. Upgrading a family does not seem to create the same problem that using Save As does for a family, at least not in the context of Revit treating it as a rogue family competing for the same name/existence in the project.

Regarding the workset issue I wrote three posts about previously, they describe how families can get renamed when worksets are being used and more than one person loads the same families and synchronizes their work in a specific way. The posts are:

FIRST post
SECOND post
THIRD post (references the first two as well)

Family Templates and Reference Plane Inequity

This is subtle but still a source of amusement or annoyance. Start a new family using the Generic Model template and try to copy an existing Reference Plane. Nope, the Copy tool is disabled.

Now try it with the Furniture template. Ah, Copy is enabled.

Try it in the Casework family template. You'll find Right, Left and Front Reference Planes are forbidden while the Center (Left/Right) and Back Reference Planes are not. That makes sense. Wait, what?

Okay, the rule is copying a Reference Plane working on furniture is okay and doing that in Generic Model templates = BAD? Doing it in the Casework template is, well it depends...

Actually the only rule is that you can expect some reference planes in some templates to be forbidden to copy while others are not affected by such thinking. Ralph Waldo Emerson cautioned us to avoid a foolish consistency. In this case a little more consistency wouldn't be bad.

...I'm not asking for all of them to be forbidden either...if you're wondering.

Wish - Copy, Rotate and Mirror Sub Elements

I really wish I could copy Split Line or Point while using Modify Sub Elements. It's really quite silly that I have to sketch or pick to place these things over and over (and this is a 2016 image...so no joy there either).

Paste Aligned Won't Play Along

I recently encountered a situation where two Paste Aligned options did not work while the option for "Aligned to Same Place" did. In this situation I was moving elements from one building file to another because of a scope of work switcheroo.

Typical we can select elements in a linked file and then paste them into the host project. Ordinarily I can paste walls, for example, using "to Aligned to Selected Levels" or "Aligned to Current View". In this case the walls didn't seem to remember their level arrangement even though both models observe the same elevations and naming. Revit insisted on putting them on the level above or the level below.

I ran into the same disrespect using "Aligned to Current View". The only way I got what I wanted was using "Aligned to Same Place". I was in a hurry so I didn't back up and try to figure out what might be contributing to the issue. I've never had a problem using the other options with elements that were already part of the same host file, you know just pasting elements to other levels to copy them upward or downward. Maybe it has something to do with the fact that these elements were coming from the linked file?

Something to consider the next time you are copying and pasting elements from one file to another.

Quick Tips - Cut/Copy/Paste - Paste Aligned

It is never a bad idea to remember to basics like these:

Windows Standard Shortcuts
Copy to Clipboard = CTRL + C
Cut to Clipboard = CTRL + X
Paste From Clipboard = CTRL + V

Paste Aligned
Think "Paste Special" in Excel if that helps...special paste options.
a) Edit Menu > Paste Aligned > Current View
b) Edit Menu > Paste Aligned > Same Place
c) Edit Menu > Paste Aligned > Pick Level Graphics
d) Edit Menu > Paste Aligned > Select Level by Name...
e) Edit Menu > Paste Aligned > Select Views by Name...

Explanations for each:
a) Current View will paste model or annotation elements into this view assuming you copied elements from some other view (or the same view technically).

b) Same Place will paste something back in exactly the same location. For example you want to move something from one design option to another. Cut to Clipboard while editing the one option and Paste Aligned > Same Place while editing the other option.

c) Pick Level Graphics will let you select one level to paste model elements on. For example select columns on Level 1 and use this option to select Level 2 or 3 or 4.

d) Select Level by Name will do the same as above (with Model Elements) but will let you choose multiple Levels from a dialog (Morerer fasterer)

e) Select Views by Name will let you paste 2D/Annotation Elements from one view into multiple other views by selecting from a dialog.

Thanks to Behzad from Kelar for the inspiration for this post and his quick tip about the using zero (0) with Paste...which is...

Let's say you need to alter a floor slab to indicate where one pour will end and another will start. You have one overall slab that needs to be two pieces. Bezad's example was focused on different phases. Edit the existing slab. While in sketch mode select the sketch segments you want in the "other" pour and Copy to Clipboard. Alter the sketch so the existing slab now represents the first "pour".

Now create a new slab and use Paste to place the sketch that you Copied to Clipboard earlier. When Revit displays temporary dimensions, you can enter zero (0) to "tell" Revit to paste at the original coordinates of the elements that you copied to clipboard. The sketch lands on top of the original slab location which can now be altered for the extents of the second "pour". Equal result as using Edit Menu > Paste Aligned > Same Place but you didn't have to go all the way up to the Edit menu.