I am attempting to use BimorphNodes package IntersectsElement node in a graph that overrides the color of elements that clash. see attached graph. In the example in the image below, I am attempting to get structural framing elements from a consolidated structural model that is comprised of several linked models that have been generated from .ifc files. I am then trying to clash ducts against those structural elements. Everything initially appears to be working, but the IntersectElements node just returns empty lists. I know for a fact that I have several hits between the elements. What am I doing wrong? Does this node support retrieving data from nested links? Does it support ifc content? I appreciate any feedback anyone is willing to provide. Thanks in advance.
Perhaps that node doesn’t work with links? Or you haven no clashes?
Bimorph’s node is super robust, but you might have to wait for the linked file additions, (If that is the case).
In the meantime, here is an alternate solution using Element.GetIntersectingElementsOfCategory from Rhythm.
Thank you for the reply and alternate workflow @john_pierson. I will give it a try.
In regard to the Bimorph node, I have already confirmed that it works with links. I also know that I have 12 clashes in my test example. I am just not sure if the node is not working on nested links or the IFC generated content. Which my above example contains both. The structural model I was trying to clash against is comprised of several links generated from IFCs.
This is an interesting problem - thanks for reporting it. So first off, Element.IntersectsElement node does support elements from linked files (per se) as you’ve rightly pointed out. Which raises the question then, why is it not working? Well, I’ve investigated and found the source of the problem, which points towards a major limitation within Revit (as opposed to a bug).
The problem is caused by the way Revit, and therefore the API, locates linked documents - it will always locate them in their Original Location (lets call this OL) relative to the file centre (XYZ 0,0,0) even if the link has been moved, rotated or mirrored.
Given that in 90-99.9% of cases, a linked document will be moved to align with your own model, what this means is, that while elements from a linked document may appear visually to be aligned with the live elements in the active document as you’ve observed, in the API context, they are actually positioned back at the OL, so the intersections fail, and this is why you are seeing zero results from the Element.IntersectsElement.
The smaller the move (or if there is no move at all), the more disguised the problem then, which is why its easy to mistake the node as working as @john_pierson has assumed with the Rhythm node - it too does not support elements from linked documents for the same reason. “Testing leads to failure, and failure leads to understanding” - useful words of wisdom from Burt Ruten!
To illustrate the limitation, here is a test file with a few walls with the OL shown in blue:
When the document is linked into a new file relative to some live ducts in the active document, its default position (Origin-to-origin) is the position the API always uses to locate its elements, as illustrated below. The linked elements bounding boxes are shown in blue - notice they don’t move regardless of what changes are made to the location of the link instance from which they derive. Hence, they ducts are in one Cartesian context, whereas the linked elements are in another even if they moved to the same context as the ducts, and that’s the cause of the problem:
What can you do then? Unfortunately not a lot: either wait for a fix or create a temp Revit file and bind all links! There is good news though, I’ve already developed a workaround which is currently going through testing and will be published to BimorphNodes in due course (there are lots of tests to perform, and its not trivial). Here’s a sneak peak testing the algorithm I’ve developed which locates the position of linked elements regardless of translation or transformation.
In answer to your other question re IFC, so long as the IFC content has been imported as Revit elements, then the Element.IntersectsElement node will work. If you want to double-check, use the Element.IsElementSupported node.
We can see here that the link is rotated and the bounding box is reporting it as such.
If we go ahead and use some of the logic pointed out, we can simply copy the elements into the file and toss them out when we are done. Luckily with spring nodes this just requires unplugging the node (demonstrated in GIF below).
All instance objects in revit have a transform (except groups, because they don’t inherit the “Autodesk.Revit.DB.Instance” class). Why do you think that the linked instance collector has a transfrom output? Just use it dude
I will second what @Dimitar_Venkov just said. RevitLinkInstance has a method on it GetTotalTransform that will get you what you need. Then you just have to transform the elements into host coordinate system, and you can intersect away.
Transforms are a small part of the solution, but not the solution:
For starters Revit link Transforms are not available (the node inputs are elements) - that forms the first complication in context to the OP
Bounding boxes are an important part of the optimisation process and need to be transformed to each link to collect any elements input otherwise the same problem will arise (if there are two links for example in two different locations, the element collection will need to transformed/performed twice before intersection testing is performed)
Due to the above, linked elements would have to be temporarily copied into the document otherwise the problem reported in the OP would arise
Live element > link element, link element > live element, link element > link element all need separate rules and are further complicated once multiple links or multiple links of the same name are considered
There seems to be no way to get the link object from an element. It can be indirectly achieved however (doc name) but there can be multiples of the same link, so filtering links by name yields multiple results and the challenge here is to minimise the impacts on efficiency while identifying which link the element has derived from
Element collection is fraught with problems as all documents can have different transforms/can’t easily be located (if from a link which appears multiple times) which results in incorrect elements being picked up even after the first hurdle (transformation) is solved.
It’s a complex problem once understood - the transformations therefore are indeed the simplest step!
That would introduce more problems unfortunately. It creates a new problem where incorrect link instances can be input by the user who is also unlikely to be aware of why they need to provide the input in the first place, and it fails to support (or resolve the problem of) multiple or duplicate link instances which are the norm (OP for example), rather than the exception.
Plus it can’t be made an optional input for obvious reasons, which means if no link instances are involved, the user is left confused.
@jmmiller Quick update: the limitation posed by elements from linked models which you reported is now fixed in BimorphNodes v2.2. I found the link element limitation affects any nodes which rely on Revit Quick or Slow filters, so I’ve also added new functionality to the BoundingBox and Element.IntersectsSolid node too, so now any element from a RevitLinkInstance is handled. It’ll be released early January!
The issue is now fixed in BimorphNodes v2.2 using the new LinkElement nodes. This new class forms an essentail part of the infrastructure than enables the Element.IntersectsElement to provide holistic support of linked elements, even if they have been transformed or translated. It does mean however that support of any packages or custom code that retrieves elements from linked Revit models has been dropped. The reasons for doing so are explained in the BimorphNodes v2.2 article, which also explains whats new in v2.2.
Whats more, the inputs and outputs of the Element.IntersectsElement node hasn’t changed - simply input LinkElements and it will do all the heaving lifting for you. An example graph showing the utilisation of LinkElements:
Or you haven no clashes?
