Showing posts with label Snaps. Show all posts
Showing posts with label Snaps. Show all posts

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.

Wednesday, March 18, 2015

Web Update 7 is Innocent

A quick follow up post. I was wrong. What I thought was caused by the update is actually caused by the Snap setting Snap to Remote Objects being off.

I must admit it is a bit mystifying since I never turn it off or at least I can't remember I time when I wanted to nor do I remember doing so. Regardless when support gurus Trey and Danny challenged me with their questions I found it was off.

Fwiw, I'd prefer that it didn't impact grid and level placement editing behavior regardless.

At least it prompted me to deal with a couple hours of windoze updates I'd been postponing.

Thursday, June 14, 2012

DWG Files and Funky Snapping

Importing survey files has always been problematic with Revit. Two things are fundamental issues: large file extents and distance from origin.

Geometry that is far apart will annoy Revit, geometry more than 20 miles in extents is the current "line in the sand". Just how precise this 20 mile consideration is a little hard to pin down. There must be some specific logic or algorithm the application uses but I've tried numerous times without success to arrive at something consistently true.

For example I've tried to draw squares and cubes, even circles and spheres to test the extremes and predict the trigger of the error messages I've written about before. As soon as I think I have something I can predict I try it again and get a slightly different result. My general rule of thumb is to try hard to make sure that I don't have extents that exceed a sphere that is 20 miles in diameter.

The other issue is when the data in the CAD file is small enough in extents but really far away from the file's origin, according to the WCS which is all Revit really pays any attention to. I can have a relatively small project site survey but far from origin and end up with Revit using Auto - Center to Center to place it. That's not really a problem though. We can just tell Revit how to resolve that with the Specify Coordinates at Point tool.

Now as for the title of this post, Revit hollers when our file is "too big". The warning tells us that this situation may affect the graphic depiction of information on screen.



This manifests itself in snap icons that appear to miss the element we are attempting to reference in the CAD file. It also shows up when you use the Pick tool to place lines and the sensitivity of the tool seems offset somewhat from where we see the line.

With Revit 2013 they've added an option in the Import dialog that says "Correct lines that are slightly off axis". This is a bit of spin unfortunately because this addition means it acknowledges that Revit has been altering them before, all along. Part of the solution to the funky snapping is resolved with 2013, don't check this option.



With Revit 2012 we can still avoid it but we have to import the DWG files a little differently. The trick is to let Revit place them using Auto - Center to Center and then move files, however many you need to use, into place manually. If we try to use the trick to Specify Coordinates using one file first and then import the rest using "Auto - by Shared Coordinates" it will trigger something internally that in turn triggers the snapping issue. That trick generates a message that these files aren't sharing coordinates but the end result is that they land in the correct location because shared coordinates are matching their own understanding of the WCS.

Here's a summary of steps, sort of...

Examine your survey file and make sure it isn't too large.

If it is you need to reduce it so just the really relevant part of the site is what you import. I realize that there may be situations that challenge this assumption but if you create two files from one that provides two that are small enough to avoid the error message about extents then you can still bring them in, position them manually and then specific coordinates.

Once you've resolved the survey file checking, pick a spot in each file that can be used as a common reference benchmark. You'll need it to move them into position in Revit. Write down what the coordinates are for this benchmark.

Now you can import the files into Revit. Use the Auto - Center to Center option. In Revit 2013 don't check the "Correct lines" option. You don't have this option in 2012 but this process will still work.

Move the files into position keeping them all near the Revit project file origin. Now you can use the Specify Coordinates at Point (SCaP) tool to match up Revit with your benchmark in the cad file. Unclip the Survey Point and move it to the benchmark location. Fire up the SCaP tool and enter the matching coordinate values.

Revit now understands your real world situation. You should find that snapping to the imported file elements is not showing the graphical glitch.

Important, there is one more thing to avoid, don't create a master survey file that uses attached Xref's to combine several files together into a single file that gets imported into Revit. Doing this will trigger the snapping issue again. It does it in 2012 and 2013 regardless. I believe that the Xref's mark the origin somehow in the master file which creates an unavoidable file extents problem which brings the snapping issue back to life.

Easy?? Wish it were easier!