Dynamo Hierarchy: Rhythm>Revit>Elements>View3D>View3D.SetSectionBox
Description:
This node will set the given 3D view’s section box given a bounding box.
Inputs:
view3D: Element
bBox : BoundingBox
Outputs:
success: Element
failed : Element
Dynamo Hierarchy: Rhythm>Revit>Elements>View>View.SetElementProjectionLineweight
Description:
This node will override the given element’s lineweight in the given view. Useful for annotation.
Inputs:
view: View
element : Element
lineweight: int
Outputs:
element: Element
Dynamo Hierarchy: Rhythm>Revit>Elements>View>View.GetFilterVisibility
Description:
This node will supply the visibility of the given filter in the given view.
Inputs:
view: View
viewFilter : View Filter
Outputs:
bool: Boolean
Dynamo Hierarchy: Rhythm>Revit>Elements>View>View.GetCropRegionElement
Description:
This node will obtain the crop region element from the given view.
Inputs:
view: View
Outputs:
cropRegionElement: UnknownElement
BimorphNodes v2.1 has been released on the Dynamo Package Manager and it now includes ultra-efficient clash detection and intersection-based nodes!
We’ve developed a new range of geometry intersection nodes that are unmatched in performance and add entirely new functionality to Dynamo, while the new clash detection nodes achieve unparalleled speed increases, reducing processing times by up to 99.95% compared to current methods, opening-up entirely new interference workflows for Dynamo BIM.
BimorphNodes v2.1 is now 2018.1 compatible, every node has been upgraded, and the entire package has been ported to C# to support the future development roadmap.
A primary focus for our latest update has been to provide a range of new nodes which deal with common and problematic workflows encountered when using Dynamo: geometry intersections and Revit element intersections. Whether its clash detection, containment testing or procedural modelling, performing intersections are invaluable, especially for ‘spatial awareness’ problems. However, they are also crippling from a performance standpoint and therein lies the greatest challenge of all; how to make intersection processes efficient.
Currently, many Dynamo workflows involving geometry intersections rely on the OOTB Geometry.IntersectAll or Geometry.DoesIntersect nodes. The advantage of these nodes are their versatility, but it comes at the cost of performance. Geometry.IntersectAll performance issues are compounded further whenever Revit elements are involved, as the elements can’t be used directly. Rather, their geometry must be extracted first using Element.Solid node which adds an even greater burden to an already computationally expensive process. Both nodes are inherently inefficient, making any workflow that depends on them impractical for anything but small projects.
Given that the majority of projects that use Dynamo are predominately large-scale, it raises the question: why can’t Revit elements be input directly to bypass the burden of solid extraction, then optimise the intersection process thereafter?
BimorphNodes v2.1 answers that question; the new range of clash and intersection-based nodes offer ultra-efficient performance when compared to the same process using Geometry.IntersectAll and Element.Solid nodes. These new nodes will largely eliminate their use, and look set to mirror the impact @ListLevel’s introduction had on the now, largely redundant, List.Map node.
As well as adding powerful new nodes to the package, we have made major changes overall which improve stability, usability and efficiency:
Element.IntersectsElement
The first of the new clash-detection nodes. It’s now possible to perform ultra-efficient clash-detection in Dynamo using the Element.IntersectsElement node. It utilises a purpose-built Revit API method to perform the intersection test (which itself is optimised) coupled with an optimisation algorithm we’ve developed to filter surrounding elements before performing each clash test, which minimises redundancy. The technique results in a massive performance increase, with up to a 99.95% reduction in overall processing time compared to the same process using Geometry.IntersectAll or Geometry.DoesIntersect + Element.Solid.
The output Elements are structured into sublists to support downstream workflows. Deciphering the output data structure is simple: any elements from Set B that intersect an element in Set A are stored in a sublist (the ‘clash result’). If there are no intersections, an empty sublist is returned to maintain data structure consistency.
The node also includes intelligence which prevents self-intersection if an element is found in both element Set A and B, eliminating false-flags. It means if you only have one element Set but still want the clash results (for example, clashing all pipes against all other pipes), the node can support this workflow without any negative impacts.
Element.IntersectsElement processing speed versus the comparable workflow using OOTB Geometry.DoesIntersect + Element.Solid :
Element.IntersectsSolid
The second of the new clash-detection nodes provides more flexibility and interop with Dynamo Solids. It utilises a purpose-built Revit API method to perform the intersection test which drastically improves efficiency, plus it’s built on the same infrastructure as the Element.IntersectsElement node, meaning its optimised (minimises redundant tests by filtering surrounding elements per clash) and the same logic applies with the output data structure.
Since the use of Dynamo’s Geometry.IntersectAll and Geometry.DoesIntersect method is avoided entirely, opting for a purpose-built method from the Revit API, there are none of the performance bottlenecks typically encountered with these nodes, resulting in a node which yields lightning-fast results despite the fact solid intersections are still being computed.
Element.IntersectsSolid comes into its own if an element isn’t compatible with the Element.IntersectsElement node (see below to learn more) such as Rooms, or for performing clash tests in situations where there is no reference geometry – for example, testing if door swings clash with another element. In this scenario, Dynamo Cylinder extrusions could be created at each door to represent the swing zone, then Element.IntersectsSolid can be used to perform the clash test. The possibilities are endless!
In some cases, solids can fail the intersection process due limitations with certain geometries processed by the Revit API Shape Builder. The node has been designed to handle these failures by returning the indexes of any problem solids to the exceptions[] output, enabling them to be bypassed, or filtered and rerouted to alternative methods.
Element.IntersectsSolid processing speed versus the comparable workflow using OOTB Geometry.DoesIntersect + Element.Solid :
Element.IsCategorySupported
Element.IsElementSupported
Not all Revit elements or Categories are supported by the two Element.Intersects nodes – either for obvious reasons, or due to limitations in the API – and it’s difficult to tell which since the output from the two Element.Intersects nodes defaults to an empty list where intersections fail. These two nodes provide a means to check if the elements are supported, outputting true or false accordingly. If the element is not supported (such as Rooms), a good alternative is to extract its solid volume and use Element.IntersectsSolid.
Curve.IntersectAll
Intersecting a set of curves to yield a single array of intersection points with no duplicates has, to-date, involved using OOTB Geometry.IntersectAll set to cross-product lacing with Point.PruneDuplicates as shown below:
However, the workflow suffers from enormous redundancy primarily due to its reliance upon two computationally expensive nodes. Plus, cross-product lacing is required to perform the brute-force intersection test (all curves intersected against all other curves) adding more profligacy to an already inefficient process. It means that even a small number of curves can take an inordinate amount of time process, and the workflow itself is essentially crippled from the outset.
With the release of BimorphNodes v2.1, the entire workflow is replaced by just one node:
Curve.IntersectAll adds new functionality to Dynamo; the node is ultra-efficient, implementing a purpose-built curve intersection method from the Revit API which is further optimised by our own algorithms to eliminate redundant tests and maximise efficiency. The result is a node which can calculate intersection points infinitely quicker than the same workflow using Geometry.IntersectAll and Point.PruneDuplicates. Here are some performance comparisons:
Curve.SolidIntersection
Curve.SolidIntersection node adds entirely new functionality to Dynamo – now solids can be used to intersect or trim curves. Prior to BimorphNodes v2.1 such concepts were not possible, yet this functionality has significant value for a myriad of workflows; from volumetric containment testing to procedural modelling.
The node can output curve segments that either intersect the input solid (default behaviour), or the result can be inverted using the invert switch, which outputs curve segments outside the solid. Inverting essentially creates 2 nodes in 1: Curve.SolidIntersection and a TrimBySolid node!
In some cases, curves can fail the intersection process due to tolerance limitations within the Revit API. The node has been designed to handle these failures by returning the indexes of any problem curves to the exceptions[] output, enabling them to be filtered and rerouted to alternative methods.
BoundingBox.GetElementsInside
BoundingBox.GetElementsIntersect
Both nodes filter and return Revit elements either inside or intersecting a bounding box. These nodes expose Revits ElementQuickFilter class, which operate only on the ElementRecord (a low-memory class), making them ideal for rapid element containment testing and collection. Note that the results are – by design – coarse, as the input element Outlines (BoundingBoxes) are used to determine the result, not the geometry. QuickFilters therefore, should be used as a means of optimisation prior to performing more complex, time-consuming processes, such as geometry intersections.
For example, these nodes can be used to optimise an interference checking workflow by collecting only elements within the proximity of another element. The result will be a far more focused collection of elements, making any subsequent geometry or element interference process significantly more efficient as redundant interference tests will be largely eliminated.
The optional tolerance input can be used to collect elements extending from the BoundingBox by the distance input. Use positive values to increase the BoundingBox zone, or negative values to decrease the zone. It uses your active document units (mm, cm, m etc) and converts them to Revit internal units dynamically.
Firstly, there’s a new node in the BimorphNodes CAD class:
CAD.SymbolicCurvesFormCADLayers
This opens-up new workflows for automated Family creation, enabling users to rapidly convert curves via layer names to symbolic lines, without needing to explode the import. Since its built on the same infrastructure as the other CurveFromCADLayer nodes, line styles can also be mapped during conversion to streamline the entire process.
Next, all the nodes have been improved, providing greater efficiency, better feedback to users if exceptions arise, and bug fixing, with some of the most popular BimorphNodes seeing major feature updates and stability enhancements. Here are a few highlights:
Sheet.Duplicate
New Features:
Fixes:
Sheet.FromSchedule
New Features:
Fixes:
Schedule.GetTableData
Schedule.GetTableDataColumn
Schedule.GetTableDataRow
New Features:
Fixes:
CAD.CurveFromCADLayers
CAD.DetailCurvesFromCADLayers
New Features:
Fixes:
If you are upgrading from an older version of BimorphNodes, continue reading, otherwise you skip this part.
Porting BimorphNodes v2.1 entirely to C# from Python has resulted in breaking changes to most nodes as their GUIDs cant be preserved. If you are upgrading and use older BimorphNodes in your graphs, they will need to manually replaced with the v2.1 versions, so please plan your upgrade strategy carefully to avoid disruption. To aid with the transition, the table below explains what has changed so you can check how the upgrade may affect you:
Why Make Breaking Changes?
Significant changes have been made to BimorphNodes v2.1 for the following reasons:
Upgrading to BimorphNodes v2.1 however, is well worth it:
Don’t forget to check out our BimorphNodes content pages and YouTube channel for user guides and extra content. New video content will be added in due course; be sure to subscribe to get notifications:
BimorphNodes Dictionary: BimorphNodes
YouTube Channel: YouTube
Finally, here is the full library of BimorphNodes v2.1:
INPUTS
importInstance : ImportInstance
layerNames : string[] (optional)
createModelLines : bool (optional)
lineStyleNames : string[] (optional)
OUTPUTS
Curves[][] : Curves[][] or ModelLines[][]
layerNameKeys[] : string[]
DESCRIPTION
Convert curves from a CAD Link or Import to Dynamo curves or Revit Model Lines using the file layer names as a filter.
Layer names can be input to filter and convert only curves on those layers. Curves are output in sublists based on their layer name and mapped to the Lines Line Style to prevent unwanted CAD styles from entering your Revit project. Alternatively, Line Style names can be input to map each sublist to that style during conversion. To convert all layers, leave the layerName input unconnected. Input layerNames and LineStyleNames are case-sensitive.
The node is optimised to convert curve-types that typically fail when using Dynamo’s Element.Curves node or Revit’s Explode tool for enhanced performance. The node also circumvents the 10000 element limit set by Revit for greater workflow flexibility.
MORE INFO
Visit Bimorph Nodes for more information and downloadable example graphs
USER GUIDE
Original post at: Space-Room coordination
The following workflow uses custom nodes from the packages: “SpringNodes”, “Archi-Lab”, “SteamNodes” and “MEPover”.
There are a few things to consider when managing your spaces:
A: Make sure the levels between the host model and the linked model are aligned;
B: Make sure the levels share the same computation height;
C: Create and coordinate spaces and rooms;
D: Set the limit offset of the spaces.
A. Aligning levels
The first one is easy as this is usually done when setting up your model. I take it everyone knows how to use the copy/monitor function, so let’s skip this step.
B. Set computation heights
If you only have a few levels in your project it is no problem: just manually check the computation height of the linked levels and the host levels and set the same computation height. However, if there are a lot of levels, Dynamo can come in handy. Here’s a simple workflow for setting the level’s computation height:
C. Space creation and coordination
This is the hardest part. There is no single right way to manage the coordination between your spaces and the rooms from the linked model. If you are not in the same office as the architect it’s almost impossible to keep track of the changes in the linked model. It would mean checking every space that no longer has a matching room number and looking for that room’s new location or it could also have been deleted altogether.
I therefore put some thought into creating a workflow that would work for any situation, regardless of the changes to the rooms. The only prerequisite for this to work well is that every room has a unique room number (sadly I still run into a lot of architectural models with duplicate room numbers, even though Revit gives explicit warnings stating that this is actually a bad idea…).
let’s assume that every space has the same number as the room it is associated with. Now whenever you load a new architetural model, the spaces will retain their space numbers (basically the state of the old architectural model). All you need to do is find the difference between the new rooms and the existing spaces. There’s basically three options to choose from:
1: A room number has been deleted
2: A room number still exists in the model (and might have moved)
3: A room number is new
To gather the information above we can use a really useful data structure known as a ‘Set’.
Sets are a collection of unique items upon which you can perform some functions you can’t do as efficiently with lists. Luckily Dynamo has included a few nodes for working with sets. There are 2 important methods that can be used with sets: ‘SetDifference’ and ‘SetIntersection’. Explaining these is best done through an example:
As you can see, this way it’s possible to find out exactly what we are looking for. Now let’s have a look at the next challenge: associating room/space numbers with actual rooms and spaces. We can achieve this by using a dictionary in which the keys are the space/room numbers and the values are the actual spaces/rooms. The output of the dictionaries will be the data to use for creating, managing or deleting the current spaces. Here is the result (with explanation):
After this make sure that the new space numbers change to match the associated room numbers. After that you can repeat this entire workflow for every new linked model update you receive.
INPUTS
importInstance : ImportInstance
name : string
projectionWeight : int
Color : Color
OUTPUTS
report : string
DESCRIPTION
Set the weight and colour of layers in a CAD Link or Import (its Revit Object Styles). Enter the required layers as strings – note that layer names are case-sensitive.
The node includes built-in logic in situations where lineStylesWeight or lineStylesColour lists are shorter (contain less items) than the layerNames list; in these situations, the node automatically defaults to longest lacing to to map attributes to every layer input.
MORE INFO
Visit Bimorph Nodes for more information and downloadable example graphs
USER GUIDE
INPUTS
filePath : string[] (optional)
refresh : bool
close : bool
OUTPUTS
report[][] : string[][]
CADLinks[] : ImportInstance[]
CADImports[] : ImportInstance[]
DESCRIPTION
Generates a report of all CAD links and imports in the active Revit document. The node provides detailed information on: instance name, link status, view specific, owner view id, workset name, file path and host level. Linked and Imported CAD links are output into lists to aid with CAD file management in Revit.
To report the active Revit document, leave the filePath input unconnected. To report any external Revit file or Family silently (without opening) simply input its file path using an out-of-the-box File Path node.
MORE INFO
Visit Bimorph Nodes for more information and downloadable example graphs
USER GUIDE
INPUTS
sheets : Sheet[]
run : bool
duplicateWithViews : bool
duplicateOption : int
suffix : string
prefix : string
OUTPUTS
report[] : string[]
Sheet[] : Sheet[]
DESCRIPTION
Duplicate selected Sheets with options to specify the duplication of placed Views and the method of duplication. The node will identify illegal characters in View names (such as {3D} for example) and clean them automatically to circumvent unexpected failures.
The algorithm which controls the duplicate View behaviour has been designed so that dependent Views are duplicated from a newly created parent View to maintain the existing View structure. The node will also check if the parent View exists on subsequent runs to handle situations where any of its other dependent Views need to be duplicated.
The report output provides a detailed log of any Sheets that fail to duplicate, any Views that fail to duplicate or cant be placed, and View names cleaned of illegal characters.
MORE INFO
Visit Bimorph Nodes for more information and downloadable example graphs
USER GUIDE
Dynamo Nodes 