Element.Room node (Rhythm) package - null values

You’re right, this is the reason.
I changed the windows’ phase for testing purpose, and it could detect some rooms, not all of them yet, I guess because I still have some families where the room calculation point is not activated yet.

Thanks you very much, it would be great if you could suggest any solution for a case like this; I am developing a solution which could save a lot of time for the project team, and the project is complicated concerning the phases.

It will take me a little time to get it, but let’s see what I can have by the end of the day?

*edit- ok, so end of day didn’t happen. That doesn’t mean I’ve forgot though. I’ll report back once I’ve investigated some more.

1 Like

Sure, thanks John!

The nulls are also caused by windows that have no room association. The biggest culprits are obviously windows on the external facade which have been flipped. A simple way to check is to look at the flip arrows in your model.

This window is in room 1

This flipped window shown below is contained in the opposite room - since its an external facade and there is no opposite room, the API room containment call will correctly return null:

@Thomas_Mahon, this does not remedy if the phases are different though.

The problem you are indicating is in fact not a problem because we can script them to flip to get the room and flip back with clockwork nodes.

The phase is the big issue here.

@john_pierson indeed, I wasn’t suggesting it would. Rather, phases cover one half of the problem, the other half of the problem is where new windows on the same phase are flipped. Whichever way you look at it, both are problems that require a remedy :wink:

2 Likes

Of course, we went through this in another thread once. Clockwork definitely helps out!

1 Like

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. :slight_smile:

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

Hi @Ahmad_Saad, can you share your script?

Sure, here is the graph:

1 Like

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