I’ve been make a simple cs script to create a simple brep, when I trying to test a point is inside thease breps, some point ouside the brep has incorrect result.
Here is werid part, I baked these brep in to rhino document, and set it back to gh, and the results is changed to correct result.
What could go wrong, they are literally the same brep.
Here is the gh file, and all my brep is create by this method Brep.CreateBooleanUnion(new[] { part1, part2, part3, part4 }, 1e-3);, it’s quite simple, I create each part separately and put them together by Union operation, them make some transformations.
It is likely that the point-is-inside test is done based on the (render)mesh of the Brep. That mesh is only created when you preview the component in grasshopper, or when you bake it to the rhino document.
The solution, as outlined above is to do the tests on a mesh you create for the brep in grasshopper. And I agree, that this is a bug.
@menno@Quan_Li thanks guys. So I can use Mesh.IsPointInside instead of Brep.IsPointInside, but it’s not a proper way for me, I can’t create mesh for each time brep needs test point inside, this process will slow down the entire progrom. Is there a way to set(or trigger) RenderMesh for brep when I just created the brep to cache this mesh for performance reason?
you can also see that by the negative Volume values
as their volume is “the entire universe minus the volume they enclose”, they of course contain the two points
but if you explode them and Brep join, then their normals are correctly unified and the result is correct (I mean, it was correct also before that, but now it’s more “human correct”)
so @Hugo_Chinaglia I would advice to explode and rejoin your breps and check if that fixes the issue (or to attach your GH file with internalised data)
[edit] same result on Version 7 SR37 (7.37.24107.15001, 2024-04-16)
