Hello.
Is there any way to access Revit’s internal intersection checker in the Revit API?
I cannot find it in the RevitAPIdocs.
I want to run it automatically with a certain ruleset against each link in the project and export the results to html files in a folder.
BimorphNodes Element.IntersectsElement or Element.IntersectsSolid nodes do, otherwise if you want to write your own implementation then you need to use the ElementIntersectsElementFilter or ElementIntersectsSolidsFilter classes.
Also, if you are dealing with links, then you should read this article covering some of the complexities of passing linked elements into the above filters which you need to consider.
Thank you for your answer Thomas!
I am thinking of running the internal interference check like shown below, with checkoffs for categories so that I get the html output files in the same way as if i would do it manually, one for each link with different rulesets for each.
Do you think that is achievable? If not, will I be able to achieve a report like this using BimorphNodes? It will be used on large projects with tons of elements.
In this particular project there are about 1300 rooms with both offices and technical working areas.
As per today we run the interference check manually, which is kind of quick to run, and parse the html documents through a graph that logs collisions, fixed collisions, and visualizes where the collisions are in the model.
I want to automate the checker part of this!
Does your nodes have the same/better efficiency as running the internal interference checker?
You are welcome. To begin with, the clash detective algorithm developed for BimorphNodes Element.Intersects nodes offers many advantages over Revit’s Interference Checker (IC):
Revit’s IC limits you to 1 Link Instance per clash test, whereas BimorphNodes clash detective algorithm supports an unlimited number of Link Instances (by virtue of the new LinkElement class)
IC doesn’t support linked element vs linked element clash detection, nor does it allow clash tests to be performed between elements from the same Link Instance, whereas BimorphNodes fully supports this type of clash test, making it ideal for projects with many link instances or general BIM coordination workflows directly in Revit
IC requires at least 1 live element in the active model before it can be used; Bimorph’s clash detective algorithm has no such restriction
The html report is very simple to recreate and you could easily do this yourself using the output from the Element.IntersectsElement node and extracting the parameter data you need. However, there wouldn’t be much need to round-trip a html report since you will have all the data you need within Dynamo.
In respect to performance, BimorphNodes is about 3x faster than the IC, however its not a fair comparison as IC builds a report and displays it in a UI dialog which will require additional time to render. Nevertheless, BimorphNodes clash algorithm its micro-optimised, making it a lot faster, despite being far more versatile (which typically impacts performance).
If your projects are huge with millions of elements, BimorphNodes is ideally suited for these types of projects -
I’ve performed tests on massive datasets with over 65,000,000 possible clashes and it took about 2.5 minutes to compute. If you structure your clash tests smartly, then there is no reason why you would need to take a ‘strategic coffee break’.
There have been some good examples posted on the forum of visualising and documenting clash tests using the Element.IntersectsElement node which you may want to look at before changing your existing workflow:
Colour overrides: Clash detection script to identify the clash and visualize it using overrides in view node
Clash reporting: Clash Detection
Starbucks stock just feel 5% on this news…
You have some great points here!
I guess i’ll look at changing the workflow we use today. It would indeed be much smoother to implement the clash detection into the same graph that documents the results.
Thanks for your help, and your brilliant nodes 
By the way, I love strategic coffee breaks 
@jacob.small I should have gone short (on their shares that is, not their coffee)!
@andre.abotnes Great, I hope it offers improvements to your workflow and thanks for the feedback 
Re strategic coffee breaks - the truth is, you’re now so efficient, you can take strategic holidays and no one will notice any difference in your productivity 
Out of curiosity, any love for Bimorph in Revit 2015? Extra coffee points if in Dynamo 0.9.2. It seems majority of our clients still use Revit 2015 and my office is trying to figure out the usefulness of Dynamo so we are still using 0.9.2 because they don’t want to manually update each computer. So for now when they ask me for a collision test script, it requires me to use Revit IC lest I be forced to run geometry intersection nodes on a hotel building.
Hi @kennyb6 its achievable but difficult to manage as it would involve creating multiple versions of BimorphNodes compiled on the older Revit and Dynamo APIs, then there would by refactoring or disabling of certain features which are not backwards compatible (so functionality between versions would not be guaranteed), plus lots of testing - basically, it would involve a lot of work unfortunately which is why 2015 and older versions of Dynamo are not supported. I have implemented some backwards compatibility for Revit 2016 and Dynamo 1.2, but its not ideal as it fragments the codebase.
Hello again!
I tried running a simple recreation of a ruleset for a clash control that we use for one of the links in a current project. With Springs linked instance collector, I found over 40k elements, but with Bimorphnodes’ equivalent node I got about half that. Does that have to do with the elements having geometry or not?
I tried running “Bimorph clash detection” side by side with Revits intersection checker, and Revits intersection checker was done in about 5 minutes, whilst the dynamo graph went for so long that I had to take a strategic coffee break… 
In fact, when I came back to the computer, it seems that dynamo had crashed.
Here is a picture of the graph:
Amount of elements selected from our model:
3533
Amount of elements selected from the linked model:
21863
If I’m not mistaken, this puts us slightly below 80M possible collisions?
This is a picture of the equivalent “ruleset” from the Revit Intersection Checker:
.
Am I doing something wrong?
There results of the element collection should be identical, and only vary slightly as the Spring node returns the total transform of the Link Instance. If its more than double then there might be a bug in the code which wont take much to fix if confirmed - can you provide a test model which consistently reproduces the difference?
The next issue…well, I honestly thought I’d toppled the Starbucks empire! At first glance your graph seems fine so it will require more in-depth testing, ideally using your model again. Are you able to share it? DM me if its confidential information.
Thanks for providing the files. The problem was caused by duct insulation with zero volume, which subsequently have invalid bounding boxes. As the LinkElement constructor requires valid bounding boxes for instantiation, the category element collection fails. Only successful category collections return elements, which explains why you might have seen different results in comparison to the Spring node (it wont be affected by this problem as it doesn’t need to extract bounding boxes nor instantiate new elements).
You can even see the same exception by collecting the linked Duct Insulation elements (using Springs for example), then use the OOTB Element.BoundingBox node on the problem element:
To solve it, I’ve applied an update to the LinkElement class so it can handle null bounding boxes and you can get these updates by upgrading to BimorphNodes v2.2.3, now available on the Dynamo Package Manager. Incidentally this update fixes a broader issue with the LinkElement.OfCategory node that caused it fail when collecting valid elements with no bounding box, such as views.
In v2.2.3 the node is working consistently and returning the same number of elements (40k elements in your case) as the Spring node.
The crashing problem is highly likely to be related to this issue - solving X solves Y. All I’ve done is add some exception handling to the Element.IntersectsElement node so it bypasses any LinkElements with a null bounding box (as there’s nothing to clash). The change has had no detrimental effect on the clash result, and I’ve verified this against Revit’s IC to ensure the results are identical, and they are (indicates the IC must also bypass invalid elements).
Subsequently, I’m not experiencing any crashes performing the same clash test with your model and graph (138,148,664 possible clashes). The clash test executes reliably and might even give you time to get a coffee, but only if the coffee machine is on your desk:
Revit IC Tool: 3min 23.04s
BimorphNodes: 2min 23.6s (30% faster)
This is incredible!
Looks like I might be able get a coffee as well, as long as I run faster than Usain Bolt!
Thank you so much for looking into this! I will try the updated package tomorrow, monday!
This is exciting stuff! 
Again, thank you for looking into this!
Dear Thomas,
I see that you’re one of the developer of elements intersect element.
I have learned so much about clashing workflows but most of them uses brute force. The idea of clashing with near objects only is the same as my idea of cutting the time.
Basically I tried it all I guess, from navis clash, IC, geometry does intersect, and your node. However I would like to request one or two things may be missing with your node. That is the clash point. Yeah navis and IC has points we can leverage with. Also if I use geometry intersect and find the center of mass of the intersect object only then I can also produce that point.
With your optimised node plus the point of intersection, it can really now par with navis clash detective.
Second is the element in another set that it clashed with. Because now the output is only the elements in one of the list that have intersection.
Or is it possible with your nodes plus ootb and I just can’t think of it? Please guide me. Thank you.
Hi @jeff.mercado thanks for the feedback its great to hear. If you watch the video below it shows how you can use simple data matching techniques to establish the element from set A that corresponds to the output clash results - basically, the index of the element in Set A corresponds to the same index of the sublist in the output:
Implementing clash results as points is problematic since not all clash tests can be represented as points; adding this functionality would therefore give rise to unpredictable or inconsistent behaviour from the node - something all good developers avoid. The advantage then of outputting the raw results is it provides you with the ability to determine how to represent your clash results (volumetrically, by points, colour coding, etc, etc) to best suit your workflow, rather than leading everyone down one route which may not be appropriate for their requirements.
Here is a workflow which shows how you can obtain clash points using the clash result:
Thank you for your response. You answered what I asked for.
I think my problem was caused by running bimorph in revit 2015 and dynamo 1.2. In comment above you said that there might be some incompatibility. When I tried to run Bimorph yesterday, the output is a flattened and cleaned list of all elements from list A with only the clashes. Thats why I said maybe something can be improved. Based on your tutorials it’s (elements intersect elements) output is the one I was looking and expecting. And the filter by bool and solid intersection node after the EIE is the same with my Workflow using geometry intersect. On Monday in the office I will update you if the revit version is my real problem.
Thank you very much. Your node is really wonderful and faster than brute force clash method.
No problem - insider info, I’m looking at techniques for representing clashes as points and analytical meshes post-processing. Not promising anything until I’ve investigated, but providing users with the ability to rapidly highlight clash results either as points, volumes or analytical meshes is on the new feature request’s for BimorphNodes v3.0. Possibly Q4 or Q1 2019 release depending on my resourcing, but if there’s any features from your experience using Navisworks which you’d like to see in BimorphNodes to completely replace your workflow then detail them here and if its viable (and sensible) then I’ll look to implement it.
@Thomas_Mahon, that sounds promising! Will some kind of ruleset managing be implemented?
For instance margins of space? I.e a cable tray needs spare space above it for cables that aren’t in the model. Is it possible?
André
I would like to share with you my navis Workflow. Actually I finished the dynamo script for a Navis->Excel->Revit but it has so many clutters and unorganised. Is it ok if i get your email? Maybe I can help you with some insights. Why I use point as representation is because my script creates 3d views of the clashes.
My reference is with dynaworks and http://au.autodesk.com/au-online/classes-on-demand/class-catalog/2016/revit/cs21553#chapter=0
But I created my own take of the problem. Thanks.
Hi @andre.abotnes its a good question, and really it depends on how the interference checker in Revit can be extended to allow for ruleset management. One of the most complicated features to add would be what you are asking for - clearance checking; I’m well aware of how important this is in the realm of 3D coordination. In theory its possible, by getting the underlying geometry from the element and scaling it for example, but that’s easier said than done, not to mention the significant impacts it would have on performance. I plan to explore it nevertheless, and will announce any headway should the endeavour prove to be successful.
@jeff.mercado yes I am very interested to hear how you work and gain some insights - DM me and we can take it from there.
