Bimorph Nodes V2.2 Adds Holistic Support For Linked Element Clash Detection With New Link-Element Nodes

We are delighted to announce the release of BimorphNodes v2.2, which is now available for download via the Dynamo Package Manager.

BimorphNodes v2.2 introduces the new LinkElement class nodes to Dynamo which are purpose-built for retrieving elements from linked Revit models. While this functionality has existed for some time in a number of other packages, what makes LinkElements unique are the range of additional properties and features they implement that solve a major limitation in the Revit API (and therefore Dynamo) concerning the location of linked elements within their host file.

The other significant update in v2.2, also related to this issue, is the addition of holistic support for linked element clash detection using any of the Bimorph Element and BoundingBox nodes. LinkElements serve a vital role in enabling this functionality, resulting in a range of nodes that are no longer impeded by the problems that arise from limitations in the Revit API.

BimorphNodes v2.2 overview:

  • New LinkElement class nodes for rapid interop with elements from linked Revit models
  • Element.IntersectsElement, Element.IntersectsSolid, BoundingBox.GetElementsInside and BoundingBox.GetElementsIntersect nodes now provide holistic support for linked elements
  • Clash detection codebase micro-optimised, resulting in +15% performance increase
  • CAD.CurveFromCADLayers refactored with improved support for view-specific CAD links
  • Curve.RemoveDuplicates refactored resulting in +80% performance increase
  • Built on the Revit 2017 API (Revit 2015 no longer supported)
  • Efficiency enhancements and general stability improvements

New Link-Element Class Nodes

The new LinkElement nodes include a range of methods and properties for retrieving and interacting with Elements from a linked Revit model (a Link Instance). What makes LinkElements unique are the way they locate the linked element in the host file. This is significant as the Revit API has a limitation which restricts linked elements to their external files origin-to-origin location, regardless of any transformations made to them in the host file. LinkElements have been purpose-built to solve this limitation by performing operations, such as geometry extraction, at the linked elements host location.

LinkElement instances can be created using the LinkElement.OfCategory node:

Properties and metadata attached to the LinkElement instance can be accessed using the LinkElement property nodes. The Solids, Faces, Location and BoundingBox nodes return the respective geometry at its host location by default:

There are also property nodes to access its associated Link Instance id, total transform and the embedded Dynamo Revit Element:

Link-Elements Solve The Revit Api Linked Element Transform Limitation

The linked element transform limitation manifests only in the Revit API context, which subsequently exposes a number of BimorphNodes to the problem. As mentioned, this limitation causes linked elements to default to their external files origin-to-origin position, even if the elements Link Instance has been transformed in the host document. The Revit projects most at risk of this problem are those where transformations have been applied to the Link Instance for coordination purposes, which is likely if Shared Coordinates are in use or if linked models have been manually moved to align with the main building model.

The problem is most pronounced when calling Revit API methods on a linked element where its relative location in the host file is required to yield a result. For example, the Revit API ElementQuickFilter and ElementSlowFilter class methods – which are used for clash detection in the BimorphNodes BoundingBox and Element nodes – produce erroneous results if element A vs B includes any linked elements which have been transformed. This is especially confusing to users since any linked Revit models which are moved to visually align with other links or live elements in the host file, are always positioned back at their respective origin-to-origin locations in the API context, causing the clash results to fail unexpectedly.

The following example illustrates the problem, showing the position of bounding boxes created in the API context from linked wall elements while its Link Instance is transformed. One would expect the bounding boxes to be drawn where the walls are positioned in the host model, but the Revit API limits them to the links origin-to-origin location:

LinkElements on the other-hand solve the problem by handling linked elements at their host location (where you see it in Revit), and this new functionality forms the basis for enabling holistic linked element support in the BimorphNodes BoundingBox and Element nodes:

Learn More About BimorphNodes V2.2 and the Revit API Limitation

Want to learn more? Visit the official BimorphNodes article to gain further insights into:

  • The Revit API limitation imposed on linked elements
  • How BimorphNodes V2.2 solves these limitations
  • How LinkElements serve a vital role in enabling holistic linked element support for clash detection
  • The new linked element clash detection workflows that are made possible using LinkElements with Bimorph Element.IntersectsElement and Element.IntersectsSolid nodes

The article includes extra video content and comprehensive details all of the new functionality that’s been added to v2.2:

BimorphNodes v2.2 Official Article