I am messing about with a workflow where i need the coordinates of the reference planes within my Revit project.
After a bit of assistance i have gathered the X and Y coordinates by collecting the BubbleEnd and FreeEnd, this however doesnt return the correct Z coordinates for the reference plane.
Using Revit Lookup i can see that the reference planes contains bounding boxes which has the required Z coordinates, but i am unable to retrieve these by the OTTB packages.
Have any of you had any successful workflows for either utilizing dynamo to gather the Z coordinates or in other ways collect the Z coordinates?
Also, reference planes are planes, and therefore may not have a Z level as the planes normal may not be aligned with global Z Axis. If you want to know where a plane intersects a view (a line), you can get the views SketchPlane and then do an intersection between ref and view planes. This will return a line, you might want to use the views bounding box or other method to constrain the line though as it will be unbound.
That wont really do the trick, as i cant rely on the views in the model - as that would simply require way to much work.
Let me give a quick run-through of the intended workflow.
The users should be able to create reference planes which they then modify in their length and height - these reference planes will be used for enabling the splitting of walls later on.
So the reference planes needs to be controlled so that they only intersect and thereby split with the intended walls.
Here the reference planes has been added for the future splitting of walls, the reference planes FreeEnd and BubbleEnd has been collected giving the start of the reference plane and the end of the reference plane (the lines of the reference planes) - however the Ends only return the Min Z coordinate.
BoundingBox of the reference planes
Then i turned to Revit Lookup and snooped the reference planes, and they all showed up with the possibilities of finding the Z coordinates for both min and max - i however have no idea if this is possible through dynamo/python
Had a play with this and the view seeing the reference plane seems to be the limiting factor, as it needs to use the bounding box of the element, and the method for this requires a view input in which the box is interpreted in relation to. Reference planes are abstract elements in that they aren’t really 3D objects, but rather elements that convey extents in relation to the viewing plane they meet (plan/section/elevation). I found if I got it in plan view it didn’t consider the Z factor of the min/max, and in 3D it returned an error. In elevation it gets the Z factor, but not the correct X/Y points.
This code retrieves the two ends in plan drawn view, which can get X/Y respectively. In my experience this works reliably regardless of the active view:
OUT = [element.BubbleEnd.ToPoint(),element.FreeEnd.ToPoint()]
This code gets the bounding box if the active view can ‘see’ the vertical extent, where only the Z is correct:
bb = element.get_BoundingBox(doc.ActiveView)
OUT = [bb.Min.ToPoint(), bb.Max.ToPoint()]
Assuming you can inform Python of a view that can ‘see’ the reference plane in each case, then you could theortically construct each plane’s bounding box, but I can’t find any other way in my findings - maybe someone else knows a more direct way. There is a property for a plane’s bounding box but typically this ended up giving me an Index reflection which isn’t valid to proceed with in Python.
I’d suggest looking around revitapidocs for potential methods/properties in Python:
As an alternative approach, maybe consider using a two level based family with vertical invisible lines at either end and a 2D plan view representation, which can definitely return a valid bounding box.
Aaah i see, just had a look at the BoundingBox when snooping the elements from different views - as u suggest the reported BoundingBox is dependent on the view from which it is snooped.
I think the most feasible way will then be to create a generic section which is extended to view the entire project - by feeding the python script with that specific view, it might work - otherwise i will need to create sections for each unique angle in which the reference planes are places.
Thanks a lot, i will try messing a bit more around with the potential solutions!
Creating a generic section didn’t really do the trick - or it did, but as touched upon it would require that all reference angles had the equivalent sections, and lists sorted to mirror which section where placed on a 90 degrees angle on the reference planes.
Which really would require a massive amount of code compared to the basic functionally of the workflow.
By creating a 2 level family as suggested i was able to extract outlining curves and thereby create a surface which could be used for the intersection check.
Unfortunately that’s a Revit behavioral issue. You’ll need to sequence it so that the new walls are made on the old one, the windows/doors are rehosted then the previous wall is deleted last. I’d suggest doing deletion outside the script.
