GetBoundarySegments With Linked Models

[mastjaso]

Hey I was wondering if anyone else has come across this quirk / bug and know if there's a work around?

I've got 3 models all linked together: 

1st floor,

2nd floor

Envelope / Shell

I've got rooms in both the 1st floor model, and the 2nd floor model, and each room is bounded by 3 walls in it's own model, and then one wall that's part of the shell model.

When working from the 1st floor model and calling GetBoundarySegments, it returns 4 boundary segments for each of the rooms in the 1st floor model, but only returns 3 boundary segments for the rooms in the 2nd floor model. It doesn't return the boundary segment that's tied to the envelope wall for the 2nd floor rooms.

I suspect it's because the envelope model is open in my 1st floor model, so from the perspective of the 2nd floor room it doesn't see the envelope model as loaded, but without seeing how that code is written I can't be sure. 

Is there any way to get the linked boundary segment of a linked room? 

[mastjaso]

Well I feel dumb for not remembering this sooner but the workaround that works for my specific case is to use the  CalculateSpatialElementGeometry method to get all the faces of the room and get the elements from there. 

I think this should still be listed as a bug though as I can't think of a reason that GetRoomBoundaries should just not return a boundary segment that exists unless I'm missing something.

[jeremytammik]

Dear Mastjaso,

Thank you for your query and congratulations on finding an efficient solution for it.

If you think it should be listed as a bug ( I would tend to agree), please provide a minimal reproducible case that we can share with the development team to get their opinion on it:

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

Thank you!

Best regards,

Jeremy

[mastjaso]

Hi Jeremy, 

Thank you for the reply. I have documented this bug below and provide associated files at the following dropbox link: https://www.dropbox.com/sh/i3b5ly5lvfucira/AABibDS6ceVf1B5YozMRuNOAa?dl=0.

I find dynamo / python easier for quickly testing out code so I've demonstrated it with that (in the Home.dyn file) though I can confirm that the exact same behaviour is produced from running a C# add-in (I also hardcoded in the UniqueIds of both the room and the revit link for ease):

This test project consists of 3 models, each one linked to the other two:

• Envelope
• FirstFloor
• 2ndFloor

When you open the first floor model, get the room from the active doc and get the boundary segments you get all 4 segments:

But if you open the 2ndFloor model, and get the room from the linked document the method only returns 3 segments:
 

I think this is because if you have two linked models in your main model, and you get an object from one of them, from that object/document's perspective the other link is closed (since it's open in the main model). 

I ran into this with hosted objects as well. We had two architecture models and an electrical one. If an electrical outlet in the elec model is hosted to the other architectural model, when I try and get the outlet's host it gives me the link element id which will give me the linkinstance but the link document returns null. The workaround with hosting is to get all linkinstances in the mainmodel and find the name that matches and then use the unique id to get the host element from there, though this is rather inelegant and doesn't help with a built-in function like GetBoundarySegments().

Regardless, since GetBoundarySegments() returns a BoundarySegment object with a LinkedElementId, it would still be helpful to get the boundary segment even if the link document isn't loaded from the room's perspective. If I had the 4th boundary segment and the linked element id I could still use a similar approach of checking the loaded documents from the main model for it, but without it I'm completely unable to know if my add-in missed a wall without computing the room's geometry.    

The Dynamo python code I used is:

import clr

clr.AddReference('RevitAPI')
from Autodesk.Revit.DB import *

clr.AddReference("RevitAPIUI")
from  Autodesk.Revit.UI import *

clr.AddReference('RevitNodes')
import Revit

clr.ImportExtensions(Revit.GeometryConversion)

clr.AddReference('RevitServices')
import RevitServices
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager

doc = DocumentManager.Instance.CurrentDBDocument

import math
import time

import sys

pyt_path = r'C:\Program Files (x86)\IronPython 2.7\Lib'
sys.path.append(pyt_path)

clr.AddReference("System")
from System.Collections.Generic import List
from System.Collections.Generic import Dictionary

outList = []
room = doc.GetElement("3c662375-fe38-44bf-a8c0-129e77cf6e67-00000a3f")

if room is None:
	lnk = doc.GetElement("0a513a3a-fc7d-4ce7-9e68-e541127e38d9-00000924")
	lnkDoc = lnk.GetLinkDocument()
	room = lnkDoc.GetElement("3c662375-fe38-44bf-a8c0-129e77cf6e67-00000a3f")


spatOpts = SpatialElementBoundaryOptions()
spatOpts.SpatialElementBoundaryLocation = SpatialElementBoundaryLocation.Finish
spatOpts.StoreFreeBoundaryFaces = True
boundSeg = room.GetBoundarySegments(spatOpts)
count = 0;
for i in boundSeg:
	for j in i:
		count = count + 1

#Assign your output to the OUT variable.
OUT = room, count

[jeremytammik]

Dear Mastjaso,

Thank you for your sample material and explanation.

I logged the issue REVIT-120488 [GetBoundarySegments omits edge from linked model -- 13406614] with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

This issue is important to me. What can I do to help?

This issue needs to be assessed by our engineering team, and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

• Impact on your application and/or your development.
• The number of users affected.
• The potential revenue impact to you.
• The potential revenue impact to Autodesk.
• Realistic timescale over which a fix would help you.
• In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

Best regards,

Jeremy

[mastjaso]

Hi Jeremy,

I think this may be causing some bugs in Revit itself, we're now encountering inconsistent behaviour with rooms. Those unbounded rooms in the below image are in a linked model, but their bounding elements are in the active model (the interior walls). Sometimes, and only sometimes, when you open Revit, the rooms will appear like the below, not fully bounded.

But through mysterious and random combinations of reloading the links, synchronizing with central, and closing/reopening you can get Revit to recognize that the rooms are bounded properly again.

The properly bounded rooms that you see are in the active model which is what makes me think this is the same issue manifesting itself somewhere in Revit itself.

[jeremytammik]

Dear Mastjaso,

Thank you for your update and additional private message, and sorry to hear the worrying news.

The issue REVIT-120488 [GetBoundarySegments omits edge from linked model -- 13406614] that I submitted for you with our development team has been replaced by a new development issue, since a code fix is required.

The new issue is REVIT-120608 [API | GetBoundarySegments omits edge from linked model -- 13406614]. Please make a note of this number for future reference.

The development team responded to the original issue: Reading the code, it looks like RoomElem::getRoomBoundaryData() does not handle curves properly that come from linked elements.

I wonder why this was not reported sooner.

I added a note of your updated news, raised the priority of this issue and asked the development team for a status update on it.

You mention only bi-annual Revit updates... in fact, major Revit updates are generally released on a yearly basis, and intermediate updates appear as well, so you may be in luck.

Best regards,

Jeremy

[mastjaso]

Hi Jeremy, thank you for the update! I suspect this has yet to be reported because I don't think most people tend to set their models up this way. But again, my suspicion is that all of it's being caused because a RevitLinkInstance will return null for it's Document if that link instance is the active document.

In my code I work around this by checking the link instance name against the active document, but this doesn't help with the room boundary functions.

Cheers,

J

[jeremytammik]

Dear J,

Thank you for another update and additional info, which I also added to the new issue is REVIT-120608 [API | GetBoundarySegments omits edge from linked model -- 13406614].

We'll see what the development team have to say about this.

Cheers,

Jeremy

[Mustafa.Salaheldin]

Dear @jeremytammik

I also face this problem. Unfortunately I can't submit a sample project but I guess the one that has been attached by @mastjaso is enough to explain the issue.

In my case the room's walls/separators that bounding it coexist with it in the same file. My issue is when I link this file to another file and then start to get the boundaries from the host file I also get the wrong number of segments.

I think also this is not a stable issue with Revit, as when I do some changes in the link file (like deleting elements or creating new ones) then save and reload, the host file can get the right number of segments. That is why I can't submit a sample project because the problem will be gone.

Is there any fix for that?

[Mustafa.Salaheldin]

I got the following errors in the Journal file:

' 1:< DBG_WARN: Invalid CurveLoop is formed by RoomBoundarySegments: line 736 of Elem\PlanTopologyUtil.cpp. 
' 1:< DBG_INFO: Odd number of edges for relinkEdgesAtVertexOnFace.: line 1799 of FaceUtil.cpp. 
' 1:< DBG_INFO: Failed to relink edges on face; trying again with increased vertex tolerance.: line 2280 of FaceUtil.cpp. 
' 1:< DBG_INFO: Failed to relink edges on face, even with increased vertex tolerance; abandoning all hope.: line 2287 of FaceUtil.cpp. 
' 1:< DBG_INFO: Geometric inaccuracies for FaceBooleanController::runFbcStage: line 3864 of FaceBooleanOps.cpp. 
' 1:< DBG_INFO: faceBoolean failed; subface information may be incomplete.: line 2699 of Elem\RoomGeometry3D.cpp. 

If this can help I attached the Journal file too.

[jeremytammik]

No fix yet. The development team are still looking at the issue I raised. New input on that might be useful and accelerate their efforts.

[jeremytammik]

I added your comments and journal file to the issue REVIT-120608 [API | GetBoundarySegments omits edge from linked model -- 13406614].

Cheers,

Jeremy

[Anonymous]

Waiting for solution for this issue. I have the same problem. I'm trying to get bounding segments with Curves and Element information for room in Linked File. 

First attempt was to use conventional metod  Room.GetBoundarySegments(opt)  but it  gives List of List of BoundarSegments with Count = 0 (for room in Linked Document)

Second attempt was to use SpatialElementGeometryCalculator for Lined room:

SpatialElementGeometryCalculator calculator = new SpatialElementGeometryCalculator(linkedDoc);
SpatialElementGeometryResults results = calculator.CalculateSpatialElementGeometry(linkedRoom as SpatialElement);

second line of code rise exeption: Failed to calculate the room 3d geometry

So if someone knows the way to get boundary segments info from linked file (note: boundary elements for room is in same linked file), please share information

[mastjaso]

The only workaround that I've been able to come up with is to get the room geometry using the standard Element get_geometry(Options) method, and then loop through all the edges to find the lowest, roughly horizontal ones.  This geometry still seems to be stored correctly no matter your linked file setup. You lose the ability to get immediate bounding objects, but these can be gathered through filtering and comparing to the lines you determine.

Really not ideal and a big performance hit, but this will work...

[Mustafa.Salaheldin]

Yes this could be a temporary solution, but it will not allow you to decide the boundaries type that you want to get the edges from them, so there is no way to choose between exterior, interior and center.

[mostapha_roudsari]

Hi @jeremytammik,

I know this is a very old topic but have there been any updates on fixing this bug? This issue is blocking us from loading linked rooms into Pollination for creating energy models. As a result, the user has to open every linked file with rooms separately to export the rooms.

[jeremy_tammik]

You can retrieve all linked models, retrieve the rooms in each of them, retrieve their boundaries within the linked model, and transform those back into the host model. Here is a chat with Gemini explaining exactly how:

• https://g.co/gemini/share/c8807b6be15e

Please let us know whether this helps and solves your problem. Please also share your final solution. Thank you!

[mostapha_roudsari]

Hi Jeremy,

Thank you for your response and the code sample. The challenge with receiving the rooms from the linked models and transforming them into the host model is that it could take a very long time. The main reason that we are trying to develop this workflow to load the linked rooms directly is to save the user from opening the linked file and save them time. Here is an example case that we had to ask the user to open every linked file: https://discourse.pollination.solutions/t/linked-revit-rooms-not-pulling-through/5495 - Your suggestion will help automate this, but it potentially takes a very long time. If we could get the boundary segments correctly, we could have offered a much faster solution.