Hi all,
I’m working in Revit 2024 with Dynamo 2.17, and I’m trying to create a node-only workflow (no Python) to automatically join intersecting walls and floors(or beams) across the entire model.
I’ve tested some basic setups, but performance is still an issue when working with large models. So I’m looking for an approach that detects where the clash is present and then joins only those elements.
(I also searched in the forum and in youtube but nothing …)
Does anyone have a working approach or example graph for this?
(i am still new to dynamo)
Thanks in advance!
Honestly i think node only you will struggle to run such a heavy check quickly. Bimorph nodes has some very fast clash check nodes, but behind the scenes it uses c# and revitapi, technically nodes I guess.
Note that joining in the way you are will lead to a lot of joins for nonclashing elements as revit often allows joins for close elements even if not overlapping.
2 Likes
I agree with Gavin - performance is going to stick here.
This is because it is bad Revit work. Beam N in the basement is being joined with wall M on the roof.
You could simplify the joins effort by reducing the selection (join by view) or limiting to only elements which intersect each other.
1 Like
Yes, I agree there is an efficiency issue. That’s why I’m looking for a way to join only intersecting elements, as you mentioned. For example, I’m thinking of running a clash detection and using the report to join the elements. The problem is that I’m still new to Dynamo, and turning my ideas into working graphs is quite difficult—sometimes I just can’t find the right nodes for the job
I know, but since I’m a beginner in Dynamo, it makes more sense to stick to nodes only for now, as I don’t know Python or any other programming languages. It would be a great help if you have any tips on how to do it using nodes only
You could simplify the joins effort by reducing the selection (join by view) or limiting to only elements which intersect each other.
piggyback on what jacob mentioned. i think if ur selection set is small, even with brute-force, runtime isn’t too much of a concern. u select them several times which will be slightly tedious, but it works fine.
For example, I’m thinking of running a clash detection and using the report to join the elements.
i remember the clash detection module in navisworks runs pretty fast. and u can locate the intersecting elements with it, export the metadata, import them into dynamo. all thats left to do is Element.JoinGeometry. (tbh, i don’t recall if one needs to leverage navisworks api to accomplish such a workflow. if it’s not out of the box. then i suppose u won’t find navisworks api easy to work with.)
1 Like
Unfortunately i dont have a script on hand.
Often with programming you can use dependency where needed, especially if beginning. Custom packages are there to help abstract more complex tasks that Dynamo may technically be able to achieve, but not as easily as written code.
The alternative is to clash the solid geometry of each floor against each wall and find which ones relate, then filter the lists down for each shape, finally joining each onto its list of found elements.
It will be slow/clunky vs using a package like bimorph as that one uses revitapi behind the scenes.
2 Likes
Not sure that’s the case. You may recall that there is a “Highlighted elements are joined but do not intersect” warning. This means that every attempted join which isn’t valid is a new warning element added to the model, which makes every subsequent action slower for all users in the entire model (all warnings are bad). These grow and are likely a big part of why the graph is slower than expected. NxN warnings with only 1/NxN joins is a lot of added overhead. Since each subsequent action includes the next join you can really take a performance hit by frontloading some failed joins. Note that this warning has always been part of Revit as far as I know, and it continues to persist in the latest version of 2026.
As such ‘brute force’ while possible, might not be advisable for even small selections.
My recommendation has always been to only join elements which should be joined (confirm they touch first).
OK this is one way you could go about this using OOTB nodes. I’m doing my best in the process to filter out unnecessary intersection checks as well as potential null/problematic solids - quite common in my experience.
Noting I am also filtering down to elements that are Structural and visible in the current view only. Geometry.DoesIntersect will likely be the bottleneck at larger scale, if not Solid.ByUnion.
When you’re ready, do check out BiMorph as it’s definitely the go for bigger tasks.
Join floors to walls.dyn (48.9 KB)
3 Likes
Great work as always @GavinCrump
1 Like
