Showing posts with label Dept. of Reviteristics. Show all posts
Showing posts with label Dept. of Reviteristics. Show all posts

Wednesday, August 05, 2020

Ramp Slope is Still a Second Class Citizen

Wrote about this before in 2013. Ramps and the Slope Annotation don't like each other. In the past we could work around their unfriendliness by dragging a working slope annotation from an adjacent floor to the ramp. That no longer works since as far back as 2019.

I'm reasonably sure Ramps have a slope... odd that the annotation doesn't think so? I wrote another post in 2013 too that describes using an adaptive point family to add some graphics to a floor posing as a ramp which might also permit using the slope annotation on it instead. Yet another thing to experiment with.

Then again it might just be better to ignore the ramp feature entirely in favor of Floors?

Saturday, November 30, 2019

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.

Thursday, December 21, 2017

Sketching Tangent Lines

A post based on my responses at the Autodesk Forum: Tangent Circle to Tangent Circle.

It could be easier...

I see Revit behaving this way, they regard the first point as ineligible to being tangent because it depends on the bearing of the line, With that assumption or bias, the first point is necessary to make a tangent condition possible. I can easily snap to a location on the circle (a pulley for example) that couldn't be tangent to the next pulley.

AutoCAD deals with this in a clever fashion (when we invoke the tangent snap) by fixing (changing) the first point to be tangent after the second point is placed. If we aren't careful with our second pick point (snap tangent too) the tangent line might end up on the opposite side of the pulley.

In contrast, Revit handles it naively, because it regards our first point as ineligible to tangents because it isn't considering this particular end result: "I want to draw a line tangent to two circles". AutoCAD appears to know this by virtue of snapping tangent for the first point so it can adjust the final bearing, and attachment to the circle, of the line.

To get around this naiveté, I place the first point on the pulley where it looks like it can be tangent, to my eye. The second point snaps to tangent with the icon. I return to the first point and grip/drag it away and back to let the snap icon appear, to fix it for tangent, just to see if I was close. If my guess wasn't accurate, it is now.

After reading a reply to my comments I did a quick sketch in AutoCAD and then did the same sketch in Revit using the same pulley sizes and offset from one another (see Footnote). The tangent lines have the same x/y properties for start and end as the AutoCAD version, that I made using its snap tangent.

This is the native DWG sketch and properties screen captures for each element.

This is same information but for the Revit drafting view exported to DWG. When I create an External Reference of the exported Revit drafting view it lands right on top of the native sketch. If you look really closely you'll see a value is slightly different in the Revit version. I think that might be my fault, sketching. Regardless, I think close enough is fair.

Footnote: Regarding a drafting view aligning with a DWG file after export: It might not be obvious but drafting views have an origin. To test that claim link a DWG, that has a marker at the WCS origin, into one and you'll see where the origin is. I did that before I did any sketching so I'd know how to place the pulleys in the same place. That made it possible to compare the tangent lines after exporting it to DWG.

Also the Start and End X/Y values are reversed. That's either just how Revit interprets the vector of each line segment or it's because of the direction I chose to sketch them in Revit. In AutoCAD I started at the smaller pulley. I didn't make sure to sketch in the same way in Revit, sloppy scientist.

Tuesday, March 22, 2016

Temporary Dimensions and Activate Dimensions

I've written about Temporary Dimensions and the Activate Dimension button in the past (2007-9), these are some posts that discuss them.

Space Bar Subtle Effect on Temporary Dimensions
Dept. of Reviteristics - Activate Dimensions
Activate Dimensions
Activate Dimensions - Redux

Temporary Dimensions don't appear when two or more elements are selected. When that happens you should see the Activate Dimensions button appear on the Options Bar.

Temporary dimensions also don't respond to families that host nested shared families. That's because these families are also regarded by Revit, under the hood, as a selection of two or more elements.

Sunday, November 04, 2012

System Inspector Inspect

Using Revit MeP, this feature makes me think of Monty Python's Dept. of Redundancy Department every time I use it. When you have elements connected together well Revit's System Inspector icon will be available.

Reading between the lines, that means if you don't see it when you think you should, something is wrong. The part that gets me is as soon as you activate it you get a little ribbon panel like the one we get for Groups. To inspect a system what's the next thing we have to do?

Yeah, tell Revit we want to Inspect. Department of Inspection Inspector?

Tuesday, April 10, 2012

Finish and Cancel Inequity

In the past Aaron Maller and I have had long conversations that oddly enough focus on Revit. He mentioned the inconsistency between the way some elements that are sketch based are finished and the way shape editing for floors and roofs finish. He recently reminded me of it, for example he put forth this list.

Floor, roof, stair or ramp Sketch Creation = Finish and Cancel
Edit Profile = Finish and Cancel
Model Groups = Finish and Cancel

Floor or roof Shape Editing = Accidentally hitting the escape key and getting kicked out of it. We are supposed to click the Modify button to finish Shape Editing.

It would be great if Shape Editing were consistent with the others!!

Monday, April 02, 2012

The Missing Door

There are two situations that trip up new users when it comes to doors. I wrote about about one of these Reviteristics in April 2010. That post is about Openings and this one is about curtain wall panel doors.

When people first make a curtain wall that is supposed to get a door they quite naturally assume the door tool is the right place to start. Wrong. Curtain walls are special and they are made up of curtain grids, panels and mullions. A curtain wall door is really a curtain wall panel. They are a panel because Revit needs to keep their width and height flexible, to accommodate any changes we might make. A regular door family can vary in size but it can't respond to curtain grids being moved. We can't even put a regular door in a curtain wall. That's not entirely true but I'd have to get into yet another Reviteristic, using other wall types as curtain wall panels.

We need to understand that a door in a curtain wall isn't a "door", at least not to the Door tool. To make matters a bit more confusing Revit treats this curtain wall panel, pretending to be a door, as a door in schedules and in Visibility/Graphics.

    It would be better if we could click on the Door tool and have the option to place a "regular" door or a "curtain panel" door. At least this way it would become immediately apparent that there is a difference!

Curtain wall panel doors are found in the Doors folder within the content library. That seems slightly logical, in the same way that Opening families are found there (Edit: Openings have their own folder beginning with version 2012). When we want to load a curtain wall door family, browse to the door library (stock content location).

Placing a curtain wall door is a bit different than a regular door in a wall. We don't use the Door tool. We have to swap out the panel that should be a door with the curtain wall door family that you loaded. To do this we need to use the TAB key to select the panel and then use the Type Selector to choose the curtain wall door family instead.

Once you do this you'll have to make sure that the curtain grids and mullions are adjusted to report the desired size. If you set the grids and mullions before the door is in place you'll find that the size is not quite the clean numbers you probably wanted. You can resolve this with mullions that use different offset values or just re-position the curtain grids until you get a cleaner door size.

I captured another video in the "Five Minutes with..." theme.

If you want to create a new curtain wall door family you ought to examine and/or reverse engineer the stock one first. You can start from scratch with the family template (Door - Curtain Wall.rft)

Tuesday, January 10, 2012

All Capital Letters

Saw a request recently to change the "Grand Total" (title as Revit calls it) that appears at the bottom of Revit schedules from Sentence Case to Upper Case.

My first reaction was to wander down the path of reminiscing why we use upper case in documentation at all. Going back to hand drafting and reducing the number of characters to master for simplicity and consistency sake. Whenever something like this comes up you can go the route of justification/explanation, "Well, here's why Revit does it that way. I know you don't feel better, but at least you know why though?" Alternatively you can just go the route of apologizing, "Nope it doesn't do that, sorry!"

    Something like this request both seems like such a tiny thing to fuss over and still such a tiny thing for the developers to overlook. Why can't we change the "case" of such automagic labeling?? Surely it can't be hard? If we add in localization, making Revit use a different language, there are some examples of where users are stuck with the English text even though the rest of the words on the documentation aren't. I seem to recall the word Scale for the view scale is/was one of those.

If you really want to get your way, you can, not hard...just isn't automatic, you'll have to keep after it. Alter the schedule so it uses the Totals Only option. Then at the bottom of the schedule add a text element that says "GRAND TOTAL". You've got to move this as the schedule expands/contracts. Remember to check it before printing.

Maybe someday they'll make it possible to change these "little things"? Definitely a Dept. of Reviteristic or perhaps Dept. of Quirky or Dept. of Subtle. Heck all three work for me!

[Added: 1/10/2012] Paul Aubin mentions in a follow up POST that we can use a font that only has upper case characters. That's a trick that a few people I'm met or know from the user forums on the "internets" have used. Assuming you can find such a font that is acceptable it might just work. Remember you've got to make any downstream users also have the font.

Tuesday, January 03, 2012

Sorry You are Too Short

No I'm not picking on short people, that's Randy Newman's domain. Revit does have a bias against short lines (as most of us are well aware). Try sketching a line that's less than 1/32" long and you'll get this message.

It also doesn't care much for moving or copying elements very small distances. You may have run into this message?

What may not be obvious is that you can often trim a line to be shorter than the minimum size of 1/32". The threshold appears to be 1/128" (.16mm). In my experience this appears to work for most families such as annotation, detail component and generic model families. I've tried it in various project views including a drafting view without success. The project environment seems to be entirely intolerant of slipping past the 1/32" (0.780369mm) threshold. Trying to get smaller than that generates the first warning again.

If you want to copy/move something a smaller distance and get the warning, try dragging or using CTRL + Drag. You can get the arbitrary smaller distance and then use the temporary dimension to set the actual distance you want. Sometimes you can affect this limitation by zooming in closer, at least with regard to move or copy.

Fwiw, 1/128" converted to decimal is 0.00781250". I was able to make a line shorter still, to this decimal inch value 0.0063477", however Revit could not display anything other than 1/128" unless I changed the project units to decimal inches first using six decimal places. It is possible to create shorter lines than we are accustomed to (Revit limits) but only in family files.

Tuesday, November 15, 2011

Sneaky Buttons

I wrote this POST in August 2005 and then followed up with another POST in July 2008. All these years later this sneaky button still has no tool tip to tell you what it does or that it is even a button. Really sneaky in my book!!

There are other Reviteristic the first POST if you are interested.