Solid Intersection Questions

[dturk3CGKE]

Hello, 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:

• 1150420 and 1149599/1149413
• 1150613 and 1149599

However, when we run Interference Check, we get only the following result:

Additionally, I've thrown together a small test app which separately:

• tries to find intersections using the ElementIntersectsElement filter
• uses a bidirectional application of the ElementIntersectsSolid filter
• attempts to create intersections using BooleanOperationUtils and checks them for positive volume.

(code can be found in the attached .zip along with higher resolution screenshots and the model on which the code was run for 2018 and 2020 versions of Revit (I've seen the issue on both)) 

Using all 3 of these approaches, I get the same result, only finding intersections between the elements highlighted by the Interference check, as can be seen in the following screenshots from execution of my code:

So, I suppose my questions would be:

1. What causes this to happen? (As we've seen it on several different setups involving CylindricalFaces or RevolvedFaces)
2. What can be done to tackle this issue in a consistent and efficient manner?
3. Is there a better way to look for solid intersections than any of the approaches via the API than those I've attempted here?

Thanks,

Doug Turk

[jeremytammik]

Dear Doug,

Thank you for your report, clear description and reproducible case.

Sorry to hear about this.

I logged the issue REVIT-152087 [incomplete intersection results] with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

This issue is important to me. What can I do to help?

This issue needs to be assessed by our engineering team and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

• Impact on your application and/or your development.
• The number of users affected.
• The potential revenue impact to you.
• The potential revenue impact to Autodesk.
• Realistic timescale over which a fix would help you.
• In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

Best regards,

Jeremy

[dturk3CGKE]

Thank you for your quick response, Jeremy. To provide further insight as to how this affects our development, please see my responses below.

• Impact on your application and/or your development. This has substantial impact to our development for current and future feature development. We depend on the Revit solid geometry functions in a plethora of our utilities and this is a noticeable shortcoming of our applications by our current customers. 
• The number of users affected. Approximately 750 current customers are affected by this.
• The potential revenue impact to you. Unknown.
• The potential revenue impact to Autodesk. Unknown.
• Realistic timescale over which a fix would help you. The sooner the better for us as this affects current customer use cases.

Thank you again for your expedient response and please let me know if you need any additional information from our development team.

Thanks, 

Doug

[jeremytammik]

Dear Doug,

Thank you for your update and business case.

The development team replied to the ticket REVIT-152087 [incomplete intersection results] before I had a chance to add it.

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.

Best regards,

Jeremy

[jeremytammik]

I added your business case to the ticket and am now looking forward to further responses both from you and from them.

[jeremytammik]

Dear Doug,

The development team replied to your business case and further input to the ticket REVIT-152087 [incomplete intersection results] and explain further:

This issue 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 (on average, one every 1.5 years), and there's usually a fairly simple workaround, so up until now, this issue, though annoying, hasn't been a serious obstacle.

In order to help our team the product manager to understand the cost / benefit ratio for this issue, can you please provide some more details on how this affects your customers?

In particular:

• Does the particular case of partly intersecting cylinders affect all (or most of) the 750 customers?
• If the problem is limited to special cases like those involving partly intersecting cylinders, can you use a work-around?
• For instance, can you define the solid cylinders as extrusions of circles made of four quarter-circles rather than two semi-circles?
• Are there other cases that affect a large number of customers, or is the problem limited to partly intersecting cylinders?

Thank you very much in advance for you further feedback!

Best regards,

Jeremy

[dturk3CGKE]

Jeremy,

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 planarFace-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.

As far as the extent of customer impact, we'll have to do some internal discussion to establish those numbers and/or how likely they are to see/feel this issue and get back to you later in the week.

Thanks again for the timely, comprehensive response,

Doug Turk

[jeremytammik · Accepted solution]

Dear Doug,

Thank you for your response, appreciation, clear summary and understanding.

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?

Best regards,

Jeremy

[Revitalizer]

Hi,

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 (puls the pipe's 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.

Revitalizer

[jeremytammik]

Thank you Doug and Rudi for the discussion and suggestions.

I summarised them here for clarity and posterity:

https://thebuildingcoder.typepad.com/blog/2019/09/cylinder-intersection-and-vision-of-online-assets....

[dturk3CGKE]

Thanks for the further suggestions. 

We're going to work today on implementing some of these locally to evaluate their efficacy in our solution.

Thanks again,

Doug Turk

[jeremytammik]

Oh, and another recommendation from the development team, on a separate topic:

By the way, I noticed that the vertical cylinder in BAD_INTERSECT-STRIPPED-RVT2020.rvt (within InterferenceCheckIssue.zip) is not quite aligned with the coordinate axes (it's a family instance with a transform that's "misaligned" by slightly more than 0.1 degrees). If that's not intentional, it would be advisable to avoid such inaccuracies, though they are not the cause of the problem addressed by this ticket.

[dturk3CGKE]

Interesting! I hadn't noticed that about that family. I'll make sure to mention that to my team in case the content it was stripped down from is being used anywhere.

I think where we've settled with this in the office is using Curve objects constructed from CylindricalFace/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,

Doug Turk

[jeremytammik]

Thank you very much for your appreciation and explanation of your final solution!

That sounds as efficient as it can be and illustrates very well what the development team mean by their cost/benefit estimate.