Hello, All,
Does anyone have an explanation for this?
I have two elements (12" Masonry Wall and a Concrete Structural Framing) that are supposed to have no intersection. When I check their intersection with the BoundingBox method, I get a positive result whereas when I check with the geometry method, I get negative.
I know about the concept that BoundingBoxes are cubic with min and max points but this does not illustrates the difference between the results of the two methods.
Please check the RVT project in this link âshorturl.at/aLNUZâ for more details.
Thank you.
A picture of the geometry would be useful as Iâm away from a computer, but I would visualise the bounding boxes in dynamo by converting the bounding box into a solid. There you should see why this might be the case.
Usually it is because the elements that the bounding box circumscribes are not aligned with an internal axis. Bounding boxes are orthogonal to the internal coordinate system not the elements. So if these two elements are at angles and almost meet, chances are the bounding boxes will collide, but the geometry wonât.
2 Likes
Bounding boxes are oriented globally, meaning they will always be aligned to the global X- and Y-axes, not the local axes of the element. They are not a good means for checking exact location or intersection for this reason.
3 Likes
Snap! 
1 Like
Thanks guys for your replies.
But the wall actually is under the beam (they have a very small vertical gap between) and therefore the X and Y axes donât really matter.
Here is a picture.
Hmm, how small is the gap? One possibility is floating point precision. When computing numbers, there is a certain precision point where it gets weird and youâll get erroneous results, in revit I think this is about the 6th decimal place, in dynamo however you have geometry scaling, you may want to change this to a higher setting where youâll have better precision.
1 Like
⌠until Dynamo 2.16 lands in Revit with Oriented Bounding Boxes
3 Likes
Yeah, I have thought of that maybe it is a precision problem but I have run my script through too many walls in the model. All of them go properly and donât intersect the beams above them except this wall. It does intersect with the boundingbox method. The gap is 0.00001 ft.
When I tried to increase the gap the problem is solved but I still wonder why this wall have the problem while other walls donât!
Yeah, does sound like a precision issue. Did you try changing the geometry scaling in dynamo? This can solve issues like this and give more consistent results.
To get around this issue, I would do a post intersection check which compares the bounding Box Aâs Max.Z with Bounding Box Bâs Min.Z for those bounding boxes that intersected and check if the difference is almost zero (or whatever tolerance you see fit). This is the cheapest method and easy to do.
Another way, but more expensive is to convert intersecting bounding boxes to solids and do a geometry.intersection and check the resultant solids volume (if not null), if it is very small or null, then assume that it was a false flag. You could also do a geometry.union and if the resultant solids volume is almost equal to the sum of both initial solids, then this also passes.
2 Likes
This is certainly a floating point precision error based on the 6 decimal degrees.
Generally speaking you should only be using bounding box intersection as an initial pass, immediately testing the geometry after the fact to confirm intersection or not. Doing so would remove the false flag in this case.
I often find that the âprecisionâ input of Revitâs bounding box intersection is a good addition to the toolset. You can replicate this by slightly scaling up your bounding boxâs min and max point (move them by a vector) to get that added âalmost intersectsâ and then move into the geometry intersection.
1 Like
Hi Daniel,
I am really grateful for your concern.
I have tried everything you have said. I changed the dynamo scaling but they still intersect. I also checked the values of BBMax and BBMin and they are equal to 0.00000 which shouldnât be. The difference should be 0.00001 as in the BBs from the geometry method.
I have converted the boundingboxes to solid and have found that they intersect in rectangular. whereas they should have a gap between them.
If you care about my case, I can send you a revit file with the script to have a look. For me, I have found a better technique using the (ElementIntersectSolidFilter) and it works perfectly now but I still curious about why among all walls and beams, the gap between this specific wall and beam closes.
Thanks again Daniel! 
Thanks Jacob for joining the discussion!
I appreciate your advice and surely I will make use of it.
Regarding the last paragraph, I am not sure I understand you correctly. Do you mean extending the bounding box to get the intersection?
Yes - make the bounding box slightly larger to account for the floating point error. Once that is done you get the specific information by using the geometry intersection test.
1 Like
The fact the max.Z is equal to the others min.Z and you happen to know thereâs a gap (although, I would consider 0.00001 to not be a trustworthy measurement due to this exact issue) shows you that there is a floating point error.
And yes, when doing the solid intersection test, this would result in a rectangular surface as the solids are touching.
Itâs up to you how you interpret these results, in your case these results would be the same as if the BoundingBox.Intersects node returned false.
Thatâs great⌠But⌠Bear in mind that this node comes with a much higher compute cost (any node that gets revit geometry will be expensive), I would only use these types of nodes after the bounding box test.
Also, it is still subject to the same rounding point error. Here it happens to be working (which further suggests a rounding point error with the bounding box intersects node), but might not always for the same reasons. The bounding box envelopes the elements geometry, the ElementSolidIntersects node is using the solid geometry of one element (or a solid you give it) to check against intersection of another elements bounding box or solid. So there can still be a false flag if the elements are within 0.00001, it just so happens in your case that when computing the bounding boxes they are getting rounded up (or down) by 0.00001 causing the false flag.
I hope all that makes sense! 
As a rule of thumb though, I would consider a gap of 0.00001 to pretty much be equal and in these cases you choose if this is or isnât an intersection based on your requirements.
1 Like
That will be great but my aim is not to get the intersection information. It is to check whether walls intersect the beams or not to make changes related to the heights of the wall. So, the key is to get the correct bool from the check.
Yeah it is not trustwworthy for me too 
. But It works for all cases of walls and beams except this one 
Fortunately, I use many filters before the solid intersect filter so yeah I take this into account although I had no idea about the note of revit geometry. Thank you for sharing with me such valuable note.
You are right I have checked it but I have found a very good thing related to ElementIntersectSolidFilter. It doesnât consider elements that intersect the given solid in geometry other than solid. In my case, I make this small gap just to prevent the tangent intersection. So, with the ElementIntersectSolidFilter, I donât need to make the gap anymore as it will not get the beams and walls as they intersect in curves not solid. I hope you get me.
1 Like
Ha, cool. Well if it works it works!
1 Like
Yeah
I will mark your answer of (floating point precision) as a solution.
Thanks again.
1 Like
Yep - no need to run the Geometry.Intersect in that case, just go with the Geometry.DoesIntersect which is actually faster.
1 Like