myMesh.Faces.GetFace(vertexIndex) returns weird negative triplet around the mesh

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.

Where should I start to fix this , what is going on with GetFace ?
The mesh was created by subdivision with WeaverBird from a simple, plain, triangular face.
Mesh via link:

Can you upload the mesh and/or the script (with internalize meaningful data)… ?

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.

The GetFace Method requires a Face index and not a Vertex Index.

for instance (where M is each Mesh from the disjoined pieces Mesh List):

var MF = M.Faces;
var MTV = M.TopologyVertices;
var MTE = M.TopologyEdges;

for(int i = 0; i<MF.Count;i++) {
MeshFace face = MF[i];
int faceVindices = MTV.IndicesFromFace(i);
int edgesIndices = MTE.GetEdgesForFace(i);

That said if you want to correlate things from faces see here:

Peter thanks for catching that ! I basically jumped one line of logic. (Non) problem solved.

Hi guys, yes.

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.

I hope this explanation is helpful.


Giulio Piacentino
for Robert McNeel & Associates

1 Like

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).

BTW: In case that you want to correlate V, E things:

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 called TryGetFace 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.