A surprising new aspect of Revit's built-in solid intersection algorithms and a ten-year vision for online assets:
A fundamental new aspect of the built-in Revit intersection calculation algorithm was unearthed thanks to the Revit API discussion forum thread on solid intersection questions:
Question: I have a couple of questions about how Revit handles solid intersection for Interference Check, ElementIntersectsElement, ElementIntersectsSolid and BooleanOperationUtilities.
I've put together an extremely simple model consisting of 4 instances of a Specialty Equipment family that consists only of a cylindrical extrusion. Among these 4, some of them intersect shallowly on their cylindrical faces. The exact setup can be seen here, with element IDs to refer to the elements more clearly:
As you can see, we should find the following intersections:
However, when we run Interference Check, some of those intersections are not found.
I've thrown together a small test app which separately:
ElementIntersectsElement filterElementIntersectsSolid filterBooleanOperationUtils and checks them for positive volume.Code can be found in the attached InterferenceCheckIssue.zip along with higher resolution screenshots and the model on which the code was run in Revit 2018 and Revit 2020. The issue occurs in both.
All three approaches give the same result, only finding intersections between the elements highlighted by the Interference check.
So, I suppose my questions would be:
Answer: I logged the issue REVIT-152087 [incomplete intersection results] with our development team for this on your behalf, and they explain:
The functions you mentioned probably all use the same underlying code to intersect solids, or to determine if two solids intersect. One of its limitations is that it does not detect intersections between two faces that lie entirely in the interiors of the faces. It's likely that in the cases when the intersection between two cylinders is not detected, the edges of each cylinder do not intersect any faces of the other cylinder. Note that in Revit, a solid cylinder's boundary will (typically) have two semi-cylindrical faces.
A workaround in such cases is to rotate one or both objects to ensure that edges of one solid intersect faces of the other solid, though in a complex case involving many solids that may not always be possible.
It's probably not hard to make the interference-checking code handle some special cases of this sort, such as two cylinders or two spheres, but the cost/benefit ratio of enhancing Boolean operations to handle such cases is probably too high to make it worthwhile, as such cases don't arise very often in practice.
This issue has in fact been raised in the past and is covered by several existing development tickets, e.g., REVIT-32243 and the items it links to, including the old "master" SPR #123893 for this issue and the items it links to.
It was a known limitation from the start.
Since 2001, about a dozen such items have been filed.
There is usually a fairly simple workaround, so up until now, this issue, though annoying, hasn't been a serious obstacle.
Response: Thank you so much for your extensive feedback. We had suspected in-house that it was something along these lines causing the inconsistency. Especially the references to old discussions of the issue are very helpful.
To summarize and clarify, the root of the issue/known limitation is that solid interference is based on detection of edge -> face intersections, rather than face -> face intersections, right? So, I need at least one "Edge" of solid 1's faces to penetrate one or more faces of solid 2, or vice versa, right?
One workaround we've come up with for our purely cylindrical/revolved families is calculating the path of the solid and generating an approximated planar-Face-based solid to perform interference checks with.
Of course, the biggest remaining issue then would appear when we're trying to run interference checks between things which have cylindrical components, but are not detected by our algorithm as "fully-cylindrical-things." (i.e. a cube/prism with a cylinder poking off of it in some direction) While I don't know that we can write these off full-stop, it is my suspicion that these are a semi-rare occurrence.
In any case, this at least satisfies my curiosity in what was going on behind the scenes.
Answer: Yes, I believe your description of the situation matches what the development team mean.
In my fantasy, I would have thought that an easier workaround than any of the ones suggested so far would be to add four model lines per cylinder to the Revit model, or even just add four non-database line segments in-memory for each cylinder to the cylinder-cylinder intersection cases, one along each of each cylinder's four cross-section quadrants, and include intersection checks between the four quadrant lines along one cylinder with the other cylinder's surface. Would that catch all possible cases?
Another suggestion, from Revitalizer: you could create some lines alongside a pipe's outer hull, e.g. 4, 8 or 12 lines, depending on accuracy needed.
For each of these lines (plus the pipe centre line), use a ReferenceIntersector to find intersecting pipes.
Make sure the View3D used for the ReferenceIntersector displays the pipe's geometry in a proper way.
Response: I think where we've settled with this in the office is using Curve objects constructed from CylindricalFace and RevolvedFace geometric information and checking their intersection with candidate solids.
Because this is a fairly processing-heavy task, we're using it as a "last resort" after checking that the elements in question have certain parameter information, lie within (or intersecting) one another's bounding boxes and are not already flagged by the ElementIntersectsSolidFilter before reaching this point. This way, we narrow ourselves down to an extremely small subset of possible intersections to check.
Thanks again for all your help in this matter.
A colleague pointed out a thought-provoking white paper by MovieLabs and its member studios (Paramount Pictures, Sony Pictures Entertainment, Universal Studios, Walt Disney Pictures and Television and Warner Bros. Entertainment) laying out a bold 10-year vision for the future of media creation technology, for filmmaking during the next 10 years, with a call to action for the industry to collaborate by appropriate means to achieve shared goals and continue to empower future storytellers and the creative community. They describe future technological advances that will enable seismic changes in media workflows with one objective in mind – to empower storytellers to tell more amazing stories while delivering at a speed and efficiency not possible today.
Many of the necessary shifts articulated in this paper are quite closely aligned with strategic intents of Autodesk, the Forge team, the AEC and other collaborative industries in general.
Here are the ten foundational principles formulated in this document:
If this sounds interesting to you, go ahead, download and take a look at the white paper when you have a chance: