Rotate elevation marker inconsistent

Revit
1

Hi

I am trying to create elevations markers for each wall face of a room. I’ve been referencing this post to rotate the actual elevation markers. It is mostly working but I am finding the rotation is inconsistent.

To calculate the angle, I am constructing a line perpendicular line from the midpoint of the room boundary curves. This is all working. But as shown below, I have two elevation markers that need to be rotated 220 degrees. One of them rotates (anti-clockwise), the other I’m not sure but it is 180 degrees off. It has nothing to do with the wall direction as I am not using this information.

Capture
Capture.JPG2254×1158 192 KB

The only thing I can think of is that the when the initial elevation markers are created that they don’t have the same orientation (@john_pierson) .

Capture2
Capture2.JPG1408×625 57.3 KB

Any ideas what is going on? @Steven @awilliams @franciscusm

Using Revit 2019 and Dynamo 2.0.3.

Thanks

Rotation study_v3.dyn (91.1 KB)

2

The API call for creating an elevation marker just places them the same way the UI does, Orthogonal.
Here is the code from Rhythm for your reference too. https://github.com/johnpierson/RhythmForDynamo/blob/master/src/Rhythm/Revit/Elements/Elevation%20Marker.cs

The image below is me running your graph with the python script frozen.

image
image554×538 9.27 KB

The next image is me running the graph with your rotation in tact. That seems consistent to me, (keeping in mind I am not too familiar with the graph).

image
image565×549 9.82 KB

Have you referenced this as well?

1 Like
3

@Paul_Wintour,

I never got around to posting this way back when as the project I was working on stoped. I too occasionally experienced this strange behavior.

I left the project unfinished but my final notes were. Check to see the direction the elevation is facing (if correct do nothing / if incorrect activate the elevation on the opposite side and delete the initial view)

As you can see below the elevation facing the incorrect direction are a bit sporadic.

image
image.png1339×584 23.4 KB

image
image.png1324×540 20.7 KB

image
image.png1189×632 24.2 KB

The walls above were mirrored about the line from the walls below
image
image.png1191×652 24.3 KB

image
image.png1301×646 23.4 KB

4

I have worked around this with an add-in that I built for curtain wall elevations. The way I worked around it was to check which quadrant the the line pointed towards from the wall and if it was in 3 or 4 I believe I reversed the and (-π) but it’s a bit different because Revits core rotation is in radians. A little goofy, but it works every time.

2 Likes
5

I feel like i am so close!
@Paul_Wintour, thanks for posting this graph. It works well to rotate multiple elevation markers, but my conditions are a little different and they tend to move around after they are rotated. It seems like the axis of rotation is being fed by the view. Is there any way to feed it in directly with vectors or lines that correspond to each axis of rotation?
I tried the Rotate Family node from Archilab, but I am not having much luck with it. I think its because it only takes one family at a time.

6

I never finished this graph - it got put in the “too hard” basket as it seemed like a Revit bug. My elevation markers did move around a bit but from memory this was due to the 0,0 point (or bounding box) of the family rather than the python code.

7

It is hard. I had some hope with editing the elevation marker family to include an invisible circle. Didn’t work though; I guess that would have been too easy. If I could pin down the center of the default rotation axis, I would write the graph to place the families at a point that corresponds to the future rotation. After some trial and error, I still haven’t been able to locate the point. It seems like there are other variables at play here. What is the view input for?

bbox = (i.BoundingBox[view])
diag = Line.CreateBound(bbox.Min,bbox.Max)
p1 = diag.Evaluate(0.5, True)
p2 = XYZ(p1.X, p1.Y,p1.Z+1)
axis_ = Line.CreateBound(p1, p2)
axis.append(axis_)

Wait, I think I figured it out; at least a little bit.
In this script, the view is required to get the marker - then a bounding box is created about the marker which corresponds to the scale of the view. Maybe you see where I am going here.

This solution may seem ridiculous:
Since a view input is required for the Python Script, you may as well change the scale parameter of the view with Dynamo to the finest setting - like 12" = 1’-0". Then after the script runs, change the scale back to the original setting. The markers still move, but the scale of that movement is constrained to the view scale. At least it is no longer noticeable!

Still, I feel like there is probably a more elegant answer out there. This work-around could have issues with some view templates. I wonder if Jeremy, the original author of Module 2 has any input on this. His script uses the center point of the wall line for the rotation axis. Till then, view templates can be temporarily switched with Dynamo as well.