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.

Dimension Inline and Dynamo

(Edit: If you download and apply an update to his Rhythm package after 1/17/2018 you'll have this node too)

From time to time I've heard people ask about putting the dimension value on the line (inline) instead of above the dimension line the way Revit prefers. The only way we can do it within Revit is to manually grip and drag the dimension value down to the line.

More recently I read a thread at the Autodesk Forum asking about this. The premise in their situation is that it is a significant roadblock to using Revit for one of their client's projects, it doesn't meet their drawing standard unless the dimensions are inline.

I was trading messages with Aaron Maller and mentioned it to him. Aaron was trading messages with John Pierson and a few minutes later I learned it is possible with Dynamo and a custom node. This morning he shared this with me, as well as replying to the thread. Nicely done John! We are sooo connected these days.

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!