Hi,
Me and @DavidMans are trying to make sense of the false output we get from the Mesh point inclusion component in the example illustrated below. Welding the mesh doesn’t seem to improve the result, but moving the point asymmetrically either along the X or Y direction seems to resolve it. Any ideas of what’s going on and if there is a workaround? Example file is attached.
I’m running this on 6.19.19295.1001 and doc tolerance 0.01.MeshPointInclusionTest.gh (18.4 KB)
Thanks,
Emil
Excellent, thanks @dale. Let us know if we can help.
It’s not limited to your point, I guess it’s a known bug explained here:
It happens whenever the mesh and it’s bouding box are Identical, one workaround is to slightly rotate inputs:
BTW: Also in R5 the Mesh.IsPointInside(…) Method yields occasionally incorrect results most notably if Mesh.IsClosed returns true AND Mesh.SolidOrientation() returns 0 (meaning propably inward/outward facing normals).
If you are familiar with C# I could provide some temporary sort of solution.
Thanks, @PeterFotiadis - a C# workaround would be fantastic for the time being.
OK, I’ll prepare a simple case with 3 test options (IsPointInside and other 2) as used in some C# that attempts to “heal/fill” Concave Mesh faces on a per topology edge Face adjacency basis.
Thus you can use portions of the code for your purposes.
Thanks @Mahdiyar - I didn’t know this issue had a history!
Rotating the input mesh isn’t ideal, but definitely a good candidate for a temporary workaround. Many thanks for sharing your definition.
Just to clarify, you only need to use the rotated mesh and points as inputs for MeshInclusion component. and obviously, elsewhere, you can use the original mesh and points.
Here’s the thing:
As I said the scope of this is to locate edges that yield convex/concave dihedrals (in order to “relax” similar Meshes used for freaky MERO trusses, blah, blah).
In order to find the edges 3 options are provited: 2 of them require answering the 1M question: is it or is it not. At first keep the test mesh as it is (N1) and change the insidePtPolicy and/or the mode: spot that for some cases (i.e. meshes) the Mesh.IsPointInside Rhino Method yields bananas … so use the approach for mode 3 as aalternative/temporary (until the fix) solution.
Also spot what the SolidOrientation has to say (yields 0 while the Mesh is closed: LOL or what).
Mesh_DihedralConvexConcaveAngles_V1A.gh (141.2 KB)
Moral: bananas.
Thanks @Mahdiyar. For context, the inclusion logic will go straight into a rhinocommon based backend system where the check performed on a modified mesh might cause other issues downstream. The GH definition attached was just to demonstrate the issue.
Thanks again!
Hi @emilpoulsen,
We should have a fix in this week’s WIP release candidate.
https://mcneel.myjetbrains.com/youtrack/issue/RH-57774
– Dale
Appreciate it, thanks @dale! I’ll report back as soon as I get the chance to test it.
Just tested this in yesterday’s WIP and it looks much better. Thanks again @dale!!
RH-57774 is fixed in the latest Service Release Candidate
