This has been mentioned in this post from 2016 but maybe it's worth bringing up again as 2018 hasn't resolved the issue yet.
As far as I can tell, the Face.Intersect(face) method always returns FaceIntersectionFaceResult.Intersecting - or I am not implementing it correctly. When I run the code below in a view with a single wall and single floor, each face to face test returns an intersection. Can someone please verify (maybe 2019)?
public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
{
var list = new FilteredElementCollector(commandData.Application.ActiveUIDocument.Document, commandData.View.Id).WhereElementIsNotElementType().Where(e => e is Wall || e is Floor);
foreach (var f1 in list.First().get_Geometry(new Options()).OfType<Solid>().First().Faces.OfType<Face>())
{
foreach (var f2 in list.Last().get_Geometry(new Options()).OfType<Solid>().First().Faces.OfType<Face>())
{
if (f1.Intersect(f2) == FaceIntersectionFaceResult.Intersecting)
{
if (System.Windows.Forms.MessageBox.Show("Intersects", "Continue", System.Windows.Forms.MessageBoxButtons.OKCancel, System.Windows.Forms.MessageBoxIcon.Exclamation) == System.Windows.Forms.DialogResult.Cancel) return Result.Succeeded;
}
}
}
return Result.Succeeded;
}
Solved! Go to Solution.
Solved by jeremytammik. Go to Solution.
Thank you for your report and reproducible case.
I see the same behaviour in Revit 2019 as well.
I added some code to The Building Coder samples to test and report in more depth:
I created the following disjunct floor and wall:
My sample code reports:
So, in fact, not every face-to-face test reports an intersection, because 7*6 equals 42.
Only the vast majority do 🙂
I logged the issue REVIT-133627 [Face.Intersect returns false positives] 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:
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.
Cheers,
Jeremy
Thanks Jeremy,
I'm using the Face.Intersect(curve) method because it seems to return SetComparisonResult.Overlap as expected, naturally with much more processing as a face needs to be compared to each curve of the other face - and visa versa - to check for all possible intersects.
Peter
The development team examined the issue that I raised for this and discovered it is a duplicate of an existing older issue, REVIT-58034 [API Face.Intersect(Face) returns true even if two faces don't intersect with each other]. They therefore closed this issue again. They also add: How critical is this, really?
I'm not surprised that this has been reported before, I am surprised that it hasn't been resolved.
How critical is this, really? I suppose in the grand scheme of things, not all that critical. However, I do expect a product to function as advertised.
They should just remove the method if they are not interested in fixing the problem.
I fully agree with what you say and am passing it on to the development team for their consideration.
Thank you!
Cheers,
Jeremy
@ciganek @Revitalizer the development team replied:
They are aware of this issue. This function does indeed not do what one expects. At most, it computes intersections between the underlying (unbounded) surfaces, not the (bounded) faces lying in the surfaces. As a first step, the documentation will be updated to reflect this fact. Then, we'll see whether resources can be found to fully implement the face intersection functionality,. or remove the incomplete functionality.
Sorry for the confusion!
Cheers,
Jeremy
Hi Jeremy,
an additional idea.
Could it be that, instead of the Face, the related Surface is compared, ignoring the borders?
If the method compares Planes instead of PlanarFaces, I would expect that they intersect all but parallel ones.
Rudi
Edit: same idea at the same time 🙂
@RevitalizerI believe you are correct. Have previously plotted the intersections using the ByRef curve overload and found this to be the case.
In actual fact an API user may prefer to find this form of intersection rather than be told no intersection exists (due to the bounds of the face preventing it). Can always compare points on the original face to those on the curve intersect result to check if there is an actual intersection. However if no results were given then that would not be useful at all. Probably there should be a bound versus unbound option perhaps.
@RPTHOMAS108 how did I miss that post?...
The description in help is indeed misleading - as is the method name + result.
Maybe the appropriate place for dealing with face to face intersections would be a face overload for the BooleanOperationsUtils class?
I just want to thank you for the feedback on the problem with this method, if not, I will waste more time in looking out my code.
And I agree with you that if this method is flawed, it should be improved or cancelled. Otherwise, like me, before I saw your post, I always thought it was a problem with my own code.
Best wishes
Danni
I've just been forwarded to this thread as I had posted reporting problems with that function.
As some users posted above, it is disappointing that the revit documentation is very vague about the accuracy of the function:
"Remarks
Hi @jeremytammik , do we have updates on the solution of this bug?
I tried today these functions and it seems to me that
Face.Intersect(Face) --> always False
Face.Intersect(Curve) --> always True
Curve.Intersect(Curve) --> this seems to work, but I need face intersections
BooleanOperationsUtils.ExecuteBooleanOperation(Solid, Solid, BooleanOperationsType.Intersect).Volume != 0 --> also works
Angelo
Hi @jeremytammik ,
After a week of trying and understanding what i'm doing wrong i find this post.
I'm making a script whereby i extraced the interior and exterior faces of walls and see if they intersect.
The goals is to find (seperataly modelled) walls wich would ressemble a compound (layered) wall.
So logicaly i used the Face.Intersect(face) method.
And i'm getting the wrong results as discriped above.
I therefore assume this issue is still ongoing?
A bit dissiapointed that more then 3 year have passed without a solution to this.
Or is there?
Is there more recent feedback from the developers team on this?
in dynamo i am able to get te correct results by just retrieving the faces and using the geometry.DoesIntesect Node to get the correct intersections from it.
If u want i can deliver my code and project for evaluation.
Altho it is writing in Cpython for use with pyrevit, it is still based on the same Api.
kind regards,
Alexander
Having a quick look in the documentation, I still see the ominous line: "This is not a general-purpose function: it only works properly for simple configurations".
Most likely, they still didn't fix it.
i'm working on a 'big' work around right now.
whereby i generate a uv-grid of the faces and then check via the Face.IsInside(uv) if walls are adjecnt to each other.
Seems to be working out at first but now i get the same funky end results....
I'll post when i'm done :)... To Be Continued
I'm not sure if that solution will work, there is a high chance that the point grid will just go through the face and not fall on it. What about converting the walls into solids and curves, and then use the IntersectWithCurve to get the result?
When I posted on this thread 4 years ago, I also developed a workaround, using other intersect functions. Unfortunately, I don't remember anymore if SolidIntersection is working correctly... At least there is no weird disclaimer on the docs.
Hey @jeremytammik , This is actually very critical, I've also been trying to work through a work around to determine what faces intersect for an area calculation Add-in. I basically ended up having to do two separate approaches.
GeometryElement wallGeo = wall.get_Geometry(options);
Solid wallSolid = wallGeo?.FirstOrDefault() as Solid;
if (wallSolid != null && baseSolid != null)
{
ElementIntersectsSolidFilter solidFilter = new ElementIntersectsSolidFilter(baseSolid);
FilteredElementCollector intersectingElements = new FilteredElementCollector(_doc).WherePasses(solidFilter);
double highestIntersectionZ = 0; // Changed from double.MinValue
bool intersectionFound = false; // Flag to check if intersection was found
foreach (Element intersectingElement in intersectingElements)
{
if (intersectingElement.Id == wall.Id)
{
GeometryElement geoElement = intersectingElement.get_Geometry(options);
foreach (GeometryObject geoObject in geoElement)
{
Solid solid = geoObject as Solid;
if (solid != null)
{
foreach (Face face in solid.Faces)
{
BoundingBoxUV bbox = face.GetBoundingBox();
var vertices = face.Triangulate().Vertices;
double avgZ = vertices.Average(v => v.Z);
if (avgZ > highestIntersectionZ)
{
highestIntersectionZ = avgZ;
intersectionFound = true; // Set flag true if intersection was found
}
}
}
}
}
}
if (!intersectionFound)
{
//
}
else
{
//Utilize Bound boxes to create solid objects and then determined if the solids were near each other using a
ProximityTolerance. But I am still have accuracy issues.
}
Basically I am attempting to determine what height a wall is above a specific floor or roof element to determine parapet area.
If this is critical for you, we certainly want to support you in resolving it.
Your description does not sound problematic at all, through: basically I am attempting to determine what height a wall is above a specific floor or roof element to determine parapet area.
Can you share an image demonstrating your objective?
I can think of several different ways to approach this
So what problem do you encounter?
What does it have to do with the various discussions above?