Tell me if I’m wrong, but this could be a workaround:
1 Like
That should do it. That was another one of my thoughts was using intersections. The nice thing with Element.Room is it’s an API method that doesn’t use geometry or bounding.
It’s true, but I understood that rooms didn’t have any phase option and I found it a bit complicated. Bounding Boxes seem to be a great tool to solve problems away from Revit constraints…
1 Like
This is very well put. 
1 Like
@Thomas_Mahon Thanks Thomas, I thought about this already, and I ran a check to make sure that the windows are correctly coming “from” their correct rooms.
@Yna_Db. I like this workaround, thank you, however the risk in my case is that whenever I create a Boundingbox , the intersection is not only with their rooms, but also with other windows (screenshot attached - windows in blue), I think it would be great if we can scale these BoundingBoxes to be exactly the same size as the original windows’ & rooms’ volumes.
Couldn’t you reduce the windows bounding boxes (with Springs.BoundingBox.Scale for instance) to a minimum volume just to check the intersection with the rooms bounding boxes?
I didn’t know about this package before, thank you @Yna_Db
I started to build another script using this method, and gonna continue next monday
Regards
2 Likes
Hi guys!
I had the chance to finish this script.
I found that my best (and accurate) solution was to use Rooms Boundrais to create dynamo extrusions, then increase their thickness, and then Element.BoundingBox for the windows/curtain panels, then using GeometryDoesItersect I could have a mask to use it later to have curtain panels/windows grouped by rooms.
Also I found that the node “Get surrounding elements” was using the BoundingBox method. that’s why it was not giving me accurate results especially that I have a lot of irregular room outlines.
Thanks a lot for your help!
2 Likes
A bit late but still in the same topic - I’m also trying to find an intersection of certain elements (revit families - more specifically their center points) with room geometry (also extruded as solids, like Ahmad did), without using Tool.GetSurroundingElements.
Up to this point I have the same solution as shown above but then the problem is: script works like 7-10 minutes with this method and only like a minute with GetSurroundingElements. What’s making such a huge difference? Is it because bounding box shape is a cuboid so it’s always going to be faster to find intersections? I wish I could edit the python script of the node but it uses Outline method which is for bbox only. How could I feed it the solid geometry outline instead? Would it produce the same time difference anyway?
Best to start a new topic, but yes bounding boxes are significantly faster than geometry intersection as trouncing box containment is a matter of checking XYZ values against each other, while geometry intersection is quite a bit more involved.
This Revit API method might simplify things for you: GetRoomAtPoint Method (XYZ)
1 Like
And specifically, arch-lab has a node for you that does that method.
2 Likes