I have what seems like a simple brep intersection instance which is giving a really weird result. The attached Grasshopper definition has the input shapes internalized; just 2 open brep surfaces, which I pass to a C# script which simply calls Brep.CreatePlanarIntersection, also taking in a Tolerance. The second shape, a rectangle, is completely contained within the first, and thus should be the result of the intersection; however the result is an inscribed triangle…?? Below you can see the outer squiggly shape in red, the inner rectangle in darker red, and the resulting surprise-triangle in green:
Here’s the GH definition to generate the behavior:
I initially found this case inside my application using RhinoCommon, and replicated it in a GH definition to make sure it wasn’t something my code was doing.
Can anyone see why this relatively simple case is failing? I tried flipping one of the surfaces and got the same result. I’ve done a lot of trial end error to find the most reliable and stable method in rhino to just take 2 planar surfaces which might have holes and perform a sort of “full outer join” on them, trying to find “A not in B / A overlapping B / B not in A”, and up until now CreatePlanarIntersection seemed to be the most stable… Is there some other method / paradigm I should be using? I tried doing it with variations on the Region Intersection component, but that doesn’t seem to handle holes well.
Any help would be greatly appreciated, this functionality is pretty key to my application.
Thanks for that Pascal, glad I’m barking up the right tree. Any thoughts on what might be causing this strange result from CreatePlanarIntersection on the provided geometry? I did notice that one of the surfaces is a NURBS surface and the other is a Plane surface, are there any known issues around those types not playing nicely together? Should I be doing some type conversion/translation on my surfaces before the boolean ops?
While the example provided is a Grasshopper file, this is more of a RhinoCommon API question / Rhino runtime question. Should I switch the topic?
Possible clue: I tried taking the input surfaces, decomposing them with Brep Edges, running the edges through Join Curves, casting them to Surfaces, and then running the Boolean Intersection, and got the correct result. Here’s the GH path:
And here is the results in Rhino, where the result of direct Boolean Intersection on the original shapes is translated above the originals, and the result of the rebuilt shapes is below:
Any thoughts on which internal properties/state would be changed by doing this surface-edges-surface round trip, which would lead to the boolean operation succeeding?
I don’t have rhino 8 but I’ve replicated the error in rhino 7 and when I put the smaller brep first the result is correct, while if I put the bigger one first it gives me the same triangle.
Interestingly I have tested it in VB.Net since its what I’m familiar with.
When I try to do the test in C# it throws an error because the breps are actually surfaces, but VB doesn’t seem to mind, but again I’m not used to C# so PlanarIntersectionNL.gh (13.9 KB)
might be declaring it wrong
Pascal, is there a way I could get this issue looked at by someone at McNeel? I’ve sunk a bunch of hours into it, but if there’s some way to have it registered as a ticket I’ll pause in trying to hunt down the issue myself.
