Having some issues with a mesh. I’m working in ghpython with mixed rs and rhinocommon code. For a particular mesh,
myMesh.Faces.GetFace(vertexIndex) returns triplets of negative values for some vertices, like T(-2147483648, -2147483648, -2147483648)
The mesh says it is Manifold and Valid. It is a Tri-Hex mesh, with empty hexagons, basically just the leftover triangles. If I move testing location towards center of the mesh, the issue is gone, going towards the outer boundary, almost all vertices return the negative goo.
Here’s the mesh and script. It seems distance from center of mesh has something to do with it. Just move the test point around to see the vertex index readout.
Mesh does not have any degenerate faces.
Mesh does not have any ngons.
Mesh does not have any extremely short edges.
Mesh does not have any non manifold edges.
Mesh does not have any duplicate faces.
Mesh does not have any faces with directions different from the mesh as a whole.
Mesh does not have any self intersecting faces.
Mesh has 571 disjoint pieces.
Mesh does not have any unused vertices.
Not throwing an exception and returning a “strange value” is actually a design intention of our SDK. We all may or may not agree with it. In case the index is out of range, MeshFaceList.GetFace() returns MeshFace.Unset.
Here the reference:
That large negative number is the smallest Int32 negative integer that is available.
If you use the indexer, it will throw IndexOutOfRangeException(). Maybe it should have thrown ArgumentOutOfRangeException(), but this is probably a subtlety.
Well … it’s not a bad thing but the 1M question is how this could happen since one access the faces via some sort of loop in M.Faces … meaning that the margins of error may be non existent (unless the mesh is bananas).
RhinoCommon is an SDK, so looking up an out-of-range index is something that can happen, and indeed happened here, and it can occur both on our side and in third-party code. It’s a design decision to adhere to the .Net recommendations or not. To adhere to the guidelines, GetFace() should have been calledTryGetFace and the indexer should have just thrown ArgumentOutOfRangeException, not IndexOutOfRange.
This was an early part of the RhinoCommon SDK and we were still figuring out all the details, and it is now written like this, so for backward-compatibility it will probably stay like this. Today it would probably be written differently, and maybe we would not have this conversation.