I’m collecting the rooms from a linked model, then trying to get the room boundaries to find points in rooms. The Crumple Room Boundary node is able to provide the boundaries from linked models, although there seems to be an issue where if the bounding element of a room comes from a linked model then the API isn’t able to create the complete boundary and I’m left with thousands of elements. Snip below showing the output of all the boundaries from a level.
I do not want to create the rooms myself as there’s thousands of rooms, and the architect has said they will get the room bounding correct so it seems a bit pointless to recreate them if they already exist which is also more of a ‘BIM’ workflow to me.
This appears to be an API limitation for Revit 2024 (depending on how accurate this chatbot response this), is there a potential workaround as visually on the floor plan I can see the whole room boundary of the room element, I’m not sure how to read the API docs updates either to see if this has been fixed in newer versions.
I would say it isn’t accurate. Just about anything is possible, but the question is how to go about it, and how fast the automation will run.
The best path forward will require knowing your intent though. is your goal in doing this? Your original statement of “to find points in rooms” is a bit too vague to know what you’re after, otherwise just pulling the room’s location point would do the trick.
At its most basic level the script takes the Crumple ‘Element.Centroid’ node for the elements then transforms the location depending on it’s orientation (downwards if it’s ceiling mounted or located in the ceiling void, forwards if it’s wall mounted, etc) so that the elements that sit on the fringe of the room are moved ‘inside’ the room.
This is so that regardless of the method (intersect solid, point in room, raybounce surface) they should be more accurate instead of overlapping with room boundaries.
Where the outcome of the script is to find what room an element is in for the clients assets register and update a parameter.
Speed is somewhat important, but if it’s necessary to run it on one level at a time in order to get accuracy in room bounding that trade off is acceptable.
Why don’t you get the Linkelement.Solids to get the geometry of rooms? I understand, sometimes it fails, but for 90 % of rooms should be good. Then you can check if the element is inside of the room by measuring the distance from centroids of elements to solids of rooms.
I don’t recommend centroid in any circumstance as the outcome is too easy to skew to something incorrect. Ideally I would recommend using the family instance’s room location point. Ensuring that on in all the family documents is both a best practice and likely the easiest path forward as it’s a one time event per type instead of once for all instances. For multi-location types (doors, windows) you will have to decide if you want to use the to room or from room point though.
I tried this and did a comparison against the room boundaries, and the room boundaries collected more boundaries for every room than the finish boundary.
Although the rooms the finish boundary collected all seem to be ‘complete’ rooms which is better for processing if the rooms are bounded entirely within the linked model, while if you look at the preview, the room boundary collection also collected as many boundaries as it could but still ignores any room bounding from a linked element.
The edge case of L shaped objects putting centroid in locations which don’t report a useful location is too frequent. The result of which is significant exception handling which slows things down and you still get a lot of false positives. Enabling location point and reporting rooms that way solves the issue and runs faster as there is no need to pull the geometry of the family instances to get the centroid.
For the object types which can’t have a room calculation point turned on, the location is the next best solution. If the location is a curve type take the curve geometry and pull the center point; if it is a point then just take the point. From there pull the points to an elevation just above the associated level by adjusting the Z component (pntCheck = Point.ByCoordinates(pnt.X, pnt.Y, lvl.Elevation + 1); and get the room at that point using the room at point method.
I’ll update the script to use the location point, I’ve processed the line based families before so that should be fine.
I have seen a few nodes that can take points and rooms, but the internal origin of the linked model is wrong so I’m not sure if these nodes automatically do the transform since I’m inputting linked elements (not rooms from the MEP model), although I guess it’ll be obvious if it doesn’t do the transform because there will be no results.
Totally agree I could use spaces, but it’s going to take 10-20 times the effort/time to maintain 10,000+ spaces on this project when the architect already has a requirement to deliver bounded rooms so they’ve done that process for me.
I’m very hesitant to use any rooms or spaces as the models are already big enough, if I was to copy spaces in they’d push the file size over to where I’d need to split the models down further.
As a workaround to that if I create the spaces in a dummy model then link in the MEP models to find linked elements in local rooms/spaces, it should work but that’s on the assumption that they get all created perfectly without me having to review the space bounding and then raise the spaces up to be slab to slab to capture elements in the ceiling void.
Spaces in theory are the solution but why replicate something the architect already created, as this process is simply for the asset requirements (no design parameters required) so it wouldn’t even be necessary to create spaces but also use rooms as there’s more dynamo nodes for finding elements.
I’ve recreated the scenario where the MEP model has Arch-A and Arch-B as model links where the rooms in Arch-A are bounded by Arch-B, I’ll make a simpler version of my script as well for how I had been finding the points in rooms.
Your summary is correct, I want to collect the Room Name & Number to put into a shared parameter.
I’m trying to avoid at all costs creating the spaces (or rooms) as I while it’s possible to bulk create these also with dynamo I will likely end up with rooms that have bounding issues which will be hard to spot across thousands of views.
I’ve uploaded the scenario models to try come up with a workaround for the room bounding from linked models, I’d even rather work in an offline version of the architects model to put in room separators than recreate spaces since I know they have their model linking bounding settings already correct.
I’ve simplified the script a bit which shows the behavior with linked element bounding, and my current workaround using the element location closest to whatever room boundary lines that are in the Arch-A model, it’s been updated to use the element location instead of the centroid.
The Autodesk electrical fixture family being hosted makes it hard to move the location of the point ‘inwards’ to the room but in this scenario it still works.
Part of this problem is that the collectors for rooms from linked models do not get complete boundaries- as you say, bits of geometry are missing.
I’ve always thought the Revit ‘‘çopy monitor’’ tool should work with rooms. In your case, you would copy monitor all the rooms from the architects into your MEP model. This would eliminate the problem you are having.
