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.
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.
No comments:
Post a Comment