Short introduction
We are a manufacturer of precast concrete stairs.
Since the Builtin Revit Stairs have a lack of possibilities we build our Families as Generic Models.
Right now we are looking for ways to automate the generation of views for our shopdrawings.
Assemblies
We are focussing on Assemblies, as they seem to have the most advantages. But by default there is also a big disadvantage, witch is the orientation. If a family instance has a rotation (not aligned to the X or Y-axis), the views are not aligned to the family instance, but to the X or Y-axis (see picture 1).
Assemblies do have their own Assembly Origin wich can be manipulated by Python.
In the thread below @daniel_woodcock1 was kind enough to share a Python script that can rotate the Assembly Origin.
import clr
import math
clr.AddReference("ProtoGeometry")
from Autodesk.DesignScript.Geometry import *
clr.AddReference("RevitServices")
import RevitServices
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager
doc = DocumentManager.Instance.CurrentDBDocument
app = DocumentManager.Instance.CurrentUIApplication.Application
clr.AddReference("RevitNodes")
import Revit
clr.ImportExtensions(Revit.Elements)
clr.ImportExtensions(Revit.GeometryConversion)
clr.AddReference("RevitAPI")
from Autodesk.Revit.DB import *
def tolist(obj1):
if hasattr(obj1,"__iter__"): return obj1
else: return [obj1]
elems = tolist(UnwrapElement(IN[0]))
axis = tolist(IN[1])
rot = tolist(IN[2])
outList = []
for e, a, r in zip(elems, axis, rot):
trans = e.GetTransform()
transRot = trans.CreateRotationAtPoint(a.ToXyz(),math.radians(r), trans.Origin)
try:
TransactionManager.Instance.EnsureInTransaction(doc)
e.SetTransform(transRot)
TransactionManager.Instance.TransactionTaskDone()
outList.append(e)
except Exception, e:
outList.append(e.message)
OUT = outList
I used this Python script in my Dynamo workflow (also attached below).
After running it the Assembly Origins are rotated correctly, and the orientation of views is also correct.
But the centerpoint of the Assembly Instance seems to be no longer the basepoint for the created views (see picture 2).
The views are aligned with the element, even if the (highlighted) stair is not aligned by the X or Y-axis (45 degrees rotation). I created this result by manualy rotate the Assembly Origin in Revit.
You’re using the z axis at the origin so that’s why the assembly rotates around the origin(0,0,0).
You have to rotate each assembly around it’s own center
I took a look at the script and it’s possible that it’s not the rotation axis, but rather the way the views for the assemblies are created. The method in the API doesn’t seem to have any control of where exactly to place the the section lines and thus the crop region includes much more than the stair. I don’t have time to go into further detail with this, but you may consider creating the views without assemblies.
I might not be right though. I hope someone else has more info about it.
Hi I was playing with the assemblies recently and I think creating the views using the Assembly build-in functionality is better. I am talking about this.
And here is the Dynamo node for this.
You can find the node in Steam Nodes package. You are able also to create the assemblies inside Dynamo with Tool.CreateAssembly node and to automate the whole process. I’ve done something like that to create assemble views for curtain walls.
I guess that I am missing something. What is the sequence in your script? Because what I’ve done is first to create the assemblies then to rotate them and after the rotation I create the views and everything is fine.
I know it is different but the logic should be the same. Here I needed always to have front view showing correctly no matter the orientation of the wall.
This node is the same that you are using. I just wrapped it in a custom node to use the @level functionality. It is still the same python code that you are using.
Assembly Views are placed on the faces of the “Assembly BoundingBox” (see picture above). So the only thing i can think of is that the size of the “Assembly BoundingBox” is (heavily) affected by rotating the Assembly Origin. If that’s the case it would be far beyond my knowledge. On the other hand that makes no sense, because @Petar_Penchev1 is doing the same thing, and it works fine for him.
